This pack is one that I have used previously to train business analysts and PMs on best practice for requirements creation and management.

1. Requirements Gathering Best Practice
Training Pack

2. Contents
What is a Requirement?
What is a GOOD Requirement?
Gathering Requirements
Managing Requirements

3. What is a Requirement?

4. Requirements- An Introduction
It's difficult to build a solution if you don't know the requirements (in spite of the fact that
many teams still try to do it today!).
There are a number of types of
requirements:
•
Business Requirements- what is the
business need
•
Functional Requirements- how
should the system meet the business
requirement
•
Technical Requirements- how should
the system technically meet the
functional requirement
This pack focuses on the creation of Business Requirements.

5. 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 8is, 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.

6. 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.
→ 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 behaviour 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.

7. 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
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

8. The Importance of Requirements
Organizations need to effectively define and manage requirements to help ensure they the end
solution meets the customer/ stakeholder needs, while addressing compliance and staying on
schedule and within budget.
The impact of a poorly expressed requirement can be devastating; it can have a domino effect
that leads to time-consuming rework, inadequate deliveries and budget overruns.
Even worse, a poor requirement can bring a business out of compliance (leaving the business
open to huge financial penalties) or even cause injury or death.
If we don’t know what we are trying to create we will never create a solution that is fit for
purpose. For most of our projects we are providing a solution or capability for the businesstherefore the business requirements must always come from the business stakeholders!

9. What is a GOOD Requirement?

10. The Importance of GOOD Requirements
We don’t just need requirements we need good requirements which are clear and specific. Poor
requirements can easily be interpreted in many different ways…

11. What is a GOOD Requirement?
Because requirements are the foundation of any development project, teams need to understand
the attributes of a good requirement.
The best requirements are:
• Complete (express a whole idea or statement)
• Correct (technically and legally possible)
• Clear (unambiguous and not confusing)
• Verifiable (it can be determined that the system meets the requirement)
• Necessary (should support one of the project goals)
• Feasible (can be accomplished within cost and schedule)
• Prioritized (tracked according to business need levels)
• Consistent (not in conflict with other requirements)
• Traceable (uniquely identified and tracked)
• Modular (can be changed without excessive impact)
• Design-independent (do not pose specific solutions on design)

12. 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.
Example:
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 employees last name, first name, middle initial, street
address, city, state, zip code, marital status’

13. Correct Requirements
The requirements should be appropriate to meet the goals of the project and accurately
describe the user’s expectations of the functionality.
Example:
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 or be
made alone’

14. Clear (Ambiguous) 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 requirements.
Example:
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 hour sin a 7 day period, a
warning is provided to the supervisor and the payment is held for approval.’

15. Verifiable Requirements
Each requirement should be testable and verifiable.
Example:
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 to use or not.
Verifiable Requirement:
‘A novice user must be able to add a new employee to the payroll system within 10 minutes’

16. Necessary Requirements
Requirements must be necessary and clearly support one of the original project goals or
objectives.
Example:
Unnecessary Requirement:
‘’We should be able to enter the employee eye colour’
→ This is a great example of a time when the BA needs to ask, ‘Why is this requirement
necessary?’

17. Feasible Requirements
The business analyst must be sure that all requirements are technologically possible for a
reasonable cost.
Example:
Unfeasible Requirement:
‘The system should automatically be updated when the government changes the law’
→ Although this requirement may be technologically feasible, it would involve a complex
interface (and likely new government system) with an outside organisation which would be
very expensive and difficult to negotiate. Is it a critical requirement?

18. Prioritised Requirements
Each requirement should be prioritised. Most organisations use the MoSCoW method for
prioritisation:
→ Must Have- the system must meet this requirement for the end product to be considered a
success.
→ Should Have- the system should have this requirement for it to solve the main business
problem.
→ Could Have- it would be good to include this requirement to ensure maximum benefit.
→ Would Have- this is a nice to have requirement which the business could do without if
necessary.

19. Top Tips for Getting Good Requirements
→ Ask Questions- you job is to help the business solve a problem. It’s not always what the
person says that’s important, sometimes its how they say it that you need to pay attention
to.
→ 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.
→ 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.
→ 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.

20. Gathering Requirements?

21. Gathering Business Requirements- An Introduction
The "elicitation" step is where the requirements are first gathered from the stakeholder.
Requirement gathering is often a challenging exercise as you need to work with stakeholders
who have day jobs and competing demands. Often the business expect you to create the
requirements but without the business input you will not create an end product which is fit for
the business purposes.
Many techniques are available for gathering requirements. Each has value in certain
circumstances, and in many cases, you need multiple techniques to gain a complete picture
from a diverse set of clients and stakeholders.

22. Gathering Techniques: One to One Interviews
The most common technique for gathering requirements is to sit down with the stakeholders
and ask them what they need.
Remember that your job as a business analyst is to help the business solve a problem they
have.
The discussion should be planned out ahead of time based on the type of requirements you're
looking for.
There are many good ways to plan the interview, but generally you want to ask open-ended
questions to get the interviewee to start talking and then ask probing questions to uncover
requirements.
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 is important, sometimes its
how they say it that you need to pay attention to.

