The document outlines a comprehensive approach to user requirements development, detailing the types of requirements needed for software projects, including business, stakeholder, solution, functional, and non-functional requirements. It emphasizes the importance of stakeholder involvement, user stories, and acceptance criteria in validating user requirements and provides various techniques for eliciting, analyzing, and documenting these requirements, such as use cases, job stories, and work breakdown structures. Additionally, it highlights the significance of non-functional requirements, which pertain to the quality attributes of the system, and offers guidance on their elicitation and analysis.

1. User
Requirements
Development
Mark Opanasiuk
Kyiv, 2022

2. A typical requirements capturing process encompasses four
elements

3. RequirementsLifecycle ♻️
BABOK Chapter 5

4. Requirements types:

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

6. User Requirements 📗
The needs of discretestakeholder groups (top-level managers, nonmanagement
staff, customers,etc.) are specified to define what they expect from a particular solution.This
requirements group serves as a bridge between the generalized business requirementsand
specific solution requirements.
Stakeholder requirements: describe the needs of stakeholders that must be met to achieve
the business requirements.They may serve as a bridge between business and solution
requirements(BABOK).
User requirements cover the different goals end-users can achieve using the product and are
commonly documentedin the form of user stories, use cases, and scenarios.

7. User Requirements in Waterfall 📗
The user requirement(s) document (URD) or user requirement(s) specification (URS) is a document
usually used in software engineering that specifies what the user expects the software to be able to
do.
Once the required information is completely gathered it is documented in a URD, which is meant to
spell out exactly what the software must do and becomes part of the contractual agreement. A
customer cannot demand features not in the URD, while the developer cannot claim the product is
ready if it does not meet an item of the URD.
The URD can be used as a guide for planning costs, timetables, milestones, testing, etc. The explicit
nature of the URD allows customers to show it to various stakeholders to make sure all necessary
features are described.

8. User Requirements 📗
• Stakeholder involvement is essential for validating the user requirements.Are these the
correct user requirements?
• Elicitation techniquesenables the discovery and understandingof the needed
requirementsby the users.
• Analyze and comparealternative requirementsand their cost impacts on the project.
• Traceabilityof user requirements is critical.Support documentation,and link those to
solution-level requirements.

9. Functional &
Non-Functional
Requirements
Mark Opanasiuk
Senior Business Analyst @ EPAM
Kyiv, 2022

10. Solution Requirements
Functional Requirements
Functional requirements: describe
the capabilities that a solution must
have in terms of the behavior and
information that the solution will
manage
Non-Functional Requirements
Non-functional requirements or
quality of service requirements: do
not relate directly to the behavior of
functionality of the solution, but rather
describe conditions under which a
solution must remain effective or
qualities that a solution must have

12. Functional &
Non-Functional Requirements 📗
Functional requirements describe what the product should do, while non-functional requirements
place constraints on how the product should do it. They can be expressed in the following form:
• Functional requirement: "The system must do [requirement]."
• Non-functional requirement: "The system shall be [requirement]."
Examples:
• Functional requirement: "The system must allow the user to submit feedback through a contact
form in the app."
• Non-functional requirement: "When the submit button is pressed, the confirmation screen must
load within 2 seconds."

13. Functional Requirements 📗
Functionalrequirements are product featuresor functionsthat developers must implement to
enable users to accomplish their tasks.So, it’s important to make them clear both for the
development team and the stakeholders.Generally,functional requirementsdescribe system
behavior under specific conditions.
For example:
The system sends an approval request after the user enters personal information.
A search feature allows a user to hunt among various invoicesif they want to credit an issued
invoice.
The system sends a confirmationemail when a new user accountis created.

14. Functional Requirements
Classifications 📗
We can group them based on the functions a featuremust perform in the product,for example:
Authentication
Authorization levels
Compliance to laws or regulations
External interfaces
Transaction processing
Reporting
Business rules, etc.

15. Requirements
Documents Formats 📗
Most common formats and documents:
 Software RequirementsSpecification (SRS) document
 Use cases
 User stories
 Work Breakdown Structure(WBS), or functional decomposition
 Prototypes
 Models and diagrams

16. SRS📗
Both functionaland nonfunctionalrequirements can be formalized in the software
requirements specification(SRS) document.
SRS must includethe following sections: Purpose.Definitions,system overview, and
background; Overall description.Assumptions,constraints,business rules, and product
vision; Specific requirements. System attributes,functional requirements,and database
requirements.
The SRS can be a single documentcommunicatingfunctionalrequirements or it may
accompany other software documentation like user stories and use cases.
Goal: to document requirementsfor every single feature before buildingit!!!

17. Use Cases📗
Use cases describe the interaction between the system and external users that leads to achieving
particular goals. Each use case includes three main elements:
Actors. These are the external users that interact with the system.
System. The system is described by functional requirements that define an intended behavior of the
product.
Goals. The purposes of the interaction between the users and the system are outlined as goals.
There are two formats to represent use cases:
 Use case specification structured in textual format
 Use case diagram

