Part of Tecnova's requirements specification series -- helping businesses save money, time, and resources
Throughout this series, we've learned that writing solid requirements is the first, most critical step for product success. Yet, with developers juggling hundreds if not thousands of requirements, something inevitably slips through: A requirement is not addressed in development. Or it’s detected in implementation and testing, and it must be addressed in a later release. Other times the oversight is not noticed until the system is integrated, manufactured, or deployed. At that point, addressing the missing requirement and making necessary modifications can be even more costly and time consuming.
At the end of the lifecycle, organizations can lose thousands of dollars, have to push back launch dates, and jeopardize their business success, all because of missing or incomplete requirements.
Making sure you’re addressing these three factors can help you identify and address possible omissions before they cause problems.
Accuracy and real-world use. To write complete requirements, you must identify the desired capability’s real- world operational environment, its interface to that environment, and its interaction with that environment. It is the real-world aspect of requirements that is the major source of difficulty in achieving specification correctness. Defining requirements from this perspective can help you address issues of performance, reliability, safety, and security that will be difficult to add later in the lifecyle.
Elicitation. It is not enough for requirements engineers to rely on stakeholders to tell them what they want. Instead, they must actively elicit requirements from all groups of stakeholders. They should collaborate on issues of reliability, safety, security, and usability, never assuming that requirements are obvious or understood. Questions should be asked about what’s needed for availability, interoperability, performance, portability, reliability, robustness, stability, and usability. Many omissions happen because requirements engineers make guesses about stakeholder needs, and stakeholders assume that requirements engineers automatically account for those needs.Mature methods and techniques. Your requirements elicitation process should be able to gather information for all types of conditions and scenarios. It should handle all credible inputs, whether they are use case diagrams, use case modeling, or path descriptions. It should ascertain requirements for “sunny day” as well as “rainy day” paths and their associated conditions. In this way, you can determine whether requirements are complete enough to define needs in any situation, and not just under perfect parameters.
To communicate the vision for your product accurately to all partners, manufacturing and engineering contractors, in-house product developers, marketing, and company executives, your requirements gathering process must account for real-world use, stakeholder elicitation, and mature processes.
This Tecnova series on requirements specification has explored:
- The value that quality requirements deliver across multiple teams throughout the enterprise
- The costly consequences of having poor requirements and the effect they have on stakeholder satisfaction and business outcomes
- The fatal flaws found in so many that ultimately lead to product failures, wasted time, extra costs, and lost revenue
- Finally, the qualities of good requirements:
To deliver value at your organization and ensure your requirements are at the level they need to be, download Tecnova’s free Requirements Specification Template. Achieve a profitable, successful product launch -- download yours now.
