User Requirements Development​; Requirements for software development project; Stakeholders / Users ​ Requirements​; Business Requirements​; Solution ​ Requirements​; Transition ​ Requirements​; Functional – functionality behavior requirements​; Non-functional – functionality quality requirements​; Requirements elicitation; Requirements gathering.

1. Business
Requirements
Development
Mark Opanasiuk
Kyiv, 2022

2. Our agenda for this conversation 🎯
1. Classification of requirements
2. Business requirements overview
3. Requirement development stages
4. BRD for business requirements
5. Tips for business requirements elicitation
6. Faults when gathering business requirements
7. Questions and Answers

3. Classification of
Requirements
🙈🙉🙊
1. What types of requirements do we know?
2. How to differ one type of requirements from other requirements?
3. Which requirements are the most important?
4. Why should we treat differently different types of requirements?

4. Business
Requirements
Requirements for software development project:
BABOK 2.3. Requirements Classification Schema
Stakeholders / Users
Requirements
Solution
Requirements
Transition
Requirements
WHY? High-level
statements detailing
goals, objectives, and
needs, that describe
why a change has been
initiated at enterprise, a
business area, or a
specific initiative level.
WHO? The needs of
stakeholders (can be
conflicting) to be
fulfilled to achieve the
business requirements.
- Customer
- End-Users
- SME (Experts)
- Regulators
- Sponsors
- Suppliers
- Testers
- and others...
HOW? Detailed
capabilities and
qualities of a solution
that meets
stakeholders'
requirements
Functional –
functionality
behavior requirements
Non-functional –
functionality quality
requirements
These requirements are
temporary in nature:
- capabilities that the
solution must have and
- conditions the
solution must meet
to facilitate the
transition from the
current state to the
future state.

5. Business Requirements
Overview 💼
Business requirements:statements of goals, objectives,and outcomes that describewhy a
changehas been initiated and how successwill be assessed. They can apply to the whole of
an enterprise,a business area, or a specific initiative.
Business Requirementsdescribe why the organization is undertakingthe project.Business
requirementsmay be documented in several ways such as a project charter,business case, or in
a project vision and scope statement or as BRD.
Examples: increased revenue/throughput/customerreach,reduced expenses/errors, improved
customer service, etc.

6. Business Requirements !=
Stakeholders Requirements
Business Requirements
Business requirements define the goals and
objectives that the organization strives to
achieve on enterprise, a business area, or
a specific initiative level.
Business requirements also define the scope of
the solution. Solution scope is generally
defined using features.
Stakeholders Requirements
Stakeholder requirements are the specific
needs and wants of groups or
individuals within the organization or
product's end users.
User requirements are generally documented
using narrative text, use cases, scenarios, user
stories, or event-response tables.

7. Business Requirements !=
Functional Requirements
Business requirements
Business requirements describe what the
deliverables are needed, but not how to
accomplish them. Some organizations include
functional requirements in BRD. These
functional requirements detail how a system
should operate to fulfill the business
requirements.
Business requirements are the means to
fulfilling the organization’s objectives. They
should be high-level, detail-oriented, and
written from the client’s perspective.
Functional requirements
Functional requirements describe how to
accomplish the deliverables that are needed. Are
documented in the project’s functional
requirements or even in BRD
Functional requirements are much more specific
and narrowly focused and written from the
system’s perspective. Functional requirements
define effective solution that meets the business
requirements and client’s expectations for that
project.

8. Examples of Business Requirements
• Problem Statement
• Project Vision
• Project Constraints (Budget, Schedule, and Resource)
• Business Objectives
These are also business requirements:
• Project Scope Statements (Features) - Solution scope is generally defined using features. Not properly defining
solution scope generally results in scope creep and solutions that are not aligned with business needs.
• Business Process Analysis deliverables - to determine how the business processes worked and will work.
• Stakeholder Analysis results - are needed to determine who will be impacted by the system and how best to
engage the impacted / relevant people to obtain user requirements.
• Impact Analysis – identifies what is affected now and what will be affected by such changes.

9. Source: Analyst Zone
Stakeholders Analysis

10. Source: Analytic Steps
Business Analysis
Process

11. RequirementsLifecycle &
Development Stages 🔁
1. What is requirements lifecycle?
2. What is the difference between requirements and designs
3. What are requirements development stages?
4. Are there differences for requirement lifecycle in agile & waterfall projects?

12. RequirementsLifecycle ♻️
BABOK Chapter 5

