How to effectively gather Software Requirements and manage them

The content describes how to manage software requirements well. It helps the project managers and software engineers to gather good requirements and deliver better. The main issue in requirement gathering is ambiguous requirements and not managing requirements changes well. This presentation give basic guideline to take care of these issues.

1. Software Requirements Requirements are King Better Requirements= Better software

2. What is a Requirement A requirement is a statement of: What a system must do (functional requirement) How well the system must do what is does (quality or performance requirement) 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. Current Version : 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. Assigned To : 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 S pecific: clearly states what is required M easurable: to confirm hen it has been met A ttainable: Appropriate/Can be done(technically possible) R ealistic: Relevant/reasonable T ime-Bound: Achievable within acceptable timeframe

5. SMART Definition: Specific Specific requirements are precise : Are not open to interpretation Avoid absolutes (ex. “all”, ”never”, ”always”) 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” 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 Poor Improved

8. SMART Definition: Realistic Specific requirements are relevant : Appropriate in context with other requirements Consider other related project constraints. 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”. 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 is the 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 A formal model that us accessible to the all Precise so that it eliminates ambiguity and incompleteness 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