Requirement
“Something that is required; a necessity.”

Scenario: “You are a Project Manager and you just received a requirements document from one of the Business Analysts (or other responsible team member). You are not sure how to judge quality of requirements and you don’t have much time to refer requirements best practices manual. Where do you go?”
Spend next few minutes reading this article and you will be ready to provide meaningful feedback to your team!

Here are some of the requirement characteristics of good requirements.

Result-oriented. Requirement clearly defined a business need and guides designer/developers to build functionality to build (new functionality/feature) or improve existing functionality. As a Project Manager, you should flag requirement if requirement does not meet this criteria.

Effective. Requirement shall clearly articulate what needs to be delivered. Effective requirements clearly articulate ‘what’ needs to be delivered. Look for quantifiable measures (i.e. response time 3 seconds or less, seven reports etc) v/s ambiguous terms (i.e. as soon as possible, all reports etc).

Acceptable. Business user/stakeholders originate the requirements and assigned Business Analyst (or responsible team member) must vet all requirements with implementer. This acceptance will greatly reduce your project requirements delivery risk.

Labeled/ Categorized. Categorized requirements help scheduling, requirements elicitation, review and approval process. You can introduce project milestones per category instead of waiting for someone to complete all those five hundred requirements after three months.

Involvement/ Collaborate. Good requirements are result of collaboration between business, technology, vendor and infrastructure teams. As a Project Manager, you may have to handle additional ‘storming’ sessions during early stages. However, this will improve quality of requirements and end product.

Stakeholder Engagement. Stakeholders must be engaged in requirements elicitations process. Their role may be ‘Owner’, ’Reviewer’, ’Subject Matter Expert’ or ‘Approver’. Engaged stakeholder provides much needed business insight and guidance to make project successful.

Testable/ Verifiable. Rethink requirement if your test team cannot create test case to test the requirement. Engage test team lead early on to ensure requirements are verifiable. Do you have a Testing Lead? If not, it’s time to secure one!

Clear/Unambiguous. You may flag a requirement if it looks like algorithm instead of easy to understand english statement (i.e. use of keywords ‘or’, ’and’, ’not’, ’if then’, ’but’ etc). Such requirements may be interpreted differently by stakeholders and introduces re-work at a later stage. It is better to rewrite such requirements sooner than later.

Enjoy your requirements review journey!