Requirements Models Representing the Product in Ways Other than Text

Purpose of the Requirements (or Analysis) Models Objective: To communicate what constitutes the program (or system) at hand (see 1 st paragraph section /e, 3 rd paragraph, section 8.1 6/e) What: Objects Functions Behaviors (e.g., action-response) Interfaces: internal and external Constraints The models are to provide multiple viewpoints of the program (or system) to nurture understanding about the program (or system) Informational (data) Functional (capability, features) Behavioral (process, control, response) Data ProcessFunction

Guidelines for Representations (Section /e, /e) Focus on customer visible requirements— keep the abstraction high The model diagrams should add value Ignore support infrastructure (non-visible functions, objects or behavior) in model Minimize communication between system components Models should communicate their ideas to all stakeholders Keep the model simple (as possible)

Modeling Approaches Data Modeling Identification of system data, its hierarchy, and relationships Models: Entity Relationship Diagrams Class-Based (Object-Oriented) Modeling Identifying the actors (objects), responsibilities (functions), and collaborations (interfaces) for the system’s components Models: Use Case, Activity Diagrams, Swim-lane Diagrams, CRC, and Class Diagrams Scenario-Based Modeling Modeling user-level functions, features, appearance, and behavior Models: Use cases

Modeling Approaches (cont) Flow-Oriented Modeling Input-process-output view of system Applicable in settings where sequences of business functions are being accomplished with application Models: Process Charts, Data Flow Diagrams, and State Diagrams Behavioral Modeling Models: Use Case and State Diagrams

Additional Points of Emphasis Analysis models are a bridge between textual summaries of application and design (fig. 6.1 pg 150 7/e, fig. 8.1 pg 177 6/e) Two common approaches to analysis: structured and OO (section pgs /e, pgs /e) Detailed description on writing use cases (see section pgs /e, section pgs /e) Other UML diagram examples (pgs and /e, and /e) Suggested representations: user scenarios, activity diagrams, class diagrams, ERD