1. Slide 1 Requirements Workflow

2. Slide 2 The Phases/Workflows of the Unified Process Figure 3.1 l Phase is Business context of a step Workflow is Technical context of a step LAST WEEK WE ARE HERE

3. Slide 3 Requirements Workflow Goals  Aim development toward the right system  Describe what the system should and should not do - an agreement between customer (including user) and development organization - in the language of the customer/user

4. Slide 4 Requirements Workflow l The primary activities of the Requirements workflow are aimed at building the use case model, which captures the functional requirements of the system being defined. This model helps the project stakeholders reach agreement on the capabilities of the system and the conditions to which it must conform.

5. Slide 5 Requirements Workflow Tasks 1. List candidate requirements 2. Understand system context 3. Capture functional requirements 4. Capture non-functional requirements 5. Validate requirements (not well-developed)

6. Slide 6 1. List candidate requirements l List Candidate features that could become requirements l - Good ideas added to feature list You can place all candidates l Evaluate candidate features to decide if they become items on the shall list. Use the items below to help decide. l · Planning values, - Status, - Cost. – Priority. – Risk l If scope too big, prioritize shall list items.

7. Slide 7 2. Understand system context l Domain model (business concepts) l AND OR l Business Model (business processes)

8. Slide 8 2. Understand system context l Domain model l - Identify and name important concepts l and entities in the system context l - Identify and name relations between l domain objects l - Glossary for now, possible classes in l analysis and design workflows

9. Slide 9 2. Understand system context l Objects or concepts: things in the system l context that the system must manipulate or l keep track of l · Events that transpire in the system context l · Capture as class models or (for small systems) as a glossary of terms l Creates a common language for customer and l developer l Focus on domain modeling; defer system l internal modeling to analysis, design, and l implementation

10. Slide 10 Requirements Workflow l The use case model also serves as the foundation for all other development work.

11. Slide 11 2. Understand system context l Business model l - Domain (object) model plus processes/behaviors workers, their responsibilities and operations l · Decide whether to build a business l model, a domain model, or simply a l glossary of terms

12. Slide 12 2. Understand system context l Business use case model - processes (use cases) and users (actors) in roles - represents system from a usage perspective and l outlines how it provides value to its users l Business object model - how each use case is realized by a set of workers who are using business entities and work units

13. Slide 13 3. Capture functional requirements  Capture requirements as use cases  Use case: a user’s way of using the system  When an actor (user or external subsystem) uses the system, the system performs a use case  All use cases = all the things the system must do  Capture user interfaces that support the use cases

14. Slide 14 4. Capture non-functional requirements  System properties  Environmental or implementation constraints  e.g. must have remote access or must run on  Linux or WinNT  Qualities (“-ilities”): performance, reliability,  security, maintainability, extensibility, usability, etc.  Tie to use cases or domain concepts, where possible  those that cannot be tied (they are general) are listed as supplementary requirements

15. Slide 15 5. Validate requirements 1. Detailed Use Case Descriptions validated with users – Functional Test Cases Defined if possible 2. Prototype the User Interfaces (with or without navigation)

16. Slide 16 Requirements Workflow in the Life Cycle Inception - identify most of the use cases to define scope - detail critical use cases (10%) Elaboration - detail the use cases (80% of the requirements) Construction - identify and detail remaining use cases Transition - track and capture requirements changes

17. Slide 17 Summary l Capture requirements as - Business model, domain model or glossary to capture system context - Use-case model that captures functional requirements and use-case-specific nonfunctional requirements Survey description of model as a whole Set of diagrams Detailed description of each use case - Set of user-interface sketches/prototypes for each actor l Supplementary requirements specification for requirements not specific to a use case Use cases drive use-case realization in analysis and design and test cases in testing