9.RequirementConcepts1

9.RequirementConcepts1 - Requirements Analysis I Book: Use...

Info iconThis preview shows page 1. Sign up to view the full content.

View Full Document Right Arrow Icon
This is the end of the preview. Sign up to access the rest of the document.

Unformatted text preview: Requirements Analysis I Book: Use Cases Requirements in Context Second Edition Bookl: RUP Chapter 9 The Requirements Discipline From Article: "The Role of Requirements Traceability in System Development" by Dean Leffingwell, copyright: Rational Software, 2002. h ttp://www.therationaledge.com/content/sep_02/m_requirementsTr 1 Traditional Activities Typical development activities include: business modeling requirements gathering, analysis and design, construction, testing, deployment and maintenance. Business modeling Requirements gathering Testing Deployment Maintenance Frequently given lip service: 2/37 Landscape of Requirements Perception changing from only emphasizing big three: Analysis, design, and construction Increasing Realization of criticality of Business Modeling and Requirements their verification and traceability. More projects fail due to poor requirements specification and poor requirements management than for any other reasons. that is, Changing Requirements and their management 3/37 and scope creep usually `not formal' but everpresent! Requirements: Difficult to Capture Sometimes done by BA (Business Analysts); sometimes done by System Analysts But not always! Sometimes done by developers with much input from BAs (know the environment) and SAs and others. Typically developers have limited knowledge of application domain. Developers often have difficulty communicating with Business Analysts and others. Sometimes (especially BAs)they have difficulty in mapping abstract "needs" to "features" understandable by developers... 4/37 Landscape of Requirements Often developers don't like to spend lots of time here (we should, but we don't) "Takes too long" Developers like to plod on (often operating under false assumptions). In fairness: Requirements can take the form of huge requirements lists (See OOSE book) Horribly boring Difficult to discern critical needs from desires. Requirements may sometimes be dictated by a single person (depending on size of application, this may not be good! You will get `that' person's views and biases. 5/37 Goals of Requirements Discipline To establish and maintain agreement with the customers and other stakeholders on what the system should do and why. To provide systemdevelopers with a better understanding of the system requirements To define boundaries (delimit) of the system To provide a basis for planning the technical contents of iterations To provide a basis for estimating cost and time to develop the system (RUP Chap 9) 6/37 Functional and NonFunctional Requirements Functional requirements are what the users need for the system to work. Nonfunctional requirements (Quality attributes) "Need to add, change and delete transactions" "Need to generate `this' report and `that' report..." System must be able to do `these' things. System must be learnable; have utility; be usable!! Items like performance, scalability, usability, supportability, reliability, security, backup/recovery... Normally documented: Supplementary Specifications Vitally important (sometimes hidden); global 7/37 Functional Requirements Merely something that the computer application does for its users. A value or feature! Functional requirements are used to express the behavior of a system by specifying both the input and output conditions that are expected to result. Sum of requirements => scope of application Add requirements? Scope increases... Scope creep! (Discuss...) Requirements indicate specific system responses to user inputs (behaviors; interactions). 8/37 NonFunctional Requirements Nonfunctional `quality' attributes of system. Usability Reliability Human factors aesthetics, ease of use, learning; consistency in the user interface; training, ... Addresses the frequency and severity of failure; recoverability, MTBF, MTTR, etc. Transaction rates/speeds, availability, response time, recovery time... Testability, maintainability, ... Application is protected from unauthorized access. (or parts of it) 9/37 Performance Supportability Security Not tied (normally) to specific functions but vital! Often thread many requirements. Requirements Artifacts Inputs: From Business Modeling Outputs: Requirements Artifacts Software Requirements Specification (SRS) Produced: Contains Needs and Features. Business Models (Business Vision document, Business Use Case; Business Object Models; Domain Model, Risks Lists, Business Rules, etc.) Product Vision Document (application to be developed) Functional Specifications as captured in the Use Case Model (Use Case Diagrams and Use Case Specs) Supplementary Specifications (local conventions ways or procedures for doing things) Nonfunctional requirements, and a number of other things Schedule, ROI, Anticipated conversions, etc. 10/37 The Pecking Order So HOW do we elicit and capture (model) the Requirements? Let's go backwards: Specific requirements (captured via `stories' in Use Cases and `text' and in Supplementary Specifications) are identified and captured to support a given Feature / Features which are captured as Stakeholder Needs in the Vision document for the Application. Thus we have a mapping: Needs Features Use Cases / Supp Specs 11/37 12/37 Traceability Can see that we have a `traceability relationship.' Needs Captured Needs (already discussed) obtained from Stakeholders must TRACE to specific Features (functional requirements) which map (trace to) to specific requirements as captured via `stories' in Use Cases and the Supplementary Specifications. A Need may be `fulfilled by' or is `part of' or some kind of feature, etc. So, such traceability relationships (much in the literature!) are essential to developing quality applications and to assure stakeholder needs are indeed accommodated in the resulting application. 13/37 Product Vision Document Complete vision of software under development Basis for funding authority and development organization. Written from customer's perspective focusing on essential features and quality. Includes `what' will be included Captures User Needs and Features. Specifies operations and characteristics Is the Contractual basis for the requirements visible to the stakeholders. 14/37 Volumes, response times, user profiles, interfaces with other systems. Functional Specifications captured in the Use Case Model / Specification Concentrates on the functionality of system Can serve as a contract among the customer, users, and developers Consists of Use Case Diagrams, Use Case Specifications (that is, the usecases themselves sometimes called the usecase narrative or usecase description...), and Actors Use Cases serve as the unifying thread throughout the software lifecycle and drive analysis, design, implementation, testing, iteration planning, software architecture, interface prototype development, and a host of additional activities. (This is a very important concept) Recall: The RUP is `usecase driven......' 15/37 Supplementary Specifications Normally a text document citing the `abilities' required, such as Usability, Scalability, Maintainability, Efficiency, Reliability, Portability, etc. Sometimes considered as constraints on design! Good!! Glossary (from Domain Analysis) extended Domain Model (from Domain Analysis) extended / modified Storyboards (serve as basis for User Interface Prototypes) developed from Use Cases. May include much more local policies too... Typically developed `in parallel' with other requirements activities. 16/37 May also include: Prelude to Work Different projects develop different artifacts. Can be organized in very different ways. But in general, projects are developed in response to user and other stakeholder needs. Considerable time must be spent on eliciting these needs. It is a simple imperative that developers MUST understand the stakeholder needs. Start with Stakeholder NEEDS 17/37 Stakeholder Needs Eliciting Stakeholder needs may arise from a variety of sources, as explained in the past. Questionnaires, Interviews, Quarterly Reports, Newsletters, Web pages, Annual Reports; Stockholder reports; Consortia of corporations, etc. are but a few. The list is rather endless. Let's look at a few. 18/37 Standard Approaches (1 of 5) User Interviews: Try to learn how users do their jobs now, how they expect their jobs to change, and typical problems they encounter now. Interview different people at different levels note biases / conflict We get `their' perspective Customer, enduser, client, etc... User Questionnaires lots of pros/cons. Many `types' and ways to administer... Lots of philosophies on creating types of questions openended, closed, etc., and methods to evaluate the responses (if any...) 19/37 Standard Approaches (2 of 5) Joint Requirements Planning Sessions (JRPS) Conduct all interviews at same time in same room. All key people brought together. Have facilitator, scribe, projectors, and support software... Focus is on WHATs of the system Have representatives of all key stakeholders Highlevel topics (in JRP) are first: critical success factors, strategic opportunities, vision, risks, business rules, ... Functional/nonfunctional requirements identified, documented, and prioritized together!! OWNERSHIP!! Often conducted offsite. Artifact: the document produced: a list of requirements. 20/37 (List? Ech!) Standard Approaches (3 of 5) Requirements Lists Functional Specifications Problems with Requirements Lists Most people detest requirement lists! Replace with Use Case Specifications, Use Case diagrams, and business rules. Not always replaceable: Requirements lists are sometimes used at very early stages for stakeholders and clearly differentiating sub requirements (alternatives, exceptions, ...) Review sample requirements lists: pp. 1719. 21/37 Standard Approaches (4 of 5) Prototypes Pros: Very popular in mid 1980s Are mockups of screens and/or windows Primarily used do define user interfaces which implies functionality!!! Great userinterface prototyping tools available e.g. VB, dynamic HTML, JavaScript, XML etc. are super for UI capture. Extremely conducive to communications between user groups and developers. Early changes to screens set stage for fewer changes later and reduced overall costs! Greatly facilitates stakeholder acceptance later... 22/37 Standard Approaches (5 of 5) Prototypes Cons: But, some pay more attention to screen than to functionality. Executives sometimes fail to realize that prototype is not a working system. Want it right away A throwaway Get buyin on the throwaway unless the development strategy (small systems) is to hone the prototype into a compliant application). Prototypes imply more is `done' than is done. Only represent front end (presentation) and do not usually represent the business rules. up front At best (but very good!) a great way to determine the user interface specification. 23/37 Recall: Sample Statement of Need "The system will allow students to register for courses, and change their registration, as simply and rapidly as possible. It will help students achieve their personal goals of obtaining their degree in the shortest reasonable time while taking courses that they find most interesting and fulfilling." (p. 107, OOSE) Note how `highlevel' and abstract this is. Very meaningful to the Stakeholder. 24/37 Map: Needs to Features Defining the features of a system that meets those needs of the stakeholders is the next step in the process. While performing this step, it can be helpful to continually relate the features of your proposed solution back to user needs. This may be accommodated using a mechanism (simple table) called a traceability matrix. 25/37 Traceability Matrix Leffingwell article Feature #1 Need #1 Feature #2 ... Feature #m x x x x x x Need #2 ... Need #n The Stakeholder needs are in the first column and the application features that we have defined to meet those needs constitute the columns. 26/37 Features are normally found in the Product Vision document for the Application. Traceability Matrix We put Xs in the cells under the features that we have defined to satisfy the stakeholder needs. Please note that this is a 1:n mapping, as there are far more features than explicitly stated Needs. Further, the Needs are at high levels of abstraction. Study the matrix carefully. No X under a feature? Perhaps Need is not mapped into feature(s)! Flag!! Features not traced back to a Need? Perhaps we have Features that are not traceable back to Needs! 27/37 Needs to Feature Mapping Maybe the Needs or Features are not clear! Too, we are not dealing with a lot of information here, so this traceability should be undertaken. Leffingwell: "Once you've mapped the need feature relationships and have determined that the needs and features are correctly accounted for and understood, it's time to consider the next level of the hierarchy: relationships between the features and the use cases." Coming... 28/37 Additional Informative Slides will not be covered in Class Included for your reading pleasure Read next few slides on your own... 29/37 Software Requirements Specifications (SRS) Given inputs from Stakeholder requests, we develop a Vision Statement Recognize that this vision statement contains features with related costs and anticipated ROI. Map these desired, highlevel features into software requirements from which the system can be developed. Thus develop a Software Requirements Specification (SRS). SRS consists of contains key stakeholder needs and highlevel features The SRS feeds / supports follow on design testing, and a host of other activities (see fig 91 in RUP) 30/37 Detailed requirements via Use Case Models and Use Cases (functional specs) Requirements that don't fit in well with Use Cases are captured in the Supplementary Specs (nonfunctional specs) Heuristics Requirements Analysis & Design (an `aside' comment) Requirements are the `WHATs' of an application. Design is the `HOWs' of an application. Desired functional and nonfunctional features. specific classes will be used. database / file system; Heavily architecturallyoriented artifacts, layers... platforms, middleware, programming language, networking approach, etc. Again, HOW do we, as developers, satisfy the `Whats' of the system? 31/37 Heuristics: Requirements and Design (aside comment #2) VERY different activities Require different mindsets; different people and skill sets. Requirements understanding the problem at hand Design solving the problem But MUCH more on design MUCH later on in this course. 32/37 Clearly, cannot design a solution until the problem has been identified, documented and understood! "...a software requirement that is `traced Traceability more to' a test case would suggest that the software requirement is "tested by" the test case that it is "traced to." "A Use Case Realization (later) that is "traced from" a use case would imply that the requirement is "implemented by" the reference collaboration (Use Case Realizations that is, design elements like classes, subsystems, etc.)." 33/37 Challenges of Requirement Gathering Some state: "Users do NOT know what they want." Sometimes this is very true; sometimes NOT. Users have lots on their minds besides your application!! Sometimes users won't commit to written requirements; Communication with users is often very low. Conflicts in performing today's job and in shaping a new system `resistance to change.' Best approach is to work so very hard at establishing personal relationships with users! So very essential! Requirements change dynamically...the more `seen' the more wanted! Remember: it is the users who must be satisfied! Real problems: we need to recognize the conflicts users have between their daily jobs and how you need that same `time' to help shape the developing system. 34/37 What to do? Understand the User's divided attentions... Establish a relationship with your users (again) Make project more visible Make it personal They will make more meetings, reviews, and answer more questions Escalate the importance of system to senior level executives, if possible If seniors are "aware," more likely users will attend requirement sessions, interview sessions, etc. Batch questions, interviews together... 35/37 Be respectful of others' time! More on Requirements Gathering and Specification Have reviews to avoid conflict Try to avoid conflicting requirements The larger the volume, the less likely project will succeed. Establish requirements traceability!! Requirements should be traceable throughout the effort back to the requirements specification. 36/37 Requirements Traceability Questions that should be answerable: Analyst/designer Where did this requirement come from? Developer What specific requirements does the class you're programming relate to? Executing this method satisfies what requirement(s)? Many more details on class contents (parameters...) Heavily architecturedependent; Oftentimes multiple components are needed to satisfy individual requirements. Within a class, what requirement does this method satisfy? Where is it specified? Tester When you execute this `test case,' what exact requirement / requirements are you testing for? Can you find it in the requirements specification? 37/37 ...
View Full Document

Ask a homework question - tutors are online