Part of Tecnova's requirements specification series -- helping businesses save money, time, and resources
So far in this series, we've looked at the benefits of good requirements, the consequences of poor ones, and the common flaws found in so many of them. As this series continues, we'll look at what it takes to create quality requirements for successful products or systems – ones that deliver all necessary functionality on time and on budget.
We may think requirements specifications need to be high grade As and Bs. But for truly effective requirements, it’s important to keep the Cs in mind: The 3 Cs of requirements specification -- correct, consistent, and clear.
Correct. Each requirement must accurately describe the functionality to be delivered, based on the viewpoint of the actual end users or stakeholders. It’s important that these users are involved in the process because only they can tell if the requirement is representing what they need.Further, every requirement must be written to describe a requirement of the product or system, and not the operator. Oftentimes this is a result of the wording of the requirement. For example, a requirement should not be written as “A user must turn off a switch in order to silence an alarm.” Instead, the more correct wording is, “The switch-changing state while the alarm is active controls the behavior in the system.”
Consistent. The requirement must not conflict with other requirements. Oftentimes when there are several people developing requirements, conflicts and inconsistencies can be created. Good requirements are in line with other software requirements and with higher level system or business requirements. Sometimes inconsistencies are hard to detect without further research, and other times they only appear as requirements are modified. It is common for specific changes to be addressed with one requirement without realizing how the change affects multiple related requirements, producing a domino effect of errors.
Clear. Finally, a requirements specification template must be written with absolute clarity, making sense to both technical and non-technical audiences. Sentences and paragraphs should be short and in the active voice. Multiple requirements should not be combined in one sentence. Terms should be used consistently and should be defined in an easy-to-find glossary.
Requirements expert Karl Wiegers suggests to check a requirements clarity by reading it from a developer’s perspective:
“Mentally add the phrase, ‘call me when you’re done’ to the end of the requirement and see if that makes you nervous. In other words, would you need additional clarification from the SRS author to understand the requirement well enough to design and implement it? If so, that requirement should be elaborated before proceeding with construction.”
If you are looking for assistance with achieving the 3 Cs of requirements specifications, look to Tecnova. Tecnova’s Requirements Specification Template is a hands-on tool for clearly communicating hardware and systems specifications. Download it here.
