BLOG #0008

WRITING SMARTr REQUIREMENTS — THE UNSPACE WAY

When it comes to writing requirements for internal or external customers, the quality of those requirements is essential. If the requirements are too vague or difficult to test, they won’t be looked at beyond project kickoff. On the other hand, if there are too many requirements that are too detailed without enough time or resources to test them, they won't all be met, and key details may be missed.

You may be familiar with the SMART acronym, but how does it apply to requirements? And what is with that bonus “r”? Let’s cover the basics of SMART, tying in the Reasoning and Rationale, and how to turn those into requirements. 

What is SMART?

SMART is acronym for evaluating technical objectives, experience, or requirements. Specific, Measurable, Attainable, Realistic, Traceable. Using these criteria ensures that the requirements can be met, within a timely manner, and can be evaluated against when testing. As you write requirements, you should evaluate each of these to determine the quality of the requirement and adjust as necessary. These represent questions you should be asking as you write and consider each requirement. Is ‘Low power consumption’ specific enough? What is the limit in watts? Should we specify current and voltage separately? How will we test it? What range of tolerance is acceptable? How will we ensure we stay below this for each unit? 

—And what is SMARTr?

While it may be tempting to just pick a subsection of your project and jump to writing requirements, this misses out on the most important part of requirements writing: The UNSPACE advantage, the second ‘r’, Rationale and Reasoning.

Requirements should always be driven from higher level constraints or objectives. An arbitrary requirement is worse than no requirement at all. For example, you shouldn’t require that the wall power be supplied by a C13 electrical connector without reason. ‘Your previous designs using it so this one should’ is NOT a valid rationale. If it is a constraint that there a high amperage requirement, or that you need to sell the product in several regions without retooling or pre-allocating production, then requiring a C13 connector makes sense. If not, then directly wiring in the power plug may be more cost effective from a BOM and process perspective. You would have just spent money unnecessarily because of a bad requirement.

Turning Rationale into Requirements

The UNSPACE Requirements Iteration is a workshop that walks you through developing your requirements the right way; Identifying stakeholders and high-level constraints and using those to drive requirements. This also helps prevent missing whole sections of requirements you may not have included or even considered without working through this process. Have you considered all the stakeholders? The Requirements Iteration workshop guides you through identifying these drivers and developing your requirements from them. Without this process, you may not realize or consider that shipping has a specific constraint, marketing has a particular need, and that requirements depend on the assembly team.

Having the right systematic approach to requirements generation can streamline and simplify writing and result in a higher quality output. Consider adding Rationale and Reasoning on your requirements evaluation and working through generating requirements the UNSPACE way!