1 / 6

Requirements Models

This document outlines the importance and methods of representing products in analysis models beyond textual descriptions. It emphasizes the objective of conveying the system's objects, functions, behaviors, interfaces, and constraints clearly to stakeholders. The focus is on high-level, customer-visible requirements, using various modeling approaches including Data Modeling, Use Case, and Behavioral Modeling. The models should simplify communication, enhance understanding, and ignore non-visible infrastructure to deliver value through effective visualization.

uta-price
Télécharger la présentation

Requirements Models

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Requirements Models Representing the Product in Ways Other than Text

  2. 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

  3. 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)

  4. 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

  5. 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

  6. 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

More Related