Software Requirements Lifecycle

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/

About the author

Brian is a biomedical software engineer - whatever that is! Started writing machine code for the Intel 8080 in 1983. Still enjoys designing and developing code. But probably enjoys his garden more now and watching plants grow ... and grandkids grow!

SoftwareCPR Training Courses:

IEC 62304 and other emerging standards for Medical Device and HealthIT Software

Our flagship course for preparing regulatory, quality, engineering, operations, and others for the activities and documentation expected for IEC 62304 conformance and for FDA expectations. The goal is to educate on the intent and purpose so that the participants are able to make informed decisions in the future.  Focus is not simply what the standard says, but what is meant and discuss examples and approaches one might implement to comply.  Special deep discount pricing available to FDA attendees and other regulators.

3-days onsite with group exercises, quizzes, examples, Q&A.

Instructor: Brian Pate

Next public offering:  June 5-7, 2024
Boston, MA

Email training@softwarecpr.com to request a special pre-registration discount.  Limited number of pre-registration coupons.

Registration Link:

Register Now

 


 

Being Agile & Yet Compliant (Public or Private)

Our SoftwareCPR unique approach to incorporating agile and lean engineering to your medical device software process training course is now open for scheduling!

  • Agile principles that align well with medical
  • Backlog management
  • Agile risk management
  • Incremental and iterative software development lifecycle management
  •  Frequent release management
  • And more!

2-days onsite (4 days virtual) with group exercises, quizzes, examples, Q&A.

Instructors: Mike Russell, Ron Baerg

Next public offering: February 12-15, 2024

Virtual via Zoom

Registration Link:

Register Now

 


 

Medical Device Cybersecurity (Public or Private)

This course takes a deep dive into the US FDA expectations for cybersecurity activities in the product development process with central focus on the cybersecurity risk analysis process. Overall approach will be tied to relevant standards and FDA guidance documentation. The course will follow the ISO 14971:2019 framework for overall structure but utilize IEC 62304, IEC 81001-5-1, and AAMI TIR57 for specific details regarding cybersecurity planning, risk characterization, threat modeling, and control strategies.

2-days onsite with group exercises, quizzes, examples, Q&A.

Instructor: Dr Peter Rech, 2nd instructor (optional)

Next public offering:  TBD

Corporate Office

15148 Springview St.
Tampa, FL 33624
USA
+1-781-721-2921
Partners located in the US (CA, FL, MA, MN, TX) and Canada.