This question was asked recently on a popular discussion group.

Maybe a better question to ask: “How do I know when the requirement set for the system of interest is “done enough” to give to the development team?” Where “done enough” is the point of time in the development process where the cost of potential changes is less than the investment required to anticipate every requirement.

Ultimately this is a risk decision. What are the schedule and budget risks of proceeding with an incomplete or poorly formed set of requirements vs spending more time on the development of the set of requirements?

There really isn’t a simple indicator. The determination should be knowledge driven and not schedule driven. However, there are things you can do at the beginning of the project to help you later on when you are trying to assess whether you are “done enough” to proceed to design/development.

Spend the time to develop scope before writing requirements

Spend time at the front-end of the project to define the scope of the project. Understand and document the “need”, i.e., the problem you are trying to solve or the opportunity you are looking to exploit. Identify the essential stakeholders of the project, including the subject matter experts, and engage them in defining the project scope: the vision, the goals and objectives, drivers and constraints, assumptions, dependencies, and interfaces. Within this context, do what is needed to discover at least one feasible concept that will result in the vision, goals, and objectives being realized within the defined drivers and constraints.

To get a complete understanding and the knowledge needed to write requirements, you need to elicit the expectations and needs of each of the stakeholders, resolve conflicts, and reset some expectations (based on reality and the drives and constraints). What is the expected functionality? Performance? Quality? What other systems does this system need to interact (interface) with? To answer these questions, you need to not just focus on normal operations, but also address the off-nominal cases and address all the product life-cycle stages – especially the interfaces at each stage. This effort can involve uses cases, user stories, scenarios, prototyping, modeling, etc. To get the knowledge you need, you need to spend the time necessary to know enough to write the requirements.

Document requirements to best practices

The assessment of “done enough” is further expedited by having a set of requirements that have the characteristics of well-formed set of requirements (note that detail of these characteristics are included in the next release (release date TBD) of the INCOSE RWG Guide to Writing Requirements for which I am a co-author.). Let me explain what I mean by this…

A set of requirements results from the formal transformation of the set of needs and expectations developed during scope definition that represents an agreed-to obligation between the stakeholders and the developers. The key elements of this definition are: a formal transformation and an agreed-to obligation. Each of these two elements can be elaborated further by stating specific characteristics of a well-formed set of requirements.

Formal Transformation. Given the set of requirement is the result of a formal transformation, the following characteristics of the requirement set can be derived:

• Complete – The requirement set stands alone such that it sufficiently describes the necessary capabilities, characteristics, constraints, and/or quality factors to meet the stakeholder needs without needing other information. If the formal transformation results in individual requirements that are necessary, the set of requirements must be a sufficient solution to the set of needs—that is, all necessary requirements have been included to meet the needs, and that all irrelevant requirements have been excluded. The goal is to communicate clearly stakeholder needs via the minimum set of requirements that are necessary and sufficient and no more.
• Consistent – The set of requirements contains individual requirements that are unique and do not conflict with other requirements in the set. Conflicting requirements lead to an empty solution space, and if not identified early on in the development process, can lead to expensive rework. For the transformation to be formal, the resultant set of individual requirements must not conflict and must be consistent with each other. Frequently, customer and other relevant stakeholder needs or design constraints are in conflict with one another, and need to be reconciled.

Agreed-to Obligation. If the set of requirements is to be a result of a fair agreement to meet an obligation, the following characteristics of the set can be derived:

• Feasible – The requirement set can be realized within constraints (e.g., cost, schedule, technical, legal, regulatory) with acceptable risk. There is little point in agreeing to an obligation that is not feasible. The set of requirements must be achievable within the appropriate constraints. If infeasibility is not identified early on in the development process, it can lead to wasted effort and cost. While individual statements of requirement may seem feasible, they may not be so when placed in combination with others. That is, the combination of feasible individual requirements does not necessarily sum to a feasible set of requirements.
• Comprehensible – The set of requirements must be written such that it is clear as to what is expected by the stakeholders and its relation to the macro system of which it is a part. An agreement is difficult to enact unless both parties are clear on the exact obligation and the expected outcome as a result of the realization of the system the set of requirements represents. The set must therefore be written so that the relevant audience can understand what is being communicated by the individual requirements as well as the set of requirements.
• Able to be validated – It must be able to be proven, with acceptable risk, that when realized, the requirement set results in the achievement of the stakeholder needs. The transformation must be formal and able to be validated, not just for individual requirements, but also for the set. It must be able to be shown at any stage of the system development that achievement of the set of requirements will result in meeting the set of needs from which it was transformed. System validation is making sure the built and verified system meets its intended purpose in its operational environment. Thus system validation goes back to the needs to make sure they have been met—as a set.

If your requirement set does not have ALL of these characteristics, there is a risk that the system developed will not meet the stakeholder needs, and thus fail system validation.

For the question “Is the set good enough or sufficient?” The answer is “Its a risk decision you have to make……..”

As always, comments to this blog are welcome.

If you have any other topics you would like addressed in our blog, feel free to let us know via our “Ask the Experts” page and we will do our best to provide a timely response.