Have you ever added the wrong ingredient to a recipe and spoiled the dish? The same can happen when you are writing requirements. Requirements are a critical part of the requirements management process and the foundation of good software. They are the ingredients that make a system great.
Writing good requirements is challenging; it requires skill and practice. However, it is a core competency for anyone tasked with writing test steps and test scripts and performing computer system validation (CSV) or applying computer software assurance (CSA). Validation tests a system to demonstrate that it performs as intended, and the intended performance is specified in the requirements.
In short, requirements are your future product, so getting them right and documenting them early in your requirements management plan (RMP) is key to better product quality, accelerated development, and less rework.
In recent years, development teams have used the Agile methodology to simplify and refine requirements writing. This approach is widely considered an improvement in the software development lifecycle (SDLC), replacing the traditional linear waterfall methodology.
Agile is an iterative practice; it breaks down large software development projects into smaller, more manageable tasks. Releases are more frequent, allowing users to see and contribute to the system as it’s being developed rather than waiting months or years before being able to use it. The Agile approach promotes transparency, better communication, and collaboration. It can help you translate user needs into well-defined requirements for a viable product or system.
Agile teams develop requirements and user stories, which are requirements expressed from the perspective of an end-user goal, in a more structured syntax. Here’s how requirements are decomposed in Agile:
It is often difficult to distinguish “must-have” requirements from “nice-to-have” requirements. Here’s a tip: Writing requirements using must, shall, and should statement qualifiers can help you deliver a compliant, fully functional system that even includes some nice-to-haves.
Aside from the structure and syntax of a user story, good requirements writing is a valuable skill to hone. Listed below are eight characteristics of a well-written requirement, as defined by The Institute of Electrical and Electronics Engineers (IEEE), as well as examples of poorly written requirements and how to correct them.
Incorrect: “Validation status flag shall be green (HEX 00b300) to indicate every failed test step.”
Correct: “Validation status flag shall be red (HEX FF0000) to indicate every failed test step.”
Ambiguous: “Indicator for fail shall stand out.”
Unambiguous: “Validation status flag shall be red (HEX FF0000) to indicate every failed test step.”
Incomplete: “Validation status flag shall be red.”
Complete: “Validation status flag shall be red (HEX FF0000) to indicate every failed test step.”
Inconsistent: “All FAIL flags shall be orange.”
Consistent: “All FAIL flags shall be red (HEX FF0000).”
Unverifiable: “All FAIL flags shall be red.”
Verifiable: “All FAIL flags shall be red (HEX FF0000).”
But there is something that has proven particularly useful in addition to IEEE’s recommendations, especially in highly regulated companies: using statement qualifiers.
When you elaborate on user stories, you end up in the traditional requirements elicitation and development realm — typically FRS and DS because URS is already addressed in the user story. The recommendation is to write your requirements using either must, shall, or should statement qualifiers, defined as:
Adhering to must, shall, and should requirement statements will allow you to read any requirement at any time and immediately understand its rank for importance and/or stability (characteristic #5 above). Furthermore, using statement qualifiers makes it easier to identify the required rigor in testing. During audits and inspections, you will be able to quickly identify regulatory requirements versus those that are nice-to-have.
There is another benefit. The word “must” will translate forward and backward in most languages without losing its meaning. “Shall” and “should” may lose their meaning when translated. This becomes more important with multinational organizations or systems that span geographies.
Advances in technology now allow organizations to manage requirements as records instead of documents. Managing requirements as records allows you to associate them within a relational database management system (RDBMS), which enables automation of tasks such as generating the requirements traceability matrix (RTM). Automating your RTM has many benefits.
The RTM maps and traces deliverables and test cases by establishing a thread for each requirement and test case from project initiation to completion. Some companies attempt to create the traceability matrix in Excel, which can be time-consuming and difficult to maintain. Unlike manual Excel spreadsheets, RTMs in ValGenesis automatically update, show coverage (or lack thereof), and reflect status in real time, including the impact of changes to requirements or test steps.
ValGenesis iVal™, part of the Validation Lifecycle Suite, empowers users to manage requirements within a library of reusable objects (requirements, test steps, etc.). This expedites document development and ensures consistency because requirements can be assessed once and reused across multiple systems.
Consider 21 CFR Part 11 requirements that apply consistently across computerized systems using electronic records and electronic signatures. Why not reuse the same requirements across systems?
iVal includes Design Manager, a purpose-built module that delivers Agile, iterative SDLC functions but also allows users to manage more traditional requirements (URS, FRS, DS). It supports epics, user stories, and iterative Agile development with the ability to move requirements to and from the backlog and manage development in sprints.
Design Manager also enables teams to better manage software and system development initiatives by estimating and tracking story points, which quantify development effort and time based on the organization’s unique structure and environment. Using story points, teams can track burndown and velocity to monitor progress across sprints and quickly identify when work is trending off track. If needed, teams refine the backlog, reprioritize work, and adjust scope or sprint plans. Course correction is easier and more controlled due to Agile’s iterative nature and structured backlog management.
ValGenesis iVal™ supports CSV, CSA, and Agile methodologies, as well as enhanced risk management capabilities.
Requirements can be developed using a traditional approach or an Agile methodology, including epics, user stories, story points, and burndown tracking. Users can manage risk at the requirement record level, and the system can automatically apply a risk framework based on outcomes. This framework can dictate which testing types to perform, including test modalities encouraged in CSA (ad hoc, unscripted, positive, negative, performance, security, boundary, scripted, white box, and black box testing).
The point is that you now have options. You can continue to perform traditional CSV or adopt and perform CSA. You can develop requirements using a sequential waterfall approach or apply an iterative Agile methodology. It’s up to you to decide what is best for your organization and your projects on a case-by-case basis.
Writing requirements is just one activity in the requirements management process, but it’s a critical one.
Requirements that adhere to IEEE characteristics (consistent, verifiable, traceable, etc.), use statement qualifiers (must, shall, should), and are captured in a requirements management plan help ensure overall project success.
Leveraging technology like ValGenesis iVal™ will further improve efficiency and effectiveness, including advances in validation methodologies (CSV vs. CSA) and SDLC practices (waterfall vs. Agile).
Watch the video below to learn more about ValGenesis iVal™.