A Use Case-Driven Approach to Requirements Gathering

1. A Use Case-Driven Approach to Requirements Gathering Materials gathered from Chapter 3 (above) – Kulak and Guiney and Use Case Driven Object Modeling – Doug Rosenburg and other personal notes.

2. Guiding Principles to Requirements Gathering • Reduce Risk • Focus on business interactions • Reduce volume • Reduce duplicates and inconsistencies • Create requirements that users can understand easily • Create requirements that are useful to designers, developers, and project managers • Leave a requirements trail • Leave design until later • Keep the plan in mind.

3. Mission, Vision, Values • Many think this is the first document. Arguable. But certainly worth thinking about: • Vision: What will the end product be? • Future. Vision of operations and filling needs… • Mission: What will with project do? • Immediate; now. How will it work? Will it fulfill the needs of the stakeholders? • Values: What principles will guide the project while they do what they will do and build what will be… • What principles underpin what we do? Organization; seeking quality products; integrity; communications, etc.

4. Steps in Gathering Requirements • Requirements are created iteratively. • Iteration means doing things over and over; enriching the value of the artifacts, etc. • Increments refer to the gradual, piece by piece evolution of the application; building on earlier work. • Requirements specs will change frequently due to reliance on other peoples ideas about the application. • other artifacts may tie back to requirements, • sometimes only tie back to fuzzy ideas.

5. Steps • We consider the Vision Document (which might include Mission, Vision, Values, and a host of other items, such as scope, objective, overview, user demography, constraints, assumptions, staffing, costs, environment, etc.) as a primary step. • This defines the scope and general overview of work to be accomplished. • All these documents tied to vision and initial business modeling include risk analyses, business rules, etc. • These are essential artifacts.

6. Steps - continued Steps - continued • Prototype • Used to identify the user interface – NO MORE! • Will identify requirements missed. • Recognize emphasis is on requirements not the specific widgets (buttons, etc.) used. • These are implementation details which will be decided upon later.

7. Steps: Use Case - Driven • The Use Case model is at the conceptual center of the entire approach because it drives everything else that follows. • Oftentimes developed in conjunction with Domain Model because the text of the Use Case supports development of the Domain Model. • Helps to identify nouns (entities and attributes) and verbs (responsibilities) • Drives Analysis Model (preliminary design) • Drives Interaction diagrams (ahead) – refine analysis model into a detailed design model using objects identified in creating the analysis model and showing how messages flow between objects within use cases. • Requirements Tracing – involves connecting user requirements with use cases and classes. • Use Cases drive entire development effort. • Discuss.

8. Use Cases: • Use Cases are sequences of actions that an actor (usually a person, but certainly can be an external entity like another system or a device) performs with an expectation of achieving a particular result; gets value. • Always use present tense very in active voice. • Model Use Cases via Use Case Diagrams • Capture Use Cases (that is, the interactions) via Use Case Narrative (Use Case ‘Scripts’)

9. Let’s review and add some detail:

10. Early Deliverables • Most efforts start with a Business Modeling effort (domain analysis) and the capturing the Domain via Domain Modeling, Glossary, and associated artifacts . • Related artifacts typically include some kind of vision document that include: • Risk Analysis (may be included in Vision Document or as an adjunct artifact) • Business Rules (see textbook page 61-62) for more examples. • Vision Statements – short encapsulating statements outlining ‘vision.’ • Environmental Constraints and more… • There are a number of approaches… •  Most uses cases are defined during the same iteration •  Typically a first cut of key use cases may be developed as part of the Inception Phase – generally around 20% of use cases (key ones) • But they are refined via subsequent iterations to provide increasing levels of detail • These details are absolutely required to drive the entire development process.

11. Statement of Work • Most development projects have some kind of Statement of Work (SOW) How the work is going to be accomplished – work plans, assignments, internal deliverables, etc. • Represents a contract between the developers and the users and/or a contract between a consulting company and the customer. • See textbook for details. • It is generally more than just bullets – can be bullets, but should have more ‘assignment’ details…

12. Risk Analysis • A list of risks that may impact the successful development of the application. • You now need to revisit these and prioritize by impact. (probability of occurrence * cost if occurs); other formulas • Provides data as to whether the development effort should start/proceed. • Risk MUST be addressed and mitigated. • Risk is consistently re-addressed as part of assessment following every iteration

13. Business Rules Artifact • Business Rules are both written and unwritten rules that govern how the company does business. • relate to the specific application only • Examples: discounts to seniors; discounts if order is > some magic number; corporation discounts; … • We use use cases and business rules very closely. • Use Case templates should have a Business Rules ‘attribute’ (row) that cites ‘references’ to any business rules that is associated with the use case • While Use Cases address the functional requirements by covering interactions between the client and the application, these interactions are often governed by business rules that dictate the environment and constraints within which the application operates.

14. Closer Look on Business Rules • May be conditions that must be true/false • Action restricting – conditions prohibiting an action (don’t accept a bad check…) • Action triggering • Inferences – drawing a conclusion from conditions that may be/become true • Calculations – formulas / discounts. etc. • Must be atomic!! • means must be stated at the finest level of granularity possible. • As stated: see Use Case textbook, Table 3.3, p. 61 for examples.

15. Prototype • Mock-up of user interface. Storyboarding… • Graphical or pictures clearly and perhaps interactively. • Introduced now; refined later after the requirements have stabilized a bit. Avoids temptations to proceed solving problems before they are understood. • Prototype demonstrates a ‘proof of concept’ • It also forms the rough basis for a user manual – as if the prototype were a working system… • Prototype should be ‘rapid.’ • Means ignore many alternatives (exceptions…) • After closure on screens/windows, this greatly facilitates locking in the Use Cases that ‘realize’ descriptions of the interface just demonstrated. • Also greatly facilitates identification of boundary objects (along with Use Cases) for our analysis modeling effort (preliminary design).

16. Prototype • Prototype can be simple. • Generic symbols (buttons may later become drop down menu….not terribly important at this time.) • Should contain some kind of windows navigation diagrams and perhaps action resulting in navigating to a new menu/window. • Can link your screen designs to your use cases – either manually or in context of a visual - modeling tool • Coupling between screens and text is intuitive…. • Be careful: Your use case text (coming) should not include too many presentation details, since these are design considerations, and we are really trying to lock in requirements – not show implementation.

17. Warning • “Whether you use prototyping, screen mockups, or the results of mining legacy user manuals, it’s important that you do a thorough job before you start writing use case text. If you don’t, you could end up spending a lot of extra time trying to pin down what your users expect to be doing with the new system.” • Don’t try to write use cases until you know what the users will actually be doing!! • Great way to learn this is through user interface prototyping. •  Note: some advocate building use case text and prototypes (also domain model) at the same time or ‘near’ the same time, in that they can act as checks (validation) on each other.

18. Role of Use Cases • The Use Cases are clearly the major artifacts of Requirements Gathering efforts. • Use Cases – great for communications • contain the essence of desired interactions. • no jargon as found in DFDs, ERDs, etc. • Particularly good for Functional and to a lesser degree (in some cases) non-functional requirements. (performance, extensibility, maintainability, backup, recovery, security, persistency, distribution, etc.) But these latter requirements are normally documented in a Supplementary Specs document… • Good for ensuring requirements traceability – because they are used for design, testing, construction, delivery, and ...

19. Role of Use Cases • When used to drive the lifecycle, they assure stakeholders that all use cases are being addressed in the development effort. • Use cases discourage premature design. If the use cases narrative has several steps before responding to the user, this is a tip off that we are undertaking too much designing…STOP! • Remember: these are still the WHATS of the application!