There is a SMART way to write software requirements

SMART is an evaluation technique that can be used when writing software requirements

Erivan Ramos
4 min readMar 27, 2021


“There is a SMART way to write software requirements” by

SMART is a well-established criteria evaluation tool that originated in business management and extended to other studies fields, such as business analysis and requirements engineering. The first known mention was in 1981 when George T. Doran wrote the paper “There’s a S.M.A.R.T. way to write management’s goals and objectives”, published by the “Management Review”. It discussed the importance of objectives and the difficulty of setting them for management excellence. The author suggested that when it comes to writing effective objectives, ideally speaking; this should be SMART, a mnemonic acronym for “Specific”, “Measurable”, “Assignable”, “Realistic”, and “Time-related”. Since then, SMART has been adopted in different fields, with some variations in use, but usually as an acceptance criteria tool.

SMART was adapted to requirements engineering by Michael Mannion and Barry Keepence in 1995. In the study “SMART Requirements”, published by the Software Engineering Notes, they compared requirements with objectives, and adjusted SMART to be used as an evaluation tool to better express (less incorrect/incomplete) software requirements, thus more likely to be technically correct. For the authors, if a requirement fails one of SMART’s criteria, it may be due to another criterion's failure. Their SMART criteria presented slight variations for the letters “A” and “T”. In the context of Requirements Engineering, it would be more appropriate to think of “A” as “Attainable” and “T” as “Traceable”. Thus, hence in specifying software requirements, SMART is defined to be “Specific”, “Measurable”, “Attainable”, “Realisable”, and “Traceable”.


Specific requirements say exactly what is needed, be clear (unambiguous), consistent in terminology, simple and with an adequate detail level.
It is recommended to avoid:
- phrases like “obviously”, clearly”, “certainly”;
- ambiguities like “some”, several”, “many”;
- list terminators like “etc.”, “and so on”, “…such as”;
- “To Be Defined”.
It is recommended to ensure that:
- pronouns are clearly referenced;
- numbers are specified to identify the units;
- all possible elements in a…



Erivan Ramos

Business Analysis & Requirements Engineering enthusiast. Information Systems & Software Engineering specialist. MBA in PM & HR. CBAP®, PMP®, CSM®, ITIL®& COBIT®