Download to read offline
Lecture_four-_Requirements_Modeling (1).pptx
- 1. Requirements Modeling Course code:SWE 2102 MBARARA UNIVERSITY OF SCIENCE AND TECHNOLOGY Course Facilitators: Dr. Angella Musiimenta (PhD) & Wilson Tumuhimbise (MSc) 1
- 2. Today Modeling Requirements: from customerviews to something translatable to software Techniques for developing functional requirements What the software is supposed to do!
- 3. Requirements modeling We buildmodels in requirements analysis to understand current systems or business processes which we are trying to automate how users will use a new system
- 4. Building from theRequirements document • Refer to the Requirements document 4
- 5. What is amodel • A representation of a system that allows for investigation of the properties of the system and, in some cases, prediction of future outcomes 5
- 6. Role of Modellingin RE • Modelling can guide elicitation – It can help you figure out what questions to ask – It can help to surface hidden requirements does it help you ask the right questions? • Modelling can provide a measure of progress: – Completeness of the models -> completeness of the elicitation (?) • i.e. if we’ve filled in all the pieces of the models, are we done? 6
- 7. Role of Modeling.. •Modelling can help to uncover problems – Inconsistency in the models can reveal interesting things • e.g. conflicting or infeasible requirements • e.g. confusion over terminology, scope, etc • disagreements between stakeholders • Modelling can help us check our understanding – Reason over the model to understand its consequences – Provide views that allow us to understand product requirements precisely. • Does it have the properties we expect? – Animate the model to help us visualize/validate the requirements 7
- 8. Example types ofmodels • Business model: describes the target environment and processes. They describe why a product is needed • A feature and/or goal model describes planned product features. A goal model focuses on nonfunctional requirement constraints. Describes the features of a product being created to enable the business model. 8
- 9. Types of models… •Use case/analysis model describes each product feature in detail and contains the product requirements. • The design model translates the requirements into a product design. illustrates the architecture for the product. 9
- 10. Requirements and Design Inprinciple, requirements should state what the system should do and the design should describe how it does this. In practice, requirements and design are inseparable
- 11. Tools for modelingrequirements • Use Cases • State Diagrams • UI Mockups – standard process in Department of Defense and auto industry • Storyboards • Prototypes • Example: TLB – Meetings and Arch/Design Specifications
- 12. Functional Requirements: What shouldit do? Developer connect mysql database to asp .net web … Client sell my beautiful jewelry Customer of client find a cool ring on sale
- 13. Client sell my beautiful jewelry Customer ofclient find a cool ring on sale User-centric: What, not how Difficult to express Functional Requirements: What should it do?
- 14. Modeling functional Reqs Identifyuser classes Example: jewelry store owner buyer of jewelry
- 15. Modeling functional reqs Identifyuser classes For each user class identify goals Example Buyer: search for item place an order return an item
- 16. Modeling functional requirements Identifyuser classes For each user class identify goals For each user class/goal Describe how the user will use the system
- 17. Example Name: Order jewelryfrom a catalog Actors: Customer Alice, Sales rep Bob, Stockroom, Shipping dept. Initiator: Alice Scenario: 1. Alice calls company 2. Bob answers phone 3. Alice says she wants to place an order from the catalogue. 4. Bob asks how the order will be paid. 5. … USE CASE
- 18. Forms of UseCases • Casual – “user stories” • Fully dressed use cases – preconditions, post-conditions, actors, stakeholders, etc. … these are cultural issues but in agile methods, less is more
- 19. Key aspects ofUse Case • Name: what we call this use case • Actors: entities that interact with system (typically people but also can be other systems) • Initiator: actor who initiates the use case • Scenario: sequence of steps users take and how system responds
- 20. Example: Main scenario Name:Order jewelry from a catalog Actors: Customer Alice, Sales rep Bob, Stockroom, Shipping dept. Initiator: Alice Scenario: 1. Alice calls company 2. Bob answers phone 3. Alice says she wants to order item X. 4. Bob checks stockroom for availability. 5. Stockroom says it is available. 6. …
- 21. Main scenario withbranches Name: Order jewelry from a catalog Actors: Customer Alice, Sales rep Bob, Stockroom, Shipping dept. Initiator: Alice Scenario: 1. Alice calls company 2. Bob answers phone 3. Alice says she want to order item D23 from page 5 the catalogue. 4. Bob checks stockroom for availability. 5. Stockroom says it is available. 5a. Stockroom says it is not available. See order out of stock item use case. 6. …. Alternative path can be completed or refer to another use case.
- 22. Use case development Brainstormto identify Use Cases Validate/prioritize/ensure consistency Elaborate high priority/complex use cases identify new Use Cases Repeat until _________________ Waterfall: until done – done keeps moving Agile: until good enough for now
- 23. Example 2: ATMUse cases 23
- 24. Modeling scenarios usingsequence diagrams 24
- 25. Use Case Elaborations •A use case diagram by itself is useless. Each use case should be associated with a use case elaboration. A use case elaboration consists of the following information: • Name: Actors: Description: Priority: (high, medium, low) Risk: (high, medium, low) Scenarios: Scenario 1: this is usually the main scenario Scenario 2: an alternate scenario Scenario 3: another alternate scenario 25
- 26. For example • Name:Transfer Funds Actors: Account Holder, Bank Server Description: The account holder transfers a specified amount of money from a specified source account to a specified destination account. Priority: high Risk: medium Scenarios: Scenario 1: Funds are transferred successfully Scenario 2: Insufficient funds in source account Scenario 3: Source or destination accounts are in use Scenario 4: Invalid PIN 26
- 27. Use Case Scenarios •A use case scenario is a script that describes a typical conversation between a use case and its associated actors. • The main scenario is the most typical conversation in which the goal is achieved. Secondary scenarios describe conversations in which errors or other unusual conditions arise. 27
- 28. Modeling scenarios usingscripts • For example, the main scenario for "Transfer Funds" begins by validating the account holder: Holder: Inserts card ATM: Reads card ATM: Requests holder info Bank: Returns holder info ATM: Requests pin Holder: Enters PIN ATM: Validates PIN ATM: Displays menu 28
- 29. Contd.. • Since themain scenario is usually successful, we may assume the PIN was valid. Next the ATM gathers information from the holder about the transaction: Holder: Selects "Transfer" ATM: Requests source account (Savings/Current) Holder: Selects source account ATM: Requests destination account Holder: Selects destination account ATM: Requests amount holder: Specifies amount ATM: Requests transfer Bank: Transfers funds Bank: Acknowledges transfer 29
- 30. Contd.. • Finally, theATM acknowledges the transaction, prints a receipt, and displays the options menu: ATM: Acknowledges transaction ATM: Need receipt? holder: Selects "yes" ATM: Prints receipt ATM: Displays menu 30
- 31. Uses of usecase Requirements: Define functional requirements Expose business rules (constraints on behavior) Planning: Suggest an iterative strategy Design: Validate design models, i.e., does design provide for Use Case Testing: Provide scenarios for validation testing
- 32. Requirement Quality • Specifywhat not how • Unambiguous • Testable • Feasible • Consistent • Prioritized • Traceable – Agile: back to requestor Interative: back to a specification # • Agreed upon by customer How can Use Cases contribute to quality in functional requirements?
- 33. Tools for modeling(functional) requirements • Use Cases • State Diagrams • UI Mockups • Storyboards • Prototypes good for describing “flow”
- 34. State diagrams • Describethe behavior of a system • Help to visualize the entire life cycle of objects, provide a better understanding of state based systems e.g a cash machine • Depict events effected by state transitions 34
- 35. State diagrams Moves to emptyspot Pac Man has n lives, score k moves left, right, up, down Hits ghost: Sound effect n reduced by 1 Lose level n=0 n>0 Hits dot: Sound effect k increased by 50 k<MAX Win level Play level: initialize n=3 (#lives), k=0 (level score) k<0
- 36. Tools for modeling(functional) requirements • Use Cases • State Diagrams • UI Mockups • Storyboards • Prototypes good for describing “flow” Better for state machines
- 37. UI Mock UP •UI Mock Up (or even full design) is often considered part of the requirements process because it summarizes the ways a user can interact with the system. • UI design can also address non functional requirements, e.g., look and feel
- 38. Storyboards Good for communicating“look and feel” in addition to “flow” – (again addressing non-functional requirements)
- 39. Tools for modeling(functional) requirements • Use Cases • State Diagrams • UI Mockups • Storyboards • Prototypes these are special cases of prototypes
- 40. Prototypes Sample level withsimplified art, minimal features Use fast prototyping tools to clarify functionality, look and feel, etc.
- 41. Sample questions • Inrequirements engineering, modelling customers’ views to something translatable to software is critical. As a software engineering student, – Define the term requirements modelling. – Explain any four roles of requirements modelling. – Describe any five tools that can be used to model software requirements.
- 42.