This preview shows page 1. Sign up to view the full content.
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.
View Full Document
- Spring '08