13. RequirementsLifecycle ♻️
Trace Requirements: analyzes and maintains the relationships between requirements,designs, solution
components, and other work products for impact analysis, coverage,and allocation.
Maintain Requirements: ensures that requirements and designs are accurate and current throughout the
life cycle and facilitates reuse where appropriate.
PrioritizeRequirements: assesses the value, urgency, and risks associated with particular requirements and
designs to ensure that analysis and/or delivery work is done on the most important ones at any given time.
Assess RequirementsChanges: evaluates new and changing stakeholder requirements to determine if they
need to be acted on within the scope of a change.
Approve Requirements: works with stakeholders involved in the governance process to reach approval and
agreement on requirements and designs
BABOK Chapter 5: Requirements Life Cycle Management

14. RequirementsDevelopment Stages
There are six (6) basic requirements development steps and those really don’t change depending on
which model or framework is used. All models are similar in their approach; they just depict them
differently graphically.
Requirement development includes all the activities and tasks associated with discovering, evaluating,
recording, documenting, validating, and further managing requirements

15. Step 1:
Gather & Develop Requirements
Gather and develop requirements from key stakeholders,project objectives,and already developed
requirements.
• Develop Requirements - the requirements don’t have to be perfect at this step, just documented,
prioritized,de-conflicted,and initially validated with stakeholders. It’s critical to have stakeholders
approve that the documented requirements meet their needs.
• Record Requirements - As you gather requirements, remain consistent in form and in terms of the
information you capture for each (at least document what is the requirement, who was the
source, rationale for the requirement,desired priority, who is affected,and who can elaborate more on
this requirement).
• PrioritizeRequirements - One characteristic of excellent requirements management is that the
requirements are classified and prioritized.You need to know what are the essential requirements.

16. Step 2:
Write and Document Requirements
The requirementsmust be documentedin order to establish a requirementsbaseline to
start buildinga system and manage any changes.
This step focuses on writing down business,stakeholders,solution level requirementsinto
the appropriate requirementsdocuments.
Business Requirements Document – is an example of deliverables that collect business
requirementsand solution requirements(optional).+ other deliverables that have details.
Questions to ask: Were all important stakeholders' requirementsdocumented?Was each
requirementcheckedif it is unambiguous(clear), feasible, necessary, concise,testable, etc.?

17. Step 3:
Check Completeness
Check that complete set of requirementshave been developed and documented that
defines all system functionsthat are needed to satisfy the stakeholder needs with their
functional and non-functional requirements.
RequirementTracing – helps to verify that a requirement meets level objectives and to get
rid of a requirement that doesn’t. Ensures that requirementscontinueto meet the needs and
expectationsof its stakeholders.We can trace requirementsto each other and to the source.
Requirementchecklists & walk-through processes are defined.

18. Step 4:
Analyze, Refine & Decompose
Examine each requirement to see if it meets the characteristicsof a good requirement.Each
requirementis then decomposed into a more refined set of requirementsthat are allocated
to sub-systems,designs,and documented – in other words, it is called Scope Refinement.
In the waterfall framework,it is done in advance when preparingRequirements
Specification document (that may have hundredsof pages). For agile frameworks,it is an
ongoing process done regularlyas the team proceeds with the product development and
new scope is introduced.

19. Step 5:
Verify & Validate Requirements
“Verify & Validate Requirements,” each requirement must be verified and validated to ensure
that they are the correct requirement. This ensures that the requirements meet the overall
objective of the business and all stakeholder needs. Verification and Validation should be
done continuously throughout the development of requirements at every level and as part of
baseline activities
Validate: Confirms that a requirement meets the intent of the stakeholder. “Does the
requirements clearly and correctly communicate the stakeholder expectations and needs?”
Verify: Confirms that the requirements can meet the intended objective. “Is the requirement
written correctly in accordance with the organization’s standards, guidelines, rules, processes, and
checklists?”

20. Step 6:
Manage Requirements
Any changes to the requirementsare controlled using a change managementprocess.
Managing requirementsis a continuousprocess. The purpose is to assure that the
requirementscontinueto meet the needs and expectations of its customersand
stakeholders through the lifecycle.
Requirements managementtool: special-purposesoftware that provides support for any
combination of the following capabilities:elicitation and collaboration,requirements
modelling and/or specification,requirementstraceability,versioning and baselining,
attributedefinition for trackingand monitoring,document generation,and requirements
change control