18. Use Case Specification Example

19. Use Case Diagram

20. User Stories📗
A user story is a documented description of a software feature seen from the end-user perspective.
The user story describes what exactly the user wants the system to do. In Agile projects, user stories
are organized in a backlog, which is an ordered list of product functions. Currently, user stories are
the most popular format for backlog items.
User stories must be accompanied by acceptance criteria. These are the conditions that the product
must satisfy to be accepted by a user, stakeholders, or a product owner.
Effective acceptance criteria must be testable, concise, and completely understood by all team
members and stakeholders. They can be written as checklists, plain text, or by using
Given/When/Then format.
Contrary to a popular misconception, functional requirements are not analogous to user stories,
but stories can be a useful tool for deriving requirements with the user in mind.

21. User Stories📗
All user stories must fit the INVEST quality model:
 I – Independent for separate work
 N – Negotiable for detalization during development
 V – Valuable for customer
 E – Estimable to schedule and prioritize implementation
 S – Small enough to be done within sprint
 T – Testable to ensure that requirementsare done

22. User Stories📗
• User story: As an existing user, I want to be able to log into my account.
• Functional requirements:
• The system must allow users to log into their account by entering their email and
password.
• The system must allow users to log in with their Google accounts.
• The system must allow users to reset their password by clicking on "I forgot my
password" and receiving a link to their verified email address.

23. User Story is based on User Personas & Assumptions
User Story – focuses on functions and solutions. Situation context, user
motivation and anxieties are ignored. ​Explains Who users are (roles and
atributes) and What they do (actions) but may miss Why they do...
As a [user persona], I want to [user action], So that [action outcome].
Too many assumptions
Who? - May be irrelevant
What? - Are we sure this is
the best action to do... Expected result
Source: Adapted from Jobs-to-be-done book by Intercom

24. Job Story focused on Context & Motivation
Job story focuses on the triggering event or situation, the
motivation and goal, and the intended outcome.
Job Stories can only come from real customer interviews.
When [trigger], I want to [goal], So I can [desired outcome].
Situation or Event User motivation Expected result
Source: Adapted from Jobs-to-be-done book by Intercom

