How do you balance clarity and completeness in your requirements specifications?

The comparison isn’t accurate. Mentioned Clarity applies to single requirement and the mentioned Completeness is applicable to requirements specifications. Completeness of single requirement (self contained) is different than completeness of specifications (all requirements captured). You don’t need to balance them, whether in the context of single requirement or requirements specifications. You should achieve both.

Requirements is not stating the design, but the envelope for the design, i.e. specification that gives designer creativity and flexibility for the best solutions and outcome.

Concise and Precise are often at odds, sometimes you want hardware that can be improved over time; sometimes you want an extensible solution (room for improvement within the delivered size weight and power envelope) but not an expandable solution (option to bolt on additional modules etc) It is vital to ensure that you indicate which requirements are tight and which ones are looser, it is not always implicit when someone other than the author reads them.

In my perspective, i don't think there is trade-offs in requirement clarity vs Completeness. Clarity and completeness depends on how well did we complete the requirement capture activity. The activity begins with capturing requirements from stake holder needs and continues through the concept development, system design until the system is fully specified, implemented and all requirements are validated. Requirement capture activity also determines if the system of interest complies with all stakeholder needs or not.

Requirements should be testable ideally automatically. Requirements should comply with regulations especially in the medical device area.

Categorising requirements is a fundamental however the need for understanding the functional architecture and using that to 'group' functionality cannot be stressed enough. Predominantly usability and other solution related requirements are non- functional, these can easily be 'grouped' into a framework that expands beyond FURPS, which includes SWaP and the 'ities'. Linking back to the previous section, the ability to understand you have sufficient requirements must be driven from validating your functional architecture and use the same validation approach to ensure you have provided coverage within the functional requirements.

From the article, I see how FURPS+ can help categorize based on type, but there is no support for the claim that it can prioritize based on importance. The article seems to imply there is some inherent difference of importance between Functionality, Usability, Reliability, etc.

Depending on how complex the project is, it is important to give requirements elicitation the time it deserves. Complex projects and programmes may need more time for elicitation. Time to develop and refine requirements with relevant stakeholders to get the right quality of requirements.

Sources of requirements are not restricted to stakeholders but can also include existing systems, process documents, regulations, and proprietary documents as outlined in the International Requirements Engineering Board (IREB) handbook on requirements engineering.

One of the ways to increase the quality of the written requirements is to engage the test and validation engineers as part of the Requirements Validation process. In my experience, they always provide great insight into whether your written requirements are unambiguous, complete and testable. Their fresh view at the requirements make it easier to ensure the requirements are correct, consistent, and complete.

When people hear that requirements are correct, consistent, and complete, they can be misled to think that means with respect to the system. Actually, it only means that the requirements agree with themselves, which is a great goal to have but not the same thing. For complex systems it's important to have experience to get greater requirements coverage, but one rarely covers everything.

A good requirement management tool that provides automated traceability and version control as well as a collaborative environment so all stakeholders can contribute should be used for large projects. Automation, traceability, version control and collaboration are four ingredients of a good requirement management tool.

On complex projects and programmes, it is important to consider the use of a requirements management tool to ensure integrity, quality, and ease of traceability analysis of requirements.

I'm surprised it was not mentioned that a quality, or optimal, requirement is testable. Verification & validation were cited. However, a requirement shall be written such that an independent testing entity can exercise the feature & gather objective evidence detailing its correct implementation.

Details are important. I was involved with defining performance requirements for a new engine, including the environment expected for the engine to operate in and the performance expected, when including power and bleed air extractions. One of the details I overlooked was the fact that while it was nonsensical to use anti-icing bleed air extractions when one is in a high and hot environment (e.g., Denver at 95F), the engineers developing the engine control software would view it as a hard requirement that they had to satisfy, so to protect the engine from anti-ice bleed extraction while at Denver and 95F, they pulled the power back quite a lot whenever anti-ice bleed was selected on. This miscommunication became apparent during flight test.

One key question related to the posted premise is “Who cares?” Answer: System Designers and the Builders since the specifications (from requirements) act as the “interface panel between human designers and builders.” Humans require clarity and completeness to solve a problem. Developing human-based specification/requirements assures us that the specification is effectively used. An effective specification is global-usableness (readable or clear and understandable or complete), testable, easy to change, and readily evolves. More on a human-based approach, see IEEE Jan 2000 published article about “Intent Specifications” by Dr. Nancy Leveson MIT.

Even seemingly common language may need to be defined. “Approved by” and “approval” are great examples, especially when dealing with government contracting. Instances where “approved” means “by the government” may be too vague, but simply saying “approved” is just as vague if it is not defined. The best course of action is to identify who is procuring the product relating to the specification, and then defining “approval” and “approved by” as being approved by the entity so identified.

I do not believe there is a trade between clarity & completeness. I believe the trade is between a complete specification consisting of well written requirements, goals, schedule, cost and risk. The better the specification the higher the probability you will get want you need but there is a cost for risk reduction. Additionally, the skills to determine what is necessary overlap but are not the same as the skills required to covert those needs into a set of unambiguous, achievable, and verifiable set of requirements. (I don’t need to be an expert in a field to know that when I see the word maximize in a “requirement” statement to know the requirement is unverifiable.) Ronald Mandel LM Space Chief Systems Engineer & LM Fellow (retired)