Requirements: When Wishing Alone Does Not Help

Product managers gather market requirements (e.g., applicable standards) via their interface with sales and position their product in the market. They draw up a product release plan by grouping and prioritizing requirements (see also the SMART attribute „Relevant”). To do this, they use, for example, the MosCoW scheme (Must-have, should-have, Could-have, and Won't-have) or even more sophisticated tools such as the Requirements Prioritization Matrix.

To define a product release, product managers need information from the development department, e.g., on the feasibility of requirements or the development effort involved. In discussions between product management and the development department, the priority of requirements should also be clarified with regard to the creation of the requirements specification.

At the latest in the requirements specification, there should no longer be any “nice-to-have” requirements. Every requirement takes time to implement and verify (see also the SMART attribute “Time-bound”), increases complexity, and costs money. Clear requirement priorities also reduce the risk of a late market launch.

The functional specification is written by the development department or the development service provider and is usually more detailed than the requirements specification. The authors of this document ensure that all requirements are SMART, see below. Since the functional specification is binding for product implementation, it must be reviewed and approved by product management.

Everyone has heard that requirements should be SMART (Specific, Measurable, Achievable, Relevant, and Time-bound). But what do these attributes mean?

Specific

How often do you see requirements like this in specifications: „The input voltage range must be greater than that of product xy.” Even if the input voltage range of this product were defined, this requirement would remain unspecific because no explicit information (value and unit, interface definition) about the range is provided. Comparative words such as „greater,” „faster,” and „better” generally have no place in requirements.

The specification is also made more specific by dividing it into functional and non-functional requirements.

Measurable

Much of what concerns measurability has already been covered in the section above. If a requirement is not measurable, it cannot be verified and therefore it cannot be ensured that the requirement has been implemented.

Achievable

Requirements must be realistic, i.e., achievable. This attribute is usually considered in conjunction with the last attribute (time-bound). Requirements whose implementation goes beyond the state of the art require a (very) large development effort.

Relevant

Requirements must be important, i.e., they must pay off (business value). Often, requirements are prioritized here, e.g., “must” or “nice-to-have,” or even finer distinctions are made. In a requirements specification, however, there should no longer be any “nice-to-have” requirements, because every requirement takes time to implement and verify (see also the Time-Bound attribute), increases complexity, and costs money.

Solcept has three priorities in its requirement templates: safety, must, nice-to-have. All “nice-to-have” requirements are eliminated together with the customer before the first baseline of the requirements specification, so that only “safety” and ‘must’ remain for implementation. The “safety” attribute is based on a concept of efficiency: not all requirements for a product are safety-relevant. However, safety-relevant requirements usually require increased documentation effort (e.g., specification and architecture descriptions down to the lowest level). This effort should only be made for safety-relevant requirements. Our requirements management tool helps us to ensure the required level of documentation for all safety requirements (traceability analysis with appropriate filtering).

Time-bound

As mentioned above, this attribute should be viewed in the context of the importance and achievability of requirements. The focus here is on the planned time of market entry.

It makes sense to distinguish between functional and non-functional requirements:

• Functional requirements describe the behavior, i.e., what a product does (e.g. read, process, display sensor values)
• Non-functional requirements specify how this function is performed (e.g. with what update rate)

Functional requirements

Functional requirements require a different form of description than non-functional requirements. It is advantageous to use a semi-formal notation in table form, which summarizes the following information:

• Objective
• Prerequisite
• Trigger
• Sequence of activities
  • Semi-formal, e.g., with IF-THEN-ELSE or DO-WHILE, etc.
• Final state

Non-functional requirements

Non-functional requirements are often also in table form and require the following information:

• Parameters (for referencing in functional requirements, e.g., T_Sample)
• Description
• Value
• Unit
• Conditions (e.g., only within a certain temperature range)

It is important that functional requirements do not contain explicit non-functional requirements, but that these are only referenced via a parameter (avoiding multiple definitions of a requirement). A modern requirements tool allows the two requirements to be linked for traceability or change impact analysis.

Just Start, Then Optimize, Optimize, Optimize

„The first draft of everything is shit.” – Ernest Hemingway

Do not let writer's block stop you, and do not disguise your inability to get started with perfectionism. To discuss and work out requirements efficiently, you need to write down what you know.

No one writes perfect requirements in just one draft. Clear and unambiguous requirements are more likely to be achieved in many small steps:

• Sharpen your thoughts while writing them down or drawing a diagram
• Discuss ideas/concepts with your colleagues
• Adapt the requirements iteratively to the architecture description
• Adapt the format to your organization's requirements rules
• Move information to the correct level in the V-model (see also here)
• Perform a review using the four eyes principle and a checklist
• Revise content based on feedback from the top, bottom, and right sides of the V-model
• Simply delete a requirement if it is obsolete (at least it helped you gain this understanding)
• Start reviewing individual requirements as early as possible (i.e., do not wait until the complete specification document is finished)

But be aware: Optimization should aim for a global optimum and not oscillate between local optima (e.g. rewriting the requirement each time it is discussed with another person according to personal format preferences).

Managing Change: Enabling Improvements, Limiting Risks

„Change management is requirements management for adults” – almost Tom DeMarco

The further the project progresses, the higher the inherent risks and costs of change. On the other hand, change is essential to achieve good quality. As explained above, excellence is achieved in many small steps.

Here are some tips for a lean change management process:

• Use a tool that manages the status of each individual requirement
• Optimize your process for change and do not assume a single creation and review loop (even low-complexity projects have many dependencies that require a feedback loop and changes in all directions of the V-model)
• Provide good tool support to review changes and their impact (the diff tool is the first feature to look at when evaluating a requirements management tool)
• Use gates to ensure that the content of the requirements is at an appropriate level for the project lifecycle (e.g. at the start of development, at least the unknowns should be identified and then closed as part of change management during development/verification)
• Use traceability and add these links during writing so that you can always see what depends on what

Move the Writing to the Information

“Do not move the information to the authority, move the authority to the information.” – L. David Marquet

Requirements management is neither black magic nor a role definition. Transferring all relevant information to a few requirements managers is inefficient and carries the risk of critical topics being lost during the transfer.

Instead, set up a simple process and tool that welcomes every stakeholder as a contributor (author, reviewer, tester, approver or auditor). Ensure that the person with the most information (developer, tester, product manager, service representative, etc.) is directly involved in the process and is given the control and authority to write and review the relevant requirements directly.

Even in a system with low complexity, defining requirements and ensuring their traceability requires in-depth expertise in many areas. Therefore, this cannot be handled by a single specialist, but requires teamwork.

The V-model Provides Structure, Not a Timeline

„The V-model is the worst form of organization—except for all the others” – almost Winston S. Churchill

The V-model helps to structure information and represent relationships (via traceability) in two dimensions:

• Vertically: The design is refined hierarchically, with layers helping to reduce complexity so that requirements can be met through design and review alone
• Horizontally: At each layer, it is ensured that everything is tested

This is particularly helpful in

• showing where information can be stored and found
• efficiently managing the impact of changes (see also above)

A common misconception is that the V-model represents a timeline. A project is not simply completed by going through the model once or twice. The work requires inherent feedback loops in all directions and will also be done from the bottom up. This is fine as long as the information is consistent from top to bottom and left to right at the end.

Consider, for example, hardware imperfections that are corrected in the software. These are details from the low-level hardware design that are usually not defined until late in the project. Nevertheless, they belong into the hardware-software interface specification at the system level to ensure that the software engineer can find the information.

Another example is the top-level specification. At the end of the first phase of system design, it is usually not possible to specify every detail completely. Instead, an assumption can be made to enable development, or at least the unknowns (TBD's) should be identified. These can then be tracked and resolved as sufficient information is gained during development.

Structure and Formalize Communication, but Keep Communicating

„Good communication is the bridge between confusion and clarity” – Nat Turner

Clean requirements management sounds like a lot of work, but ambiguities and vagueness can lead to inefficiency and much more work, such as:

• Higher effort in implementing the wrong thing due to misunderstandings
• Major changes late in the project due to forgotten requirements/problems
• Recurring discussions about what needs to be implemented

A requirement is something that everyone involved must have the same understanding of, so that the individually developed parts work together and the end product offers the desired functionality. Ultimately, requirements management is just a structured and formalized method for communicating and for connecting all stakeholders.

Keep the following in mind:

• If a requirement is ambiguous and leads to discussion, update it with the conclusion that results from the discussion, otherwise the same discussion will come up again (e.g., during reviews, implementation, testing, etc.).
• At the beginning of the project life cycle, it is important to record and coordinate the most important requirements/decisions (without getting lost in details that can be clarified later), as fundamental changes to the architecture/design can then still be made without major impact/effort.
• Since natural language is ambiguous, clearly defined semantics and formalized approaches help to reduce ambiguity. However, keep in mind that comprehensibility always comes before format and tools.