23. Gathering Techniques: Group Interviews
Group interviews are similar to the one-on-one interview, except that more than one person is
being interviewed -- usually two to four.
These interviews work well when everyone is at the same level or has the same role.
Group interviews require more preparation and more formality to get the information you
want from all the participants.
You can uncover a richer set of requirements in a shorter period of time if you can keep the
group focused.
The discussion generated by group interviews allows the teams to ‘thrash’ out requirements to
ensure that you get good requirements.

24. Gathering Techniques: Facilitated Sessions
In a facilitated session, you bring a larger group (five or more) together for a common purpose.
In this case, you are trying to gather a set of common requirements from the group in a faster
manner than if you were to interview each of them separately.
These are often held as Conferences and Workshops.

25. Gathering Techniques: Joint Application Development (JAD)
JAD sessions are similar to general facilitated sessions.
However, the group typically stays in the session until the session objectives are completed.
For a requirements JAD session, the participants stay in session until a complete set of
requirements is documented and agreed to

26. Gathering Techniques: Questionnaires
Questionnaires are much more informal, and they are good tools to gather requirements from
stakeholders in remote locations or those who will have only minor input into the overall
requirements.
Questionnaires can also be used when you have to gather input from dozens, hundreds, or
thousands of people.
Be careful about how you structure and word your questionnaires. Ensure that you do not ask
leading questions and ensure that you use open questions as far as possible.
When consolidating data ensure that you accurately represent individuals responses within
any outcome statistics.

27. Gathering Techniques: Prototyping
Prototyping is a relatively modern technique for gathering requirements.
In this approach, you gather preliminary requirements that you use to build an initial version
of the solution -- a prototype.
You show this to the stakeholder, who then gives you additional requirements. You change the
application and cycle around with the stakeholder again.
This repetitive process continues until the product meets the critical mass of business needs or
for an agreed number of iterations.
A downside of this method is that you can end up forever changing the prototype and never
progressing to a full system. To minimize this impact you should set clear timeline for
prototyping and set clear expectations on the number of rounds you will conduct.

28. Gathering Techniques: Use Cases
Use cases are basically stories that describe how discrete processes work.
The stories include people (actors) and describe how the solution works from a user
perspective.
Use cases may be easier for the users to articulate, although the use cases may need to be
distilled later into the more specific detailed requirements

29. Gathering Techniques: Following People Around
This technique is especially helpful when gathering information on current processes.
You may find, for instance, that some people have their work routine down to such a habit
that they have a hard time explaining what they do or why.
You may need to watch them perform their job before you can understand the entire picture.
In some cases, you might also want to participate in the actual work process to get a hands-on
feel for how the business function works today

30. Gathering Techniques: Brainstorming
On some projects, the requirements are not "uncovered" as much as they are "discovered."
In other words, the solution is brand new and needs to be created as a set of ideas that people
can agree to.
In this type of project, simple brainstorming may be the starting point.
The appropriate subject matter experts get into a room and start creatively brainstorming
what the solution might look like.
After all the ideas are generated, the participants prioritize the ones they think are the best for
this solution.
he resulting consensus of best ideas is used for the initial requirements

31. Managing Requirements?

32. Managing Requirements: Introduction
Once you have gathered your requirements there are ten steps that can help you better define
and manage requirements:
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
Structure Requirements
Manage and link customer needs, requirements and contracts
Manage constraints
Visualize requirements
Test requirements
Bridge the chasm between business and development
Control change to requirements
Capture and track metrics and trends
Provide examples of goof requirements
Reuse Requirements

33. Structure Requirements
Duplicate requirements can cause work to be performed twice, lead to conflicts, and
eventually double your maintenance cost.
Omitted requirements may lead to missing functionality or cause shortcomings (see below,
“Constraints”).
Requirements should be structured to enhance understanding while avoiding duplication and
omission.
Traceability to higher- and lower-level requirements enables teams to assess coverage.
Structuring requirements is the first step in taking control and improving the quality of
requirements.

34. Manage and link stakeholder needs, requirements and contracts
Organizations typically collect the stakeholder’s needs, captured “as is.”
These needs undergo an internal translation to requirements in a format that meets the
requirements characteristics described above. They may also be made more generic and less
customer-specific (so the system can meet multiple customer needs). There is also often a
stable contractual agreement, a legally binding third document. Organizations need to capture
these levels of user requirements, maintaining intelligent traceability and change impact
analysis between them.
Specifications and contractual documents should be generated from the requirements
repository; this central location should also maintain links to outside elements (e.g., customer
documents, e-mails and contracts).
By managing the multiple representations of customer needs, organizations have better
control over contractual agreements and increase the chance of project success.

