For anyone involved in software development, the importance of software requirements cannot be minimized. Software requirements provide the definition and explanation of “what the software should do” and “how the software should behave.” The software engineers and developers use the requirements as input to the software design and coding process. The test developers also use the requirements as input to test case development process – to essentially determine if the software has defective behavior. Well written and well thought out software requirements are typically the start of a high quality software system.
But have you ever considered the “life” of a software requirement? It can be helpful to use a software requirement lifecycle to track the software development and test development process. For example, after leaving the “new” state, the requirement might initially achieve “draft” state. This state might be used to solicit input from stakeholders. After incorporating feedback, the requirement might be set to a “ready for dev” state. In this state, both test development and software development would begin. Once the software developers completed design, coding, and unit verification, the requirement would be set to the “ready for integration” state. The test developers would then begin to execute integration and software system level test cases. As the software associated with a given requirement passes these test cases, the test developers would set the state to “ready for validation.” Achieving this state would be a clear indication that all verification activities for that requirement are complete. The software team is communicating that they believe the software to be of the quality agreed to in the Software Development Plan.
Obviously the state can be set to a previous state at many points in the process. For example if the software engineers or test developers find issues with the “ready for dev” requirements such as vagueness, conflict, or confusion, they could return the state to “draft”. Or if the test developers find software defects associated with “ready for integration” requirements, they could return the requirement(s) too “ready for dev”, flagging the software developers that they must investigate. Depending upon the overall SDLC and the stage of development, one might also create a bug or defect ticket as well.
Requirement lifecycles can be an effective method to help ensure quality and helpful project management information. One might also consider other attributes of requirements that can help overall software quality such as safety risk level and product lifecycle (e.g., deployed).
See some of our other posts related to requirements:
https://www.softwarecpr.com/2019/08/fda-expectations-for-requirements/
https://www.softwarecpr.com/2018/12/scpr-62304-82304-requirements-comparison/
