A Use Case-Driven Approach to Requirements Gathering

1. A Use Case-Driven Approach to Requirements Gathering Materials gathered from chapter title (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. Four Steps in Gathering Requirements • Requirements are created iteratively. • Requirements specs will change constantly due to reliance on other peoples ideas about the application. • other artifacts may tie back to requirements, but requirements can only tie back to fuzzy ideas. • Author’s approach to use cases: • outlining, widening, focusing, touching up. • four ‘mind sets’ Not always all required. • Chapters 4-7 cover these in detail: façade, filled, focused, and finished. • Various authors use different ‘names’ for the evolution of use cases.

4. Use Case - Driven • The Use Case model is at the conceptual center of the entire approach because it drives everything else that follows. • Developed in conjunction with Domain Model • Drives Analysis Model (preliminary design) • Drives Interaction diagrams – 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.

5. Use Cases: • Use Cases are sequences of actions that an actor (usually a person, but perhaps 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 • Document Use Cases via Use Case Narrative or Use Case Description - Scenarios

6. Early Deliverables • Most efforts start with Business Modeling and capturing the Domain via Domain Modeling, Glossary, and associated artifacts most of which come from the Domain Modeling Discipline. • Related artifacts include: • Risk Analysis • Business Rules • Vision Statements • Environmental Constraints and more… • There are a number of approaches… • Most uses cases are defined during the same iteration • But they are developed via iterations that provide increasing levels of detail – required to drive the entire development process.

7. Statement of Work • 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 (p.57) for details. • It is generally more than just bullets – can be bullets, but should have more ‘assignment’ details… • I call the Statement of Work the Anticipated Deliverables. But Statement of Work is a more universally-accepted term.

8. Risk Analysis • A list of risks that may impact the successful development of the application. • Prioritized 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 in each deliverable in the SOW – particularly early on in the project.

9. 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. • 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.

10. More 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. • See Use Case textbook, Table 3.3, p. 61 for examples.

11. Prototype • Mock-up of user interface. • 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…) • Demonstration is great for locking in presentation aspects of requirements with users • After closure on screens, this greatly facilitates developing Use Cases that ‘realize’ descriptions of the interface just demonstrated. • Also greatly facilitates identification of objects (along with Use Cases) for our analysis modeling effort (preliminary design).

12. Prototype • Prototype can be simple. • Generic symbols (buttons may later become drop down menu….) • Can be boxes within boxes. • 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!!

13. 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!!

14. 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 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 more.

15. 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 has several steps before responding to the user, this is a tip off that we are undertaking too much designing…STOP! • These are still the WHATS of the application!