70 likes | 178 Views
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 6.1.1 7/e, 3 rd paragraph, section 8.1 6/e) What: Objects
E N D
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 1st paragraph section 6.1.1 7/e, 3rd 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 Function Process
Guidelines for Representations (Section 6.1.2 7/e, 8.1.2 6/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 6.1.4 pgs 153-154 7/e, pgs 179-180 6/e) • Detailed description on writing use cases (see section 6.2.1 pgs 155-161 7/e, section 8.5.1 pgs 186-191 6/e) and/or The Pragmatic Programmer Chapter 7. • Other UML diagram examples (pgs 161-163 and 172-175 7/e, 191-193 and 205-208 6/e) & Appendix A 7/e • Suggested representations: user scenarios, activity diagrams, class diagrams, ERD