How to effectively gather Software Requirements and manage them
Download as PPTX, PDF1 like39 views
The document outlines the importance of well-defined software requirements, emphasizing their role in the success of software development. It describes various attributes of requirements such as uniqueness, traceability, and priority, and introduces the SMART criteria for creating effective requirements. The document also discusses common problems related to ambiguous requirements and suggests solutions, including the use of automated testing and requirement management tools.
How to effectively gather Software Requirements and manage them
- 1. SOFTWARE REQUIREMENTS REQUIREMENTS ARE KING BETTER REQUIREMENTS= BETTER SOFTWARE
- 2. WHAT IS A REQUIREMENT ISO/IEC/IEEE • Statement which translates or expresses a need and its associated constraints and conditions Wikipedia • Singular documented physical and functional need that a particular design, product or process must be able to perform A requirement is a statement of: 1. What a system must do (functional requirement) 2. How well the system must do what is does (quality or performance requirement) 3. A known resource or design limitation (constraint) More generally. A requirement is anything that drives a design choice
- 3. MAIN REQUIREMENT ATTRIBUTES • Unique ID: Each requirement needs to have a unique identification number assigned to it, so that we can easily find it and link it to its business objectives and test cases. • Date Created: Some requirements are identified at the beginning of the project, while others are added later. Knowing when a requirement was created allows us to precisely trace when and where it originated; this can provide valuable information for prioritization and change management. • CurrentVersion: It’s common for a requirement to morph into something completely different as it is analyzed. Unless there is a robust version control system in place, we cannot guarantee that everyone will work with the same version of a requirement.The requirement version number can be used for flagging different versions of the same requirement to prevent confusion. • Requirement Author: Indicates who proposed a requirement. • AssignedTo:The ability to gain an indication of who has been assigned which requirement to implement, can facilitate improved balancing of overall workload and lead to increased productivity in the entire team. • Requirements Status: Has the requirement already been implemented or is it just at the stage of proposal? There is no point working on requirements that are yet to be reviewed and approved by key stakeholders. • Priority: Not all requirements are made equal. Some have much higher priority than others, and we should be able to see which ones are the most important and which ones can be deferred to a later release.This attribute provides an indication of which requirement should be implemented first. • Risk:This attribute seeks to answer the following question:What’s at stake if the requirement isn’t implemented? • Stability: Before we start working on a requirement, we should confirm that it has reached a certain level of stability. Developing software based on requirements that are subject to constant change is not efficient and is far from productive. • Stakeholders:This attribute indicates who will be affected should any changes be made to a requirement.
- 4. DEVELOP SMART REQUIREMENTS • Specific: clearly states what is required • Measurable: to confirm hen it has been met • Attainable:Appropriate/Can be done(technically possible) • Realistic: Relevant/reasonable • Time-Bound: Achievable within acceptable timeframe
- 5. SMART DEFINITION: SPECIFIC • Specific requirements are precise: • Are not open to interpretation • Avoid absolutes (ex.“all”, ”never”, ”always”) The document will contain all customer information: • Which document? • What customer information? • What format(s)? The Declaration document shall contain this customer information in a text block in the top right corner of the first page: • Customer Name • Phone • Email Poor Improved
- 6. SMART DEFINITION: MEASURABLE • Measurable requirements can be verified as complete : • Avoid undefined time periods/quantities • Avoid non-fact based measurements such as “best” or “optimal” The application shall function quickly for end users: • How quickly (seconds, minutes, hours)? • Which application features are included? • Which users are affected – guests, administrators, everyone? The application shall have response time of 4 seconds or less for all the features and for all the user roles, during business hours of 9 AM ~ 5 PM, Monday ~Friday Poor Improved
- 7. SMART DEFINITION:ATTAINABLE • Attainable requirements are able to be achieved given the existing environment: • Appropriate for project/limitations • Realistic to achieve within project parameters The monthly cycle will be run on the last Friday of he month, between 7 PM to 8 PM: • Has this been verified to be possible? • What if he cycle runs longer than 1 hour? The monthly cycle will be run on the last Saturday of the month. Starting 7 AM and completing by 7 PM Poor Improved
- 8. SMART DEFINITION: REALISTIC • Specific requirements are relevant: • Appropriate in context with other requirements • Consider other related project constraints. The new website will generate overs 1,000,000 hits within its first 12 hours of implementation: • Is this likely/necessary to occur? • Is there a better way to measure this outcome? The new website shall be ranked within the first results page on three major search engines (Google, Bing andYahoo) within its first 12 hours of implementation. Poor Improved
- 9. SMART DEFINITION:TIME-BOUND • Time-Bound requirements are timely: • Clarify how quickly a requirement needs to be finished , executed or implemented. • Avoid vague time references such as “ fast”,“quick” or “soon”. System availability will be achieved soon after the cycle is completed: • How soon (seconds, minutes, hours)? • What if the cycle is late? System availability shall be achieved after the cycle completion and by no later then 6 AM on Mondays~Fridays. Poor Improved
- 10. WHAT MAKES A GOOD REQUIREMENT? • A good requirement states something that is necessary, verifiable, and attainable • Good requirements should have the following characteristics: • Complete • Consistent • Correct • Modifiable • Ranked • Traceable • Unambiguous • Understandable • Testable
- 11. WHAT ISTHE PROBLEM WITH REQUIREMENTS? • Though many techniques exits, most are written in ambiguous natural language • The requirements are “static”- they offer no way to derive tests directly from them • No way to update tests when the requirement change – this has to be done manually
- 12. AMBIGUOUS REQUIREMENTS • A system can be build around misunderstanding, so that: • At least 56% of defects stem from ambiguity in requirements- some place this as high as 59% or even 65% • 64 % of total defect cost originate in the requirement analysis and design phase- some place this as high as 80% • 40~50% of project costs are expended in rework • On average, only 69% of desired functionality is actually delivered
- 13. POSSIBLE SOLUTIONS • Identifying possible use cases • Mapping requirements to an unambiguous, active flowchart • Auto generate test cases and automated tests- no more hops • Manage requirement changes
- 14. IDENTIFYING USE CASES • A use case specifies all possible scenarios for a given piece of functionality
- 15. MODEL REQUIREMENTS AS AN “ACTIVE” FLOWCHART 1. A formal model that us accessible to the all 2. Precise so that it eliminates ambiguity and incompleteness 3. It can be used by testers ,developers and other stakeholders
- 16. AUTOMATED TESTS • Test cases can be auto generated or regenerated from requirements • Automated tests are generated from test cases • They are optimized to provide 100% coverage in fewer tests • Includes negative and future scenarios • Pallet-based UI automation • Exhaustively test the application • Are updated for the requirement changes
- 17. MANAGE REQUIREMENT CHANGES • Creating a requirements baseline • Manage versions of requirements documents • Adopt a change control process • Perform requirement change impact analysis • Store requirement attributes • Prioritize and track the status of each requirement • Trace requirements into design, code and tests • Store requirements in a requirement management tool
- 18. For more information please visit Thank You! https://thexlearn.com/ THEXLEARN.COM