Posted by tac_admin, April 3, 2013

7 Trademarks of Awesome Requirements

Awesome requirementsA requirement may be very broad, very specific, or something in between.

For example, a high level requirement may look like this:

“Our payroll system must have direct deposit and paycheck options.”

Whereas a detailed requirement may read:

“The employee ID number should be 6 digits and assigned sequentially based on the employee’s original hire date.”

It is the responsibility of the Business Analyst to write clear and complete requirements, no matter the scope of specificity. Check out the 7 characteristics of excellentrequirements below:

Complete Requirements

Make sure the requirement describes completely the user task and information required to support the task. Focusing on system functionality instead of what needs to be accomplished may lead to incomplete requirements.

Incomplete requirement:
“We must be able to change an employee’s profile information.”

***If we don’t specify the individual components of the employee profile, this requirement is not complete.

Complete requirement:

“We must be able to change the employee last name, first name, middle initial, street address, city, state, zip code, marital status, and/or withholding parameters.”

Correct Requirements

The requirements should be appropriate to meet the goals of the project and accurately describe the user’s expectations of the functionality.

Incorrect requirement:

“Employees only change their name when their address or their marital status changes.”

***Someone who was not familiar with the business area may have assumed this requirement. This requirement is incorrect and must be changed.

Correct requirement:

“Employees may change their name in the payroll system by providing the appropriate legal proof of the change. The change may come with a change in marital status, address, withholding parameters, or be made alone.”

Unambiguous Requirements

Requirements should be written so that all readers will arrive at a single, consistent interpretation. Ambiguous requirements can result in the wrong system being developed and may not be found during testing due to the incorrect interpretation of the requirement.

Ambiguous requirement:

“Employees are not allowed to work for more than 80 hours in one week.”

*** “Not allowed” is an ambiguous phrase. Are they physically removed from the work environment or are they not paid for any hours over 80?

Unambiguous requirement:

“Employee time worked: the time worked is recorded in hours, the smallest increment recorded is .25 of an hour. If an employee reports more than 80 hours in a seven day period, a warning is provided to the supervisor and the payment is held for approval.”

Verifiable Requirements

Each requirement should be testable and verifiable.

Unverifiable requirement:

“The system should be easy to use.”

***This requirement is impossible to test since every user will have a different opinion about what is easy and what is not.

Verifiable requirement:

“A novice user must be able to add a new employee to the payroll system within 10 minutes.”

“An experienced user must be able to change an employee’s withholding parameters within 3 minutes.”

Necessary Requirements

Requirements must be necessary and clearly support one of the original project goals or objectives.

Unnecessary requirement:

“We should be able to enter the employee eye color.”

***This is a great example of a time when theBA needs to ask, “Why is this requirement necessary?”

Feasible Requirements

The Business Analyst must be sure that all requirements are technologically possible for a reasonable cost.

Unfeasible requirement:

“The system should automatically be updated when the government changes the withholding parameter criteria.”

***Although this requirement may be technologically feasible, it would involve a complex interface with an outside organization and may be very expensive. Is it a critical requirement?

Prioritized Requirements 

Each requirement should be prioritized.Some organizations require one of the following phrases in each requirement:

  • Must have
  • Should have
  • Could have

Sign up for my online training course today to learn everything you need to know about excellent requirements! 


One response to “7 Trademarks of Awesome Requirements”

  1. […] the time a project begins, requirements guide the project through completion. Requirements define the problem the project addresses and form the framework for project documents. The role of […]

Leave a Reply

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

Get in touch today

Speak directly with The Analyst Coach
and get pointed in the right direction.

Preferred Contact EmailPhone

Subscribe to receive our free white paper on how weak requirements effect strong companies


Sign up to get your FREE Business Analyst Survival Guide

Don't worry, we hate spam too. We will never share your information to third parties.