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 •  Leavedesign until later • Keep the plan in mind.

3. Approaching Function Requirements • Many think the Requirements Specification (Software Requirements Specification – SRS in the RUP) this is the first document. It really isn’t! • For the Business: Only if the business analysis (business case) is well defined, the business environment, business vision, a domain model, business rules, risks, information pertinent to the organization, stakeholders, etc. are defined and understood, can we proceed to identify requirements for an application. • All the organizational parameters: technologies available, environmental constraints, organization’s vision, mission, values, etc. are captured along with a strong modeling of the organization and its information structures (domain), etc. can we proceed into capturing the details of requirements. • For the Application: When the stakeholder needs for an application are known – and captured by business analysts, and only when the systems analyst takes these high level needs and converts them into ‘features’ to be accommodated by an application, - then, and only then can we proceed into capturing the real, detailed functional and non-functional requirements. At this time, requirements are very high level and abstract.

4. Statement of Work • Prior to the real beginnings of the application development, a Statement of Work (or similarly entitled document) is developed. • 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. • Sometimes we have a DPP (a Data Project Plan – WHAT is going to be done, schedule, etc.) and a DPD (Data Project Directive – who is going to do what.) • Sometimes this is all called the Software Development Plan (RUP) • 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…

5. A Couple of Terms • Some initial key roles: • Business Analyst: Captures the Needs of the business from a variety of stakeholder perspectives. • These needs may be many and may not lend themselves to automated solution. • Systems Analyst: Translates these Needs into Features that can be accommodated by an application (s).

6. Side note: Hundreds of Other Methodologies • Many and varied. • All meet needs for different types, sizes, complexities of applications. • Lightweight versus Heavyweight Processes (methodologies) • Lightweight - Many • Scrum, Extreme Programming, Agile Processes • Working Software > documentation; heavy user involvement, smaller teams, … • Heavy-weight methodologies - Many • SDLC, RUP, Spiral, Others… • Plan-driven, larger teams & projects, more effort on formalizing design, more modeling, … • Some have features of both; mot mutually exclusive…

7. Requirements Evolve… • Requirements evolve from the abstract to the very concrete... • Requirements may well arise (should be!!!) derived from a variety of stakeholders to avoid biases!!!! • When undergoing capture and development, Requirements will change frequently due to reliance on other peoples ideas about the application. • Even when you have them, you probably don’t. • It is likely they are incomplete. Only be detailed and locked in when starting a specific iteration, such as in Construction. • We will use tools and a lot of work…

8. Capture Requirements: Use CasesOur tool… •  The Use Case model is at the conceptual center of the entire approach because it drives everything else that follows. • Should follow the existence of a good, solid domain model and identification of features the application is to accommodate. • Use Case development drives Analysis (preliminary design) • Drives Design Modeling – refine analysis model into a detailed design model using objects identified in creating the analysis model. • Drives Testing! •  Requirements Tracing – involves tracing features to specific interactions via use cases. (Needs to Features to Use Cases to Analysis Modeling elements to …) • Use Cases drive entire development effort. Much more later… • Discuss. Definition of the RUP!!

9. Use Cases • Use Cases are sequences of actions that an actor (usually a person, but certainly can be an external entity like another external system or a device) performs with an expectation of achieving a particular result; gets value. • Always use present tense very in active voice. VERB…OBJECT in naming a Use-Case: Maintain User Status, Generate xxx. • Model Requirements: • Use Case Diagrams • Use Case Specifications • Diagram is only a graphical model associating Use Cases with actors. •  Capture Use Cases (that is, the interactions) via Use Case Narrative (Use Case ‘Scripts’) (Use Case Specifications)

10. Warning •  “Whether you use prototyping, screen mockups, or the results of mining legacy user manuals, it’s important that you do a thorough job to understand end-user requirements 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.

11. 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 much 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 Specification Document… • Good for ensuring requirements traceability – because they are used for design, testing, construction, delivery, and ...

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