21. Requirements management
- planning, executing,
monitoring, and controlling
any or all work associated
with requirements elicitation
and collaboration,
requirements analysis and
design, and requirements life
cycle management.
Requirements management
plan - a subset of the
business analysis plan for a
specific change initiative,
describing specific tools,
activities, and roles and
responsibilities that will be
used on the initiative to
manage the requirements

22. Requirements&
Designs
Both requirements and designs are important
tools used by business analysts to define and
guide change.
Requirements are focused on the need.
Designs are focused on the solution.
The distinction between requirements and
designs is not always clear. The same
techniques are used to elicit, model, and
analyze both. A requirement leads to a
design which in turn may drive the discovery
and analysis of more requirements. The shift
in focus is often subtle.
BABOK Chapter 7 + Chapter 2.5

23. Stakeholders may present a need or a solution to an assumed need. A business analyst
transformsthat request into a requirementor design.

24. BRD for Business Requirements 📗
1. What are the qualities of a good BRD?
2. How large and detailed shall be the BRD? Can BRD be a one-pager?
3. What are the main challenges that BA may face when drafting BRD?
4. What are the most efficient elicitation techniques in your opinion?

25. Best Practices for Creating BRD 🛠️
A business requirementsdocument (BRD) describes the business solution for a project (i.e.,
what a new or updated product should do), includingthe user's needs and expectations,the
purpose behind this solution,and any high-level constraintsthat could impact a successful
deployment.
BRD makes it easier to collect and process requirementsfor the project.It gives a clear
structureand topics that need to be covered, simplifies discussion and validation of those
requirementswith stakeholders,helps to kick-off the project faster, and ensure everyone is on
the same page regardingproject goal and objectives.

26. Best Practices for Creating BRD 🛠️
The structuremay vary but a basic BRD may includethe following sectionsand components:
(1) Project overview (includingvision, objectives,and context); (2) Successfactors; (3) Project
scope; (4) Stakeholder identification; (5) Business requirements; (6) Scope of the solution; (7)
Project constraints(such as scheduleand budget) and risks; (8) Quality control measures.
+ Glossary of terms
Some teams may need to includeadditional sectionsdepending on the needs and complexity
of the project,such as a (9) current assessment,a (10) futureprocess map, and (11) staff
trainingneeds, etc.
Additionally, depending on the organization’s documentation process, sections for
(12) functional and (13) non-functional requirementsmay also be includedin a BRD
Lucidchart on BRD

27. Practice effective
requirements elicitation
Primary elicitation methods are (1) Document analysis, (2) Brainstorming,
(3) Requirement workshops, (4) Surveys, (5) Focus groups, (6) Observations, (7) Prototyping,
(8) Interviews, (9) Interface analysis.
Other elicitation techniques:
(10) Benchmarking and Market Analysis; (11) Business Rules Analysis; (12) Collaborative Games;
(13) Concept Modelling; (14) Data Mining; (15) Data Modelling; (16) Mind Mapping; (17) Process
Analysis; (18) Process Modelling.
Use clear language, learn stakeholders, come prepared, continually gather requirements.
BABOK 4.2.6 Elicitation Techniques

29. Faults When Gathering
Business Requirements 🤦‍♂️
1. What mistakes can happen when gathering business
requirements?
2. What are consequences of failing to conduct proper business
requirements elicitation?
3. How can we minimize faults and errors when gathering
business requirements?

30. “Fail to prepare,
and you prepare to fail...” 💩
• Misunderstanding implications of suggested stakeholders' requirements.
• Underestimating the amount of effort involved in the development process.
• Conflicting or unclear requirements, client is changing its mind too frequently, feature creep.
• Lack of initial requirement gathering, poorly defined initial business requirements.
• Uninvolved stakeholders during the requirements gathering process.
• Making false assumptions, instead of asking stakeholders.
• A lack of clearly defined success criteria, goals, and objectives.
• Not enough communication or over-communication with the customer.
• Not validated or not approved business requirements.
• Focusing on solution's technicalities instead of business needs.

31. + Bonus content 🔥
• 40+ free BRD templates & examples for projects of any type:
https://bit.ly/brd_templates + PandaDoc BRD template
• Great article on BRD requirementsby LucidChart
• Business RequirementsAnalysisarticlefrom mindtools.com
• Requirementdevelopmentguide for AeroSpaceindustrywith tons of other
useful content for BAs & PMs (yep, it is a waterfall,but a really cool one)

32. Thank you!
Q&A
Mark Opanasiuk
Let's connect on LinkedIn
TG channel: @wtf_is_pmf
Medium: @markopanasiuk