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:
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.
“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.
“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.”
The requirements should be appropriate to meet the goals of the project and accurately describe the user’s expectations of the functionality.
“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.
“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.”
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.
“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?
“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.”
Each requirement should be testable and verifiable.
“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.
“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.”
Requirements must be necessary and clearly support one of the original project goals or objectives.
“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?”
The Business Analyst must be sure that all requirements are technologically possible for a reasonable cost.
“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?
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!