Are your requirements smart

Are Your Requirements SMART?

Most of us would have heard something as SMART objectives. SMART objectives have been used by professionals for a long time to ensure they set objectives which are clear to stakeholders and are achievable.

Can we apply the same principles to requirements?

This would actually be a nice conversation with your stakeholders. If you find a requirement which is NOT SMART, you simply indicate to stakeholder that the requirement is not very smart and should be modified appropriately.

I define the SMART requirements as one which follow the below mentioned rules:


Without ambiguity, using consistent terminology, simple and at the appropriate level of detail

It is possible to put a number to the requirement? This is especially true for non-functional requirements.

Technically feasible. What is your professional judgment of the technical ‘do-ability’ of the requirement?

Realistic, given the resources. Do you have the staffing? Do you have the skill? Do you have access to the development infrastructure needed? Do you have access to the run-time infrastructure needed? Do you have enough time?

Traceable and Testable
From its conception through its requirement specification to its subsequent design, implementation and test.

I have used this simple classification and found very good use of the same.

Do let me know if this works for you as well.

Happy reading and have a wonderful day and do provide your suggestions and comments.


I work as Principal Consultant and Trainer with Adaptive Processes, a leading requirement engineering solutions (training, consulting and product) organization. You can reach me at

If you like my posts please like/share/comment and spread the word in your network.

Would love to hear from all professionals here, please leave a comment with your feedback.


About Adaptive Processes


Adaptive Processes provides CBAPCCBAECBACPRE, Agile BA and other business analysis certification training online and consulting needs for Individual or Corporate either online or offline. Adaptive Processes is an endorsed education provider of IIBA®, Canada and IREB®, Germany.

Learn more on this training here: . For more updates on courses & tips follow us on: Facebook | Twitter | LinkedIn | Google+
​​​​ ​

Follow LN


COO at Adaptive Processes
Author Mentor Consultant

24+ years of professional experience inbusiness analysis, software product development, business analysis, ERP implementations, software processes , strategic Change Management Consultancy.

Author of 12 books on Business Analysis and Requirements Engineering
Follow LN


  • Nice article, have come across this acronym while doing various courses, was only able to recall the S, M and T though, thanks for explaining this important concept lucidly. But the ‘Traceable’ part in T is something new to me, Its good to have it there, but I feel ‘Traceability’ is more of a process aspect, not an integral part of Requirements definition.

    • Dear Anirban,

      In fact T (Traceability) is very essential. Here I am referring to tracing the requirement to project scope and business need. If we can’t establish a good traceability between requirement, project scope and business need, it should be dropped.

      Hope this clarifies my thoughts on the subject.


  • How come anything in analysis can be a rule ? They are widely accepted thoughts not rules or best practices.
    SMART are objectives attributes for requirements are different.

Leave a Reply

Your email address will not be published. Required fields are marked *