Requirements Everywhere

Requirements Everywhere
Sowmya Teja Page 1
7 Trademarks of Awesome Requirements
A 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 excellent requirements below:
1) 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.”
2) 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.”

Sowmya Teja Page 2
3) 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.”
4) 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.”

Sowmya Teja Page 3
5) 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 the BA needs to ask, “Why is this requirement necessary?”
6) 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?
7) Prioritized Requirements
Each requirement should be prioritized. Some organizations require one of the following phrases in each
requirement:
Must have
Should have
Could have

Sowmya Teja Page 4
Four Steps to Consistent Requirements Elicitation
1. Ask Questions – remember that your job as a business analyst is to help the business solve a problem
they have.
The dynamic of how your business sponsor’s mind works is the key to understanding their needs.
Remember that it’s not always what the person says that’s important, sometimes it’s how they say it that
you need to pay attention to.
2. Listen – Listen to what the business is saying. If you are really listening, what they tell you will lead you
to what questions you need to ask next.
3. Feedback – next, your job is to provide feedback of what you heard to ensure you understood correctly
what they were saying. Do this by repeating back to them what you heard them say using paraphrasing or
mirroring their words.
4. Agreement – ensure you have agreement from the business of what the requirement really is.
Remember that questions elicit the business reasons for what they want and you need to act as their
guide to define clarity around those needs.

Sowmya Teja Page 5
Categorizing Requirements
To present and maintain requirements, think of them as belonging to categories. Each category of
requirement is built on the previous category, starting with business requirements, followed by
functional requirements, and ending with technical requirements.
Check out the breakdown of each category for an easy reference on how to categorize your requirements:
Business Requirements:
These are detailed descriptions of the information, business activities, business rules, and interactions
needed to accomplish the business mission. A business requirement addresses what the business
problem is, what the business needs to accomplish, and/or what are the business goals, including…
Project initiation: A statement of purpose, objectives, and risks of the project. The project scope
description and diagram are the first source of Business Requirements.
Information needs: Descriptions of the business information that is used by the Business Area (entities
and attributes).
Business processes/activities: Descriptions of the work done by the Business area to accomplish their
goals and objectives.
Business rules: Constraints or conditions that control when and how an activity is performed, they are
operating principles about the business.
Functional Requirements:
For each business requirement that is to be automated, describe how it should be automated and what
the software will “look like” to the end user. For business requirements that will not be automated,
document the manual procedure and employee guidelines. Functional requirements describe the view
from the user’s perspective of how the system or process will work, including…
Design area scope: Description of which business requirements will be automated (Use Case diagram).
System functionality: How the user will interact with the software. These are often documented with
Use Cases.
Data definitions: What the business data will look like, allowable values, default values, field lengths, etc.
Quality attributes: Descriptions that indicate how well the system performs a behavior or lets the user
take some action.
User classes: Groups of people who will be using the new application software or process (actors,
external agents).
User interfaces: Screen layouts, report layouts, and procedural descriptions.
Performance standards: Volume of transactions, number of users, speed of response, etc.
Security requirements: Levels of access required, password length and type, audits and/or logging
required.

Sowmya Teja Page 6
Technical Requirements
These are detailed descriptions of database definitions, database triggers, stored procedures, business
rule engine logic, program logic, application interfaces, and network components to support the business
requirements and the functional requirements. A technical requirement is a requirement that describes
specifically how the business problem will be solved, and reflects the view from the technical world. This
includes…
Hardware descriptions: Are there specific types or brands of hardware that must be used?
Software descriptions: What development tools will be used, and what programming language?
Database design and data conversion requirements.
Design flows: Diagrams and descriptions that depict how programs and other system components
interface with each other.
Programming considerations: Creating reusable modules, following standard programming naming
conventions, and using consistent call sequences.
Interface requirements: Connections between this system and other existing systems. These include
interfaces, and communication mechanisms for hardware and other software systems.
Any additional technical constraints and standards.

Sowmya Teja Page 7
How to Promote Excellent Requirements
• Develop a clear vision for the product
• Ensure there is a well-defined project scope and that all members of the project team have the
same understanding of that scope.
• Stakeholders should be involved throughout the requirements process (not just in the
requirements sessions).
• Discover and represent requirements using multiple techniques and models.
• Document the requirements clearly and consistently – Choose a method of documentation and
stick to that method for the entire project.
• You must continuously validate that the requirements are the right ones to focus on. Make sure
that you are updating older requirements as you get new ones if the new ones affect previously
gathered requirements.
• Frequently review the requirements and remove unnecessary ones.
• Prioritize the requirements (ex: must have, nice to have, optional)

Requirements Everywhere

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Requirements Everywhere

Similar to Requirements Everywhere (20)

Recently uploaded

Recently uploaded (20)

Requirements Everywhere