The bottom line is the set of requirements is complete when all the stakeholders have approved the set of requirements.

Define Scope before you write your requirements.
From Requirements Expert’s viewpoint, it is that, but more.   What we advocate in our classes is the importance of clearly understanding and defining stakeholder expectations before writing requirements.  This is what we call defining scope.   Requirement definition is a quest for knowledge need to write a correct, complete, and consistent set of requirements.  Each of the things we teach in our class is one step in this quest.

1. Identify the relevant stakeholders.
2. Define a clear set of Need, goals, and objectives.  Include your Key Performance Parameters (KPPs) in the set of objectives.
3. Identify your drivers and constraints.  This includes identifying all applicable regulations and design and construction standards, higher level requirements, existing systems, budget, schedule, technology.
4. Develop scenarios, use cases, and operational concepts.  The goal is to define at least one set of concepts that will result in the Need, goals, and objectives being met within the context of the drivers and constraints.  In developing the scenarios or operational concepts, you need to involve all the relevant stakeholders, for all life-cycle stages of the product, for both nominal and off-nominal cases.
5. Identify the external interfaces between our system and the outside world.

If you follow this approach, there is little you have left unturned and should have the knowledge to develop a correct, complete and consistent set of requirements.

There are several effective methods to help make sure you have a complete set of requirements.

1. Use the Checklist for Good Requirements that we provide in our classes. (Send me an email at info@argondigital.com and I will send you a copy of the checklist.)
2. Major reviews like the Systems Requirement Review (SRR), involve even more stakeholders to help identify missing requirements.
3. Use cases and scenarios help make sure the system you have defined will provide its intended function, performance, and quality expectations from the stakeholder perspective.
4. Functional Modeling helps with completeness and consistency.  Model-based System Engineering (MBSE) builds on this concept.
5. Develop a template for your requirements document, tailored for your domain (product line) with examples of the various types of requirements that need to be defined.  In our classes, we advocate you organize your requirements into the following categories:  functional/performance requirements; operational requirements (all requirements dealing with how your system interacts with the outside world (external interfaces); -ilities (including quality, safety, security); physical attributes of the system; and design and construction standards.
6. Risk assessment methods (FEMA, PRA, Fault Tress, etc) help you to identify off-nominal situations that your system may have to deal with.  Addressing the bad things that may happen during scope definition will result in a more robust system.  For those bad things you can do something about, you will include requirements.

If you gain the knowledge that results from defining scope and develop a set of requirements that, when implemented, will result in everything in scope definition being implemented, then you should have a correct, complete and consistent set of requirements.

Saying that, the proof of the pudding is when you can successfully complete system validation – proving the system meets its intended purpose  in its operational environment.  The intended purpose is what is defined during the scope definition phase.

The bottom line is for a project to follow the best practices for product development as advocated by ArgonDigital, allocate the resources needed to develop requirements, educate your team, and have management clearly communicate the importance of requirements to your project’s success.