Measurable: this answers whether you will be able to verify the completion of the project. You should avoid signing up for any requirement that cannot be verified as complete. These are especially risky when you use non-quantitative terms (best, optimal, fastest) for acceptance criteria.
- Weak Requirement: The system shall have an optimal response time for the end-user.
Why is it weak? There is no way you can be successful with this requirement once the new system goes into production. It’s similar to being specific, in that optimal is not defined and really cannot be defined.
Strong Requirement: The system shall have user response times on user click-events that are 5-seconds or less during business hours of 9AM-5PM, Mountain Time, Monday-Friday.
Now this requirement can be measured once the system is in production. In the first example, you might end up in a never ending loop with the customer after the system is in production trying to define “optimal.”
Jessica Popp is a practicing project manager in software engineering. She has more than 13 years experience in software development, project management and people leadership in both Fortune 500 and startup companies. She has a wealth of hands-on project experience from the smallest project to projects whose budgets exceeded $50M per year. Jessica holds a BBS in Information Systems, an MS in Decision Sciences and has a current PMP certification. Jessica runs Project Management 101, a blog dedicated to disccussing various topics about Project Management.