A Use Case-Driven Approach to Requirements Gathering.ppt

1、1/12,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/12,Guiding Principles to Requirements Gathering,Reduce Risk Focus on business interactions Reduce volume

2、 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/12,Approaching Function Requirements,Many think

3、the Requirements Specification (Software Requirements Specification SRS in the RUP) this is the first document. It really isnt!For the Business: Only if the business analysis (business case) is well defined, the business environment, business vision, a domain model, business rules, risks, informatio

4、n 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, organizations vision, mission, values, etc. are captured along with a stro

5、ng 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 l

6、evel 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/12,Statement of Work,Prior to the real be

7、ginnings 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 Dat

8、a 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 cust

9、omer. See textbook for details. It is generally more than just bullets can be bullets, but should have more assignment details,5/12,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 m

10、ay not lend themselves to automated solution.Systems Analyst: Translates these Needs into Features that can be accommodated by an application (s).,6/12,Side note: Hundreds of Other Methodologies,Many and varied. All meet needs for different types, sizes, complexities of applications. Lightweight ver

11、sus 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 mot mutually exclusive,7/12,Requiremen

12、ts 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 applica

13、tion. Even when you have them, you probably dont. 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/12,Capture Requirements: Use Cases Our tool, The Use Case model is at the conceptual c

14、enter 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

15、 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. Mu

16、ch more later Discuss. Definition of the RUP!,9/12,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 pre

17、sent tense very in active voice. VERBOBJECT 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 Narrativ

18、e (Use Case Scripts) (Use Case Specifications),10/12,Warning, “Whether you use prototyping, screen mockups, or the results of mining legacy user manuals, its important that you do a thorough job to understand end-user requirements before you start writing use case text. If you dont, you could end up

19、 spending a lot of extra time trying to pin down what your users expect to be doing with the new system.”Dont 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 pro

20、totypes (also domain model) at the same time or near the same time, in that they can act as checks (validation) on each other.,11/12,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 in

21、teractions. 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 no

22、rmally documented in a Supplementary Specification Document Good for ensuring requirements traceability because they are used for design, testing, construction, delivery, and .,12/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 designingSTOP! Remember: these are still the WHATS of the application!,