Requirements for a computer-based system can be seen in many different ways. Some software people argue that it’s worth using a number of different modes of representation while others believe that it’s best to select one mode of representation.
The specific elements of the requirements model are dedicated to the analysis modeling method that is to be used.
- Scenario-based elements :
Using a scenario-based approach, system is described from user’s point of view. For example, basic use cases and their corresponding use-case diagrams evolve into more elaborate template-based use cases. Figure 1(a) depicts a UML activity diagram for eliciting requirements and representing them using use cases. There are three levels of elaboration. - Class-based elements :
A collection of things that have similar attributes and common behaviors i.e., objects are categorized into classes. For example, a UML case diagram can be used to depict a Sensor class for the SafeHome security function. Note that diagram lists attributes of sensors and operations that can be applied to modify these attributes. In addition to class diagrams, other analysis modeling elements depict manner in which classes collaborate with one another and relationships and interactions between classes. - Behavioral elements :
Effect of behavior of computer-based system can be seen on design that is chosen and implementation approach that is applied. Modeling elements that depict behavior must be provided by requirements model.Method for representing behavior of a system by depicting its states and events that cause system to change state is state diagram. A state is an externally observable mode of behavior. In addition, state diagram indicates actions taken as a consequence of a particular event.
To illustrate use of a state diagram, consider software embedded within safeHome control panel that is responsible for reading user input. A simplified UML state diagram is shown in figure 2.
- Flow-oriented elements :
As it flows through a computer-based system information is transformed. System accepts input, applies functions to transform it, and produces output in a various forms. Input may be a control signal transmitted by a transducer, a series of numbers typed by human operator, a packet of information transmitted on a network link, or a voluminous data file retrieved from secondary storage. Transform may compromise a single logical comparison, a complex numerical algorithm, or a rule-inference approach of an expert system. Output produce a 200-page report or may light a single LED. In effect, we can create a flow model for any computer-based system, regardless of size and complexity.