35. Manage Constraints
Requirements must not only describe functional behavior.
Nonfunctional requirements, also called constraints, can be critical for compliance and
regulations and can add quality to the system. Typical nonfunctional requirements can specify:
→ Performance
→ Interface
→ Security
→ Safety
→ Reliability
→ Availability
→ Maintainability
Writing better requirements includes providing coverage for constraints since shortcomings in
these areas (e.g., performance, reliability and ease of use) generally cannot be reengineered
back into the system once developed. By ensuring that they take into account all types of
constraints relevant to their industry, organizations greatly increase their projects’ chances of
success

36. Visualise Requirements
Most requirements analysts find augmenting textual requirements with modeling helpful,
whether this means drawing pictures on a whiteboard, utilizing presentation tools such as
PowerPoint or simply creating a mental model.
These representations should be managed alongside the requirements to help ensure
consistency, traceability and change control.
Visual requirements modeling provides a simple and powerful way to communicate with, and
elicit requirements from, customers and end users.
It also helps clarify requirements and create a common understanding between all
development team members and stakeholders.
Although models and images should not replace clear, unambiguous textual requirements, by
empowering visual requirements, organizations increase communication and collaboration
across all stakeholders.

37. Test Requirements
An efficient way to better manage requirements is to ensure they are clearly mapped to test
cases.
Making sure each requirement is clearly verifiable from the start not only helps prepare later
phases of the project, but it also puts the writer in the correct state of mind.
Note that this is true for the nominal functional mode (making sure the system or software
does what it’s supposed to do). Requirements and their associated tests must also indicate
what the system should not do, and what happens at the limits (degraded mode).
This rule also applies to constraints (nonfunctional requirements): Indicating how they shall be
tested is a good way to write better requirements. For instance, how would we test the
requirement “The software must be highly usable”? A better requirement would be, “An
untrained user will be able to generate a report in less than three minutes,” for instance.
Organizations that ensure their requirements are clearly testable, early on in the process, can
improve project success rates and enhance quality.

38. Bridge the Chasm between Business and Development
In many cases, the route to better requirements management is to have fewer requirements.
Projects cannot always offer the luxury of implementing all customer requests, marketing
ideas and business suggestions when they also have to meet budget and deadline objectives.
Rather than trying to manage every requirement, project and product managers must be able
to make decisions on those requirements that bring the most value to the customer and help
the business improve innovation.
This can be achieved by combining value and priority information from stakeholders and
defining the right combination of requirements.
By creating and maintaining this link between engineering requirements and business and
customer needs, senior management can help ensure that resources are spent efficiently.
Development and implementation can similarly align technical decisions with the
organization’s strategy.

39. Control Change to Requirements
Requirements are subject to continual change.
As a project progresses, organizations need to remain agile, adapt to engineering imperatives
and respond to evolving marketplace situations and customer needs.
Writing a perfect first requirement is insufficient if its evolution isn’t well managed—poorly
controlled change can lead to inadequate systems and software, rework effort and loss of
revenue.
Organizations need to implement a reliable and repeatable change control process that helps
turn this challenge into an opportunity.
As a result, they’ll be more competitive, control schedules and respond to evolving customer
needs.

40. Capture and Track Metrics and Trends
Today’s complex projects demand automated data collection and reporting facilities to
streamline project management. As such, project managers and all stakeholders need a
“management dashboard” of metrics and trends that enables them to quickly monitor project
activities such as the progress, growth and volatility of actual requirements.
In other words, project managers need to keep their focus on decision making instead of
manually gathering data and compiling reports. Most importantly, the display of key
requirements monitoring information must be at a high level, allowing users to manage by
exception and spot trouble areas quickly.
A high change frequency on a specific requirement or a whole subsystem may indicate that the
requirement needs to be revisited with the customer. A large amount of rework on
implementation may point at a poorly specified original requirement.
Trends should also be used to learn lessons from past systems and software projects: Could
issues and problems have been identified earlier on? This wealth of information must be used
to build the organization’s knowledge database.

41. Provide Examples of Good Requirements
By providing examples and counterexamples of good requirements and documents,
organizations can enhance the quality, consistency and completeness of their requirements.
The next step should be to use good (and bad) requirements from each project that reflect the
organization’s domain expertise to build a corporate knowledge database. Textbook
requirement examples rarely reflect a company’s needs as well as their own previous
experience.
Past requirements should be annotated during a project postmortem to indicate any notable
information (positive or negative).
New projects can, for example, examine the traceability that previous projects have used for
regulations to understand how they were taken into account, and to identify teams that have
already achieved compliance for their projects.

42. Reuse Requirements
When a good requirement has been written for a previous project and it is applicable to a
present situation, the natural reaction is to reuse it, generally by copying and pasting the
description.
This unfortunately breaks the traceability and eliminates impact analysis. A smarter approach
to reuse is to maintain a link between the two requirements (for example, creating a reuse
type link).
This enables analysts to access the original requirement at any time to check allocation of
implementation, for instance.
Likewise, any changes made to the original requirement (issues detected, updates needed) can
lead to the notification of reusing teams.
By implementing smart requirements reuse, organizations can improve knowledge sharing
across teams and facilitate impact analysis.

43. Any Questions?