25. User Story vs. Job Story
USER STORY
(focuses on user persona and solution)
JOB STORY
(discoveredfrom users' experience)
WHO: As a user of news app connected to wi-fi,
WHAT: I want to save in cache memory 50 recentnews
articlesfrom the news feed,
OUTCOME:So I can access and read those later.
Questions: But does user really want this? Why 50 articles?
Why is it importantfor user to read those later?Do we need to
refresh the cashednews when user has accessto the internet?
SITUATION: When I am not connected to free wi-fi,
GOALS:I want to be able to read recent news for free
AND have access to those news even offline,
OUTCOMES:So I will save money on expensive mobile
traffic AND stayinformed on recent news.
Provides more context,gives more space to think aboutthe
best solution to be detailed in designs and tasks
.
Solutionssuggested: cache recentnews in app when
connectedtoWi-Fi + publish news as FBInstantArticles on
our FB page (FB trafic is free in many African countries)
Jobs stories slightly revise the format to be less prescriptive of a user action, and thereby give
more meaningful information for the designer and developer to buildfor the user’s expected
outcome.

26. Functional decomposition or
Work Breakdown Structures (WBS)📗
WBS is a visual document that illustrates how complex processes break down into their simpler
components.WBS is an effectiveapproach to allow for an independent analysis of each part.
WBS also helps capture the full pictureof the project.
• Find the most general function.
• Find the closest sub function.
• Find the next level of sub function.
• Check your diagram.
High Level Function->Sub-function -> Process -> Activity

27. Functional decomposition or Work Breakdown Structures (WBS)

28. Software prototypes📗
Software prototype is an umbrella term for different forms of early-stage deliverables that are built
to showcase how requirements must be implemented. Prototypes help bridge the vision gaps and
let stakeholders and teams clarify complicated areas of products in development.
Prototypes can be cheap and fast visual representations of requirements (throwaway prototypes) or
more complex ones (evolutionary prototypes) that can even become MVPs.
Wireframes - a two-dimensional illustration of an interface that specifically focuses on space
allocation and prioritization of content, functionalities available, and intended behaviors.
Mockups - detailed visual designs that convey the look and feel of the final product.
Prototypes - allow for some interface interactions, like scrolling, clicking on links, or filling in forms

30. Non-Functional Requirements 🛠️
(NFR)
Non-FunctionalRequirements(NFR) - Non-functional requirements(also known as quality
attributesor quality of service requirements)are often associated with system solutions,but
they also apply more broadly to both process and people aspects of solutions.They augment
the functional requirementsof a solution,identify constraintson those requirements,or
describe quality attributesa solution must exhibit when based on those functional
requirements.
Non-functional requirementsanalysis examines the requirementsfor a solution that defines how
well the functional requirementsmust perform. It specifies criteriathat can be used to judge the
operation of a system rather than specific behaviors (which are referred to as the functional
requirements).
BABOK 10.30.Non-Functional Requirements Analysis

31. NFRs are a huge requirements
domain 🎯
Often referred as the "-ility" requirements
1. Usability
2. Availability
3. Reliability
4. Scalability
5. But there are so many more such as...

32. Non-Functional Requirements types:

33. NFRs - Usability
Usability defines how difficult it will be for a user to learn and operate the system. Usability
can be assessed from different points of view:
Efficiency of use: the average time it takes to accomplish a user’s goals, how many tasks a
user can complete without any help, the number of transactions completed without errors,
etc.
Intuitiveness: how simple it is to understand the interface, buttons, headings, etc.
Low perceived workload: how many attempts users need to accomplish a particular task.
Usability requirements may include also language barriers and accessibility
requirements: People with no understanding of French must be able to use the product.

34. NFRs - Usability
Ease with which a user can learn to use the solution (BABOK).
- Who are target users?
- What is the usage context?
- What are the most frequentlyperformed tasks?
- What is the optimal time for each task?
- What is the longest acceptable time for each task or wait time between steps?
- What are the alternative flows for each task?
- What is the tolerance for user navigation errors?
- How do we define and measure user satisfaction?

35. NFRs - Availability
Degree to which the solution is operable and accessiblewhen required for use, often expressed as
100% minus the percentage of time a system/solution is unavailable (BABOK).
- When the system is down, or sluggish, what does this mean to our customer?
- When a user has an active session, and the DB or application goes down, how is the user or our reputation
is affected?
- What is our system unavailability tolerance?
- Is this function critical to the customer, business, or technical team? Do any other systems rely on this
function/service/module output?
- If a certain module becomes unavailable, how does it affect the system's availability?
- What is our tolerance for system goes down for the scheduled maintenance?
Example: New module deployment mustn’t impact front page, product pages, and check out pages
availability and mustn’t take longer than one hour.

36. NFRs - Availability:

37. NFRs - Reliability
Reliability defines how likely it is for the softwareto work withoutfailure for a given
period of time.
Reliabilitydecreases because of bugs in the code, hardware failures,or problems with other
system components.
To measure software reliability,you can count the percentage of operations that are
completed correctlyor track the average period of time the system runs before failing.
Example: The database update process must roll back all related updates when any update
fails.

38. NFRs - Scalability
Degree with which a solutioncan grow or evolve to handle increased amounts of work (BABOK).
- What is the projected user growth over the system lifetime?
- What is the projected resource use per user over lifetime of the system?
- How large data sets we operate? How large is user's data set?
- What is the demand for CPU / how many calls per second under normal working conditions?
- What would be considered a heavy load for the system in terms of users / data / requests?
- How shall system react in case of increasing load? What is our plan?
- What monitors can we put in place to track load and get alerts on high loads?
Example: The website attendance limit must be scalable enough to support 200,000 users ata time.

39. NFRs - Performance
Degree to which a solution or component performs its designated functions with minimum
consumption of resources. Can be defined based on the context or period,such as high-peak,
midpeak or off-peak usage (BABOK).Includes short response time,high processing rate,low CPU
utilization,etc.
- What shall be the request timeout? What shall happen if a user does not receive a response within X
seconds?
- What are the time constraints for the user performing the task?
- What is the current actual response time for our customers?
- What other systems may impact the performance of our system? How to mitigate those?
- How many transactions per second shall the system be able to handle in normal and peak usage times?
Example: The front-page load time must be no more than 2 seconds for users that access the website using
an LTE mobile connection.

40. NFRs - Security
Securityrequirements ensurethat the softwareis protected fromunauthorizedaccess
to the system and its stored data.
It considers different levels of authorization and authentication across different users roles.
For instance,data privacy is a securitycharacteristicthat describes who can create,see, copy,
change,or delete information.
Securityalso includesprotection against viruses and malware attacks.
- What user's role / permissions/ other securitycharacteristicsare required?
- What levels of authorization and authentication across different users roles are required?
Example: Access permissions for the particular system information may only be changed by
the system’s data administrator.

41. NFRs elicitation🛠️
1. Do your research before addressing NFRs, Plan elicitation ahead to frame
NFRs well for the business, send questions in advance before meetings.
2. Bring together stakeholders (such as operations and support).
3. Scenario based elicitation: What if..., GWT technique, Drill down techniques
(5Whys, root cause, decomposing into smaller pieces).
4. Define NFRs by interpreting them into business relatable ideas.
5. Find a NFRs champion among developers in your team.

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