Requirements Modeling: Introduction and Components, Scenario based Modeling

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman..

. Quick Recap. Requirement Elaboration Requirement Modeling = Analysis Modeling Big Picture of Analysis Modeling Negotiation Specification Validation.

. Today’s Agenda. Objective of Analysis Modeling Approaches of Analysis Modeling Elements of Analysis Model Scenario based Modeling Narrative based Refining preliminary use-cases Writing Formal use-cases Diagrammatic use-cases Activity Diagram as supplement.

. Requirement Modeling - Objectives. The requirements model must achieve three primary objectives: (1) to describe what the customer requires (2) to establish a basis for the creation of a software design (3) to define a set of requirements that can be validated once the software is built Requirement Model or Analysis Model Bridges the Gap between System Description and Design Model.

. Requirement Modeling Approaches. Two Approaches: Structured vs O-O Approach Structure Approach considers data & the processes that transform the data as separate entities . Data objects are modeled in a way that defines their attributes and relationships. Processes that manipulate data objects are modeled in a manner that shows how they transform data as data objects flow through the system.

. Requirement Modeling Approaches. Object Oriented Approach Focuses on the definition of classes and the manner in which they collaborate with one another to effect customer requirements UML and the Unified Process are Predominantly object oriented..

. Requirement Modeling Approaches. Although the requirements model proposed in this book combines features of both approaches, software teams often choose one approach and exclude all representations from the other Each element of the requirements model presents the problem from a different point of view.

. Elements of Requirement Model. The requirements model—actually a set of models—is the first technical representation of a system Scenario-based models of requirements from the point of view of various system “actors” Class-oriented model – represents object-oriented classes (attributes and operations) and the manner in which classes collaborate to achieve requirements Flow-oriented model – represent the functional elements of the system and how they transform data as it moves through the system Behavioral model – represent how the software behaves as a consequence of external “events” Data model – represent the information domain for the problem.

. 9. Scenario-Based Modeling. Inception and elicitation —provide you with the information you’ll need to begin writing use cases Requirements gathering meetings, QFD, and other requirements engineering mechanisms are used to identify stakeholders define the scope of the problem specify overall operational goals establish priorities outline all known functional requirements, and describe the things (objects) that will be manipulated by the system To begin developing a set of use cases, list the functions or activities performed by a specific actor.

. Scenario-Based Modeling. The SafeHome home surveillance already discussed identifies the following functions (an abbreviated list) that are performed by the homeowner ( an actor): • Select camera to view • Request thumbnails from all cameras • Control pan (left & right movement) and zoom for a specific camera • Selectively record camera output • Replay camera output • Access camera surveillance via the Internet- display camera views.

. Scenario-Based Modeling. The requirements gathering team develops use cases for each of the functions noted In general, use cases are written first in an informal narrative fashion If more formality is required, the same use case is rewritten using a structured format Example: Consider the function “ access camera surveillance via the Internet— display camera views” Narrative of homeowner about interaction.

. Scenario-Based Modeling. Use case: Access camera surveillance via the Internet—display camera views (ACS-DCV) Actor: homeowner.

. Scenario-Based Modeling. A variation of a narrative use case presents the interaction as an ordered sequence of user actions.

. Scenario-Based Modeling. It is important to note that this sequential presentation does not consider any alternative interactions (the narrative is more free-flowing and did represent a few alternatives) Use cases of this type are sometimes referred to as primary scenarios Refining a Preliminary Use Case A description of alternative interactions is essential for a complete understanding of the function that is being described by a use case Therefore, each step in the primary scenario is evaluated by asking the set of questions.

. Scenario-Based Modeling. Q1: Can the actor take some other action at this point? Q2: Is it possible that the actor will encounter some error condition at this point? If so, what might it be? Q3: Is it possible that the actor will encounter some other behavior at this point (e.g., behavior that is invoked by some event outside the actor’s control)? If so, what might it be? EXAMPLE: Next Slide.

. 16. Q2: Is it possible that the actor will encounter some error condition at this point? Any number of error conditions can occur as a computer-based system operates. In this context, we consider only error conditions that are likely as a direct result of the action described in step 6 or step 7. Again the answer to the question is “yes.” A floor plan with camera icons may have never been configured. Hence, selecting “pick a camera” results in an error condition: “No floor plan configured for this house.” This error condition becomes a secondary scenario..

. Scenario-Based Modeling. Each of the situations described in the preceding slide is characterized as a use-case exception An exception describes a situation that causes the system to exhibit somewhat different behavior either a failure condition or an alternative chosen by the actor.

. Scenario-Based Modeling. In addition to the three generic questions suggested earlier in this section, the following issues should also be explored: Are there cases in which some “validation function” occurs during this use case? For example - validation function is invoked and a potential error condition might occur Are there cases in which a supporting function (or actor) will fail to respond appropriately? For example, a user action awaits a response but the function that is to respond times out Can poor system performance result in unexpected or improper user actions? For example, a Web-based interface responds too slowly, resulting in a user making multiple selects on a processing button. These selects queue inappropriately and ultimately generate an error condition.

. 19. Scenario-Based Modeling. As further conversations with the stakeholders progress, the requirements gathering team develops use cases for each of the functions noted In general, use cases are written first in an informal narrative fashion If more formality is required, the same use case is rewritten using a structured format similar to the one proposed.

. Writing a Formal Use-Case. Important elements of a formal use-case The goal in context identifies the overall scope of the use case. The precondition describes what is known to be true before the use case is initiated. The trigger identifies the event or condition that “gets the use case started” [Coc01b]. The scenario lists the specific actions that are required by the actor and the appropriate system responses. Exceptions identify the situations uncovered as the preliminary use case is refined. Additional elements may or may not be included.

. 21. SAFEHOUE Use Casc Template for Surveillance mg: Acces ÄÜa IACS-XV) 2, 14 V. Prinary GWI in of via a insi& 1. The 2. The D. 3. The eigh in 5. The FÜnewner 6. The a 7. The 8. The a 9. The a is i&røifid cmera 11. The e*iin 'rune cae se cae wrveiUame al use case Humbnaa 4. A is ne we plan. 5. is cae Narm encwMerd. Wirn TKrd Charnel «t«t md Chatmeb 2. Coe: issue: by enpby•es of gi.M c.ti".

. Diagrammatic Representation. Ease of understanding in case of complexity.

. UML Model that Supplement the Use-Case. In many situations a text-based model— even one as simple as a use case—may not impart information in a clear and concise manner In such cases, you can choose from a broad array of UML graphical models Developing an Activity Diagram The UML activity diagram supplements the use case by providing a graphical representation of the flow of interaction within a specific scenario. (Similar to the flowchart) An activity diagram uses: Rounded rectangles to imply a specific system function Arrows to represent flow through the system, Decision diamonds to depict a branching decision (each arrow coming from the diamond is labeled), Solid horizontal lines to indicate that parallel activities are occurring.

. UML Model that Supplement the Use-Case. Activity Diagram for the ACS-DCV use case.

. Summary. Objective of Analysis Modeling Approaches of Analysis Modeling Elements of Analysis Model Scenario based Modeling Narrative based Refining preliminary use-cases Writing Formal use-cases Diagrammatic use-cases Activity Diagram as supplement.