Requirements Analysis I From Book Use Cases Requirements
Requirements Analysis I From Book: Use Cases – Requirements in Context Second Edition Book: RUP – Chapter 9 – The Requirements Discipline Article: “The Role of Requirements Traceability in System Development” – by Dean Leffingwell, copyright: Rational Software, 2002. http: //www. therationaledge. com/content/sep_02/m_require ments. Traceability_dl/. jsp 1
Traditional Activities n Typical development activities include: – – – – n business modeling requirements gathering, analysis and design, construction, testing, deployment and maintenance. Frequently given lip service: – – – Business modeling Requirements gathering Testing Deployment Maintenance 2/37
Landscape of Requirements n Perception changing from only emphasizing big three: – Analysis, design, and construction n Increasing Realization of criticality of – Business Modeling and – Requirements - their verification and traceability. n 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 ever-present!
Requirements: Difficult to Capture n Sometimes done by BA (Business Analysts); sometimes done by System Analysts - But not always! § Sometimes (especially BAs)they have difficulty in mapping abstract “needs” to “features” understandable by developers… n 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. 4/37
Landscape of Requirements Often developers don’t like to spend lots of time here (we should, but we don’t) n “Takes too long” n Developers like to plod on (often operating under false assumptions). n In fairness: n – – Requirements can take form of huge requirements lists 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 n n n To establish and maintain agreement with the customers and other stakeholders on what the system should do and why. To provide system-developers 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 6/37
Functional and Non-Functional Requirements n Functional requirements are what the users need for the system to work. § “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!! n Non-functional requirements (Quality attributes) § 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! n Functional requirements are used to express the behavior of a system by specifying both the input and output conditions that are expected to result. n Sum of requirements => scope of application – Add requirements? Scope increases… – Scope creep! (Discuss…) n Requirements indicate specific system responses to user inputs (behaviors; interactions). n 8/37
Non-Functional Requirements n Non-functional ‘quality’ attributes of system. – Usability – § Human factors – aesthetics, ease of use, learning; consistency in the user interface; training, … – Reliability § Addresses the frequency and severity of failure; recoverability… – Performance § Transaction rates/speeds, availability, response time, recovery time – Supportability § Testability, maintainability, … – Security § Application is protected from unauthorized access. (or parts of it) n n Not tied (normally) to specific functions – but vital! Often thread many requirements. 9/37
Requirements Artifacts n Inputs: From Business Modeling – Business Models (Business Vision document, Business Use Case; Business Object Models; Domain Model, Risks Lists, Business Rules, etc. ) n Outputs: Requirements Artifacts – Software Requirements Specification (SRS)- Produced: – Product Vision Document – (application to be developed) § Contains Needs and Features. – 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) - Non-functional requirements, and a number of other things – Schedule, ROI, Anticipated conversions, etc. 10/37
The Pecking Order n So HOW do we elicit and capture (model) the Requirements? Let’s go backwards: – Requirements (captured in Use Cases and in Supplementary Specs) are identified to support a given Feature / Features 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 We have a ‘traceability relationships. ’ – Needs – § Captured Needs (desires) 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 n n n 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 – Volumes, response times, user profiles, interfaces with other systems. n Is the Contractual basis for the requirements visible to the stakeholders. 14/37
Functional Specifications captured in the Use Case Model / Specification n Concentrates on the functionality of system n Can serve as a contract among the customer, users, and developers n Consists of Use Case Diagrams, Use Case Specifications (or use case narratives or descriptions) and Actors n 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) 15/37
Supplementary Specifications n Normally a text document citing the ‘-abilities’ required, such as – Usability, Scalability, Maintainability, Efficiency, Reliability, Portability, etc. – Sometimes considered as constraints on design! Good!! n May also include: – Glossary (from Domain Analysis) - extended – Domain Model (from Domain Analysis) – extended / modified – Storyboards (serve as basis for User Interface Prototypes) – developed from Use Cases. § Typically developed ‘in parallel’ with other requirements activities 16/37
Stakeholder Needs n Stakeholder needs may arise from a variety of sources, as explained in the past. n Questionnaires, Interviews, Quarterly Reports, Newsletters, Web pages, Annual Reports; Stockholder reports; Consortia of corporations, etc. are but a few. n The list is rather endless. n Let’s look at a few. 17/37
Standard Approaches (1 of 5) n User – – – n 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, end-user, client, etc… n User Questionnaires – lots of pros/cons. – Many ‘types’ and ways to administer… Lots of philosophies on creating types of questions – open-ended, closed, etc. , and methods to evaluate the responses (if any…) 18/37
Standard Approaches (2 of 5) n 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 – High-level topics (in JRP) are first: critical success factors, strategic opportunities, vision, risks, business rules, … – Functional/non-functional requirements identified, documented, and prioritized together!! OWNERSHIP!! – Often conducted off-site. – Artifact: the document produced: a list of requirements. (List? Ech!) 19/37
Standard Approaches (3 of 5) n Requirements Lists – Functional Specs – 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 subrequirements (alternatives, exceptions, … 20/37
Standard Approaches (4 of 5) n Prototypes - Pros: – Are mock-ups of screens and/or windows – Often used do define user interfaces which implies functionality!!! § Great user-interface prototyping tools available – § 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… 21/37
Standard Approaches (5 of 5) n Prototypes - Cons: – But, some pay more attention to screen than functionality. – Executives may fail to realize prototype is not a working system. – Want it right away – A throwaway – Get buy-in on the throw-away – 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. 22/37
Statement of Need n “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) Very meaningful to the Stakeholder. 23/37
Map: Needs to Features n Define features of system that meets needs of the stakeholders. n While performing this step, it can be helpful to continually relate the features of your proposed solution back to user needs. n This may be accommodated using a mechanism (simple table) called a traceability matrix. 24/37
Traceability Matrix – Leffingwell article Feature #1 Need #2 … … Feature #2 x Feature #m x x x 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. Features are normally found in the Product Vision document for the Application. 25/37
Traceability Matrix (more) n n n 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 matrix. 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! 26/37
Needs to Feature Mapping Maybe the Needs or Features are not clear! n Too, we are not dealing with a lot of information here, so this traceability should be undertaken. n Leffingwell: “Once you've mapped the needfeature 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: n Relationships between the features and the use cases. ” n 27/37
Continue the Traceability Mapping n From the Product Vision Document for the Application, which contains the desired Features derived from Stakeholder Needs, we need to map the Features to Use Cases. n Consider the next two slides: 28/29
We continue with this figure – to the figure on the next slide… 29/29
This is what we are after…. Product Features, and more from Leffingwell’s article. This figure says a great deal!!! 30/29
- Slides: 30