IFS231

Unit 3 Welcome to IFS231 – 2021

Requirements analysis
(part 1)
Requirements,
Orientation for online teaching and learning programme

elicitation & gathering

 Learning objectives

At the end of Unit 3 slides, you should be able to:

1. Explain why requirements are important in business analysis,
2. Distinguish between the requirement classifications,
3. Differentiate between the types of system/solution
requirements
4. Identify and write out functional and non-functional
requirements statements for examples and case studies.
5. Discuss eight techniques that can be used to elicit
requirements.
6. Explain the Requirements Life Cycle Management knowledge
area in BABOK (Chapter 5).
 Where are we in the SDLC?

Operations
and
Implementation maintenance

Integration
and test
Development

Design

Requirements
analysis
Planning

System
Concept
Development

Initiation

Business Case • Functional Spec System Requirements Spec

• Business
Requirements
Doc
 Requirements Analysis in the SDLC

The Requirements Analysis process consists of two parts:

1. Requirements Gathering & Elicitation [UNIT 3]:

• Definition of the system in terms understood by the
customer (“Problem Description/Definition”)

2. Requirements Analysis & Documentation [UNIT 4]:

• Technical specification of the system in terms
understood by the developer (“Problem Specification”)
 What is a requirement?

“A requirement is a usable representation of a need.

Requirements focus on understanding what kind of value could

be delivered if a requirement is fulfilled.

The nature of the representation may be a document (or set of

documents) but can vary widely depending on the
circumstances.”

BABOK® Guide v3. A Guide to the Business Analysis Body of Knowledge (2015).
International Institute of Business Analysis (IIBA).
 Source of Requirements
Initial requirements come Advanced requirements
from the customer/user come from the analysts, after
(stakeholders), via: studying:

• Documents, such as • Scope and price

RFI/RFP • Feasibility (technological,
• Meetings, reports, etc. organisational, etc.)
• Policy documents • Prototypes
• Interviews • Standards & procedures
• Workshops • Documents, interviews,
• ‘Casual’ communication workshops

Final requirements are stabilized in an iterative process.

http://www.technion.ac.il/~erant
 Strategic
decisions

Tactical management &

decisions

Operational management & decisions

https://digitalmarketing.temple.edu/agervasio/2017/07/18/requirements-gathering-types-and-methods/
 Requirements Classification Schema
Business Stakeholder / User System/ Solution Transition
Requirements Requirements Requirements requirements
• high-level • often referred to as • are what the • describe the
requirements that user needs or user developers use to capabilities that the
describe why the requirements, build the system. solution must have
organisation is • describe what users • written for developers • describe the
undertaking the do with the system, • these are the conditions the
project. such as the activities traditional “shall” solution must meet to
• state some of the that users must be statements that facilitate transition
benefits that the able to perform. describe what the from current state to
organisation or its • written for the system “shall do.” future state.
customers expect to customer – often in • system requirements • of a temporary nature
receive from natural language are classified as either • address topics such as
undertaking the • generally documented data conversion,
✓functional
project. using narrative text, training, business
✓non-functional
• may be documented use cases, scenarios continuity, etc.
requirements.
in several ways such or user stories
as a project charter,
business case, or in a
project vision and
scope statement.

9
 Scenarios
• “A narrative description of what people do and experience as
they try to make use of computer systems and applications”
[M. Carrol, Scenario-based Design, Wiley, 1995]

• A concrete, focused, informal description of a single feature of

the system used by a single actor.
• Scenarios can have many different uses during the software
lifecycle

Requirements Elicitation • As-is scenario, visionary scenario

Client Acceptance Test • Evaluation scenario

System Deployment • Training scenario

 Types of Scenarios
Visionary Evaluation Training
As-is scenario
scenario scenario scenario
• Used in • Used to describe • User tasks • Step by step
describing a a future system. against which instructions that
current Usually used in the system is to guide a novice
situation. greenfield be evaluated. user through a
Usually used in engineering and • Example: Four system
re-engineering reengineering users (two • Example: How
projects. The projects. novice, two to play
user describes • Can often not be experts) play in TicTacToe
the system. done by the a TicTacToe
user or
developer alone
• Example:
Description of
an interactive
internet-based
TicTacToe game
tournament.
 States that the organisation might be in
Greenfield Interface
Re-engineering
Engineering Engineering
• Development starts • Re-design and/or re- • Provide the services
from scratch, no implementation of of an existing
prior system exists, an existing system system in a new
the requirements using newer environment
are extracted from technology • Triggered by
the end users and • Triggered by technology enabler
the client technology enabler or new market
• Triggered by user needs
needs • Example: access of
information to
brokers via web
services
 How to find Scenarios

• Don’t expect the client to be verbal if the system does not

exist (greenfield engineering)
• Don’t wait for information even if the system exists
• Engage in a dialectic approach (evolutionary, incremental
engineering)
– You help the client to formulate the requirements
– The client helps you to understand the requirements
– The requirements evolve while the scenarios are being
developed
– [Agile Programming: they continue to evolve while
prototyping]
 Heuristics for finding Scenarios
• Ask yourself or the client the following questions:
– What are the primary tasks that the system needs to perform?
– What data will the actor create, store, change, remove or add
in the system?
– What external changes does the system need to know about?
– What changes or events will the actor of the system need to
be informed about?
• However, don’t rely on questionnaires alone.
• Insist on task observation if the system already exists (interface
engineering or reengineering)
– Ask to speak to the end user, not just to the software
contractor
– Expect resistance and try to overcome it (change
Management)
 Requirements Classification Schema
Business Stakeholder / User System/ Solution Transition
Requirements Requirements Requirements requirements
• high-level • often referred to as • are what the • describe the
requirements that user needs or user developers use to capabilities that the
describe why the requirements, build the system. solution must have
organisation is • describe what users • written for developers • describe the
undertaking the do with the system, • these are the conditions the
project. such as the activities traditional “shall” solution must meet to
• state some of the that users must be statements that facilitate transition
benefits that the able to perform. describe what the from current state to
organisation or its • written for the system “shall do.” future state.
customers expect to customer – often in • system requirements • of a temporary nature
receive from natural language are classified as either • address topics such as
undertaking the • generally documented data conversion,
✓functional
project. using narrative text, training, business
✓non-functional
• may be documented use cases, scenarios continuity, etc.
requirements.
in several ways such or user stories
as a project charter,
business case, or in a
project vision and
scope statement.

15
 Solution/System Requirements
Functional requirements
• Describe the interactions between the system and its environment
independent from the implementation
• E.g. “Users shall be able to log in using log in screen.”
• Basically, functional requirements describe the behaviour, features,
functioning, and usage of a product/system/software from the perspective
of the product and its user.
• Functional requirements are also called "functional specifications”.

Non-functional requirements
• Aspects not directly related to functional behaviour.
• E.g. “User credentials shall be checked within 0,1 seconds”
• Non-functional requirements are not non-functional at all. Rather, they
describe various quality factors, or attributes, which affect the
functionality's effectiveness. They do not exist in the abstract but only with
respect to relevant functionality. They are often called "ilities," because
many end in "ility," such as, usability, reliability, and maintainability.
 Solution Requirements (cont)
Functional requirements
• An example of a functional requirement would be that a
system must send an email whenever a certain condition is met
(e.g. an order is placed, a customer signs up, etc).

Non-functional requirements
• A related non-functional requirement for the system may be
that emails should be sent with a latency of no greater than 12
hours from such an activity.

The functional requirement is describing the behaviour of the

system as it relates to the system's functionality.
The non-functional requirement elaborates a performance
characteristic of the system.
 Non-functional requirements (1)
• Availability: A system’s availability, or “uptime,” is the amount
of time that it is operational and available for use.
• Efficiency: Specifies how well the software utilizes scarce
resources: CPU cycles, disk space, memory, bandwidth, etc.
• Flexibility: If the organization intends to increase or extend
the functionality of the software after it is deployed, that
should be planned from the beginning; it influences choices
made during the design, development, testing, and
deployment of the system.
• Integrity: Integrity requirements define the security attributes
of the system, restricting access to features or data to certain
users and protecting the privacy of data entered into the
software.
 Non-functional requirements (2)
• Performance: The performance constraints specify the timing of
the software. Certain functions are more time-sensitive than
others; the non-functional requirements should identify those
software functions that have constraints on their performance.
• Reliability: specifies the capability of the software to maintain
its performance over time. Unreliable software fails frequently,
and certain tasks are more sensitive to failure (for example,
because they cannot be restarted, or because they must be run
at a certain time).
• Reusability: Many systems are developed with the ability to
leverage common components across multiple products.
Reusability indicates the extent to which software components
should be designed in such a way that they can be used in
applications other than the ones for which they were initially
developed.
 Non-functional requirements (3)

• Robustness: A robust system is able to handle error

conditions gracefully, without failure. This includes a tolerance
of invalid data, software defects, and unexpected operating
conditions.
• Scalability: Software that is scalable has the ability to handle a
wide variety of system configuration sizes. The non-functional
requirements should specify the ways in which the system
may be expected to scale up (by increasing hardware capacity,
adding machines, etc.).
• Usability: Ease-of-use requirements address the factors that
constitute the capacity of the software to be understood,
learned, and used by its intended users.
 Other non-functional requirement areas

Accessibility Privacy
Capacity, current and Portability
forecast Quality
Compliance Resilience
Documentation Response time
Disaster recovery Security
Effectiveness Stability
Extensibility Supportability
Fault tolerance Testability
Interoperability
Maintainability
 Think – pair – share class discussion
What are functional and non-functional
requirements for a milk carton?

FUNCTIONAL EXAMPLES
• “The packaging should be able to contain fluid
without leaking”
NON-FUNCTIONAL EXAMPLES
• “The corrugated fiber board container is printed and
used as the outer package” (design) OR
• “The packaging should be 100% recyclable”
(compliability) OR
• “Production cost of one package should be no more
than 50cents”
 Think – pair – share class discussion
What are functional requirements for Netflix?
FUNCTIONAL EXAMPLES
• Streaming
• Users should be able to open any video instantly, by hovering over the thumbnail
and pushing the play button.
• When the user hovers over a thumbnail, the trailer of that video should
automatically play in the panel, displaying the title, preview, summary, episodes,
year for the video
• Watch history
• The platform regularly updates the suggestions list by using data analytics.
• The contents of the main page depends on users’ search history, preferences, and
watch history.
 Think – pair – share class discussion
What are non-functional requirements for Netflix?
NON-FUNCTIONAL EXAMPLES
• Usability
• The interface should be adapted to desktop and mobile devices.
• The main page should display items that are in being watched (in progress).
• Security
• Personal data should be stored securely.
• A username and password is required to access the platform.
• Reliability
• The system should be available 24/7 for 365 days of the year.
• Performance
• The response rate should be less than 5 seconds
Examples of good functional requirements

✓ 1. Document requirements, not physical solutions!

✓ 2. Document one requirement at a time!
✓ 3. Map each requirement to the objective(s) and/or
principle(s) it contributes to delivering.
✓ 4. Make each requirement as complete and accurate as it
needs to be to answer the question “what does the solution
need to change in order to deliver the requirements?”.
✓ 5. If there is a known, verified constraint that materially
affects a requirement, then state it.
Examples of poor functional requirements

X 1. Be able to use diary functionality

X 2. Be able to flag premium customers
X 3. Be able to track and report on sales
X 4. Increase accuracy of sales information
X 5. Allow authorised users of team-leader and above to cancel
sales orders
X 6. Prompt the owner of the sales order to notify the customer
of cancelled sales orders.
 Functional vs Non-functional

Table from: https://theappsolutions.com/blog/development/functional-vs-non-functional-requirements/

 Verifiable Requirements
Non-verifiable Verifiable
• The system shall work • The output shall in all cases
satisfactorily be produced within 30
• The interface shall be user- seconds of the corresponding
friendly input event.
• The system shall respond in • It shall be produced within
real time 10 seconds for at least 80%
of input events.
• Professional train drivers will
reach level 1 of proficiency
(defined in requirements) in
two days of training.
Functional Requirement Prioritisation

the project objectives cannot be met

M ust have:
without this requirement

O
the project objectives can be met without
S hould have: this requirement but not as well as with it

C ould have: this requirement only maps to one or

more principles

O
this requirement does not map to any
W ish list: project objectives or principles.
Example: Functional Requirements (1)
Example: Functional Requirements (2)
 Example: Non-Functional Requirements
“Spectators must be able to watch a match without prior
registration and without prior knowledge of the match.”
➢Usability Requirement
“The system must support 10 parallel tournaments”
➢Performance Requirement
“The operator must be able to add new games without
modifications to the existing system.”
➢Supportability Requirement
 Checklist for good requirements
 Correctness:
• Does the requirements represent the client’s viewpoint?
 Completeness:
• Are all possible scenarios, in which the system can be
used, described?
 Consistency:
• Are there any requirements that contradict each other?
 Clarity:
• Can requirements only be interpreted in one way?
 Realism:
• Can the requirements be implemented & delivered?
 Traceability:
• Can each system behavior be traced to a set of functional
requirements?
 Remember

Functional requirement describes what the

solution/product does

Non-functional requirement describes how the

solution/product works

Design is also concerned with HOW the solution works

but involves more of aesthetics that bring value to the
function.

Requirements are focused on the need; designs are

focused on the solution.
 Think – pair – share class discussion

What are 5 functional requirements for a

website?

What are 5 non-functional requirements for

website?
 Requirements vs. Design

BABOK® Guide v3. A Guide to the Business Analysis Body of Knowledge (2015).
International Institute of Business Analysis (IIBA).
Requirements & Design cycle

BABOK® Guide v3. A Guide to the Business Analysis Body of Knowledge (2015).
International Institute of Business Analysis (IIBA).
 Performing requirements gathering

• Understand the problem or problems that the eventual

software system should solve
• Prompt relevant questions about the problem & system
• Provide basis for answering questions about specific
properties of the problem & system
• Decide what the system should do
• Decide what the system should not do
• Ascertain that the system will satisfy the needs of its
stakeholders
• Provide basis for development of the system

Source OOSC (Bertrand Meyer)

Elicitation & Collaboration Knowledge area

Prepare for
elicitation

Conduct elicitation

Confirm elicitation
results

Communicate
Business Analysis
information

Manage
stakeholder
collaboration
 Techniques for requirements gathering
Requirements are best determined by business analysts and
businesspeople/stakeholders together

Methods for Requirements Elicitation:

1. Interviews (one-on-one/group)
2. Questionnaires
3. Observation (Following people around)
4. Document analysis (Request for Proposals)
5. Join Application Development (JAD)
6. Prototyping
7. Brainstorming
8. User stories
9. Use Cases [UNIT 4]

There are more techniques listed in Chapter 4 (page 53) of the BABOK
 1. Steps to conduct interviews
 Selecting interviewees
▪ Different perspectives:
managers, users
 Designing interview questions
▪ unstructured (broad),
structured (narrow)
 Preparing for the interview
▪ List questions, set priorities,
schedule interview
 Conducting the interview
▪ Be professional, record info,
give interviewee time to ask
questions
 Post-interview follow-up
▪ Review notes, look for gaps
 2. Steps to administer questionnaires

Select participants
HALO EFFECT =
▪ Using samples of the population Question from
Design questionnaire previous question
▪ Careful question selection carry on to next
Administer questionnaire question
▪ Working to get good response rate
Questionnaire follow-up
▪ Send results to participants
CENTRAL TENDENCY =
Tendency to rate every
question as average
 Good Questionnaire Design
• Begin with non-threatening
and interesting questions
• Group items into logically
coherent sections
• Do not put important items at
the very end of the
questionnaire
• Do not crowd a page with too
many items
• Avoid abbreviations
• Avoid biased or suggestive
items or terms
• Number questions to avoid
confusion
• Pretest the questionnaire to
identify confusing questions
• Provide anonymity to
respondents
Types of questions
 3. Observation

Observation helps check validity of Behaviours

information gathered in other ways change when
▪ Users/managers, when asked, people are
often don’t remember watched
everything they do

Be careful not to ignore

BUT REMEMBER THAT periodic activities:
Weekly … Monthly …
Annual
 4. Document Analysis
Review existing reports, forms, and procedure
descriptions
Provides clues about existing “as-is” current system
Typical documents
▪ Forms
▪ Reports
▪ Policy manuals
Look for user additions to forms
Look for unused form elements
 5. Joint Application Design (JAD)
• Allows project managers, users & developers to work together
• May reduce scope creep by 50%
• Avoids requirements being too specific or too vague
• Often most useful method for collecting information from users

JAD Participants
• Session leader trained in group dynamics and JAD group
facilitation
• Knowledgeable business and system users and policy makers
• Technical staff representatives to handle
• Computer and network configurations
• Operating environments
• Security issues
• Project team members
 JAD Facilities JAD Session
• Conducted in special room • May involve several days
• Limit interruptions over a period of a few
• May be off-site weeks
• Resources • Prepare questions as with
interviews
• Overhead projector,
white board, flip charts, • Formal agenda and ground
work material rules
• Electronic support • Facilitator activities
(laptops) • Keep session on track
• CASE tools • Help with technical terms
• Group support systems and jargon
(GSS) • Record group input
• Help resolve issues
• Post-session follow-up
JAD Meeting room
 Managing problems in JAD sessions
• Reducing domination
• Encouraging non-contributors
• Avoid side discussions
• Agenda merry-go-round
– the same issue raised
continually
• Violent agreement
– Inconsistent terminology
masks potential agreement
• Unresolved conflict
– Help group select a better
alternative
• True conflict
– Document as an open issue
• Use humor
 6. Prototyping in the Requirements phase
• Prototyping is used to elicit and
validate stakeholder needs, by
creating a model or design of
requirements.
• Elicit requirements through an
iterative process.
• Also used to optimise user
experience, evaluate design
options, and as a basis to develop
the final solution.
• Used to identify missing or poorly
specified requirements.
BABOK® Guide v3. A Guide to the Business Analysis Body of Knowledge
(2015). International Institute of Business Analysis (IIBA).
 6. Prototyping approach (2)

Throw-away:
• Prototypes are generated with simple tools (such as paper and pencil, a whiteboard, or
software)
• Used with the aim of uncovering and clarifying requirements.
• A prototype may be updated or evolve during the course of discussion and development
but does not become workable code or get maintained as a deliverable once the final
system or process is implemented.
• This method is helpful for identifying functionality or processes that are not easily elicited
by other techniques, have conflicting points of view, or are difficult to understand. These
prototypes can be an inexpensive tool to uncover or confirm requirements that go beyond
an interface including requirements related to processes, data, and business rules.

Evolutionary or Functional:
• prototypes are created to extend initial requirements into a functioning solution as
requirements are further defined through stakeholder use. This approach produces a
working solution and usually requires a specialized prototyping tool or language.
• These prototypes may be used in the final solution. If specialized software is used, business
processes, rules, and data can be simulated to evaluate the impact of changes and validate
desired outcomes.

Section 10.36 – BABOK – Pg: 324

 6. Prototyping approach (3)

Methods Examples

• Storyboarding • Proof of Concept or

• Paper prototyping Principle
• Workflow modelling • Form study
• Simulation prototype
• Usability prototype
• Visual prototype
• Functional prototype

Section 10.36 – BABOK – Pg: 323

 7. Brainstorming (1)
• Brainstorming is an excellent way to foster creative thinking
about a problem.
• The aim of brainstorming is to produce numerous, diverse,
new ideas and to derive themes for further analysis.
• It helps answer specific questions such as (but not limited to):
❑ What options are available to resolve the issue at hand?
❑ What factors are constraining the group from moving ahead with an
approach or option?
❑ What could be causing a delay in activity 'A’?
❑ What can the group do to solve problem 'B'?

BABOK® Guide v3. A Guide to the Business Analysis Body of Knowledge (2015).
International Institute of Business Analysis (IIBA).
 7. Brainstorming (2)

BABOK® Guide v3. A Guide to the Business Analysis Body of Knowledge (2015). International
Institute of Business Analysis (IIBA).
 7. Brainstorming (3)

Strengths Limitations

• Ability to elicit many ideas • Participation is dependent

in a short time period. on individual creativity and
• Non-judgmental willingness to participate.
environment enables • Organisational and
creative thinking. interpersonal politics may
• Can be useful during a limit overall participation.
workshop to reduce tension • Group participants must
between participants. agree to avoid debating the
ideas raised during
brainstorming.

BABOK® Guide v3. A Guide to the Business Analysis Body of Knowledge (2015). International Institute
of Business Analysis (IIBA).
 8. User stories (usage narratives)

• A user story is a narrative told from user's perspective,

describing his/her usage of the system.
• It helps us to define the value a user gains from the
system.
• It helps us manage requirements in an Agile
environment
• They are high-level requirement artefacts that emulate
conversations with stakeholders.

65
 8. User stories (usage narratives)

As a ______________________(role)
WHO ,

I want to ______________________(action),
WHAT
so that_______________________(benefit).
WHY

“As a Customer, I want to select a car from the carousel

so that I can complete the order. ”
"As a Student, I want to purchase a parking pass so
that I can drive to school"
 8. User stories (usage narratives)

"User stories are part of an agile approach that helps shift the
focus from writing about requirements to talking about them. All
agile user stories include a written sentence or two and, more
importantly, a series of conversations about the desired
functionality" - Mike Cohn, a main contributor to the invention of Scrum
software development methodology
• A user story is defined incrementally, in three stages:
– The brief description of the need (CARD)
– The conversations that happen during backlog grooming
and iteration planning to solidify the details
(CONVERSATION)
– The tests that confirm the story's satisfactory completion
(CONFIRMATION)
https://www.visual-paradigm.com/guide/agile-software-development/what-is-user-story/
 8. User stories- INVEST mnemonic
Independent • Stories should be as independent as possible.

• A story is not a contract. A story IS an invitation to a

Negotiable conversation. The story captures the essence of what is
desired.

Valuable • If a story does not have discernible value it should not

be done.

Estimable • A story has to be able to be estimated or sized so it can

be properly prioritized.

• Two week iterations which allow for user stories to

Small average 3-4 days of work – TOTAL! The smaller the user
story, the higher the accuracy of the estimate!

Testable • Every story needs to be testable in order to be “done.”

https://www.agileaces.net/write-good-requirements-user-stories-scrum/
 Think – pair – share class exercise
WRITE THIS SCENARIO IN USER STORY FORMAT
• Bill is a marine biologist who wants to see an article
about fish.
• He selects "Article or journal" from the menu.
• He chooses the topic "fish" from the subsequent list
shown.
• The system returns articles to Bill about his chosen topic.
• The annotated list designates the physical location of
articles.
• Bill clicks articles of interest to him.
• Abstracts of each flagged article are displayed.
• Bill makes a final selection of articles based on abstracts.
• The abstracts are printed, and Bill retrieves them from
the printer. 69
 Selecting Appropriate Techniques
Interview JAD Questionnaires Document Observation
Analysis
Type of As-is, As-is, As-is, improves As-is As-is
information improves, improves,
to-be to-be
Depth of info High High Medium Low Low
Breadth of info Low Medium High High Low
Info integration Low High Low Low Low
User Medium High Low Low Low
involvement
Cost Medium Low- Low Low Low-
medium medium
 Requirements Life Cycle Management
Trace analyzes and maintains the relationships between requirements,
designs, solution components, and other work products for
requirements impact analysis, coverage, and allocation.

Maintain
ensures that requirements and designs are accurate and current
requirements throughout the life cycle and facilitates reuse where appropriate.

Prioritize assesses the value, urgency, and risks associated with particular
requirements and designs to ensure that analysis and/or delivery
requirements work is done on the most important ones at any given time.
Assess evaluates new and changing stakeholder requirements to
requirements determine if they need to be acted on within the scope of a
changes change.

Approve
works with stakeholders involved in the governance process to
requirements reach approval and agreement on requirements and designs.
 Summary

• This unit examined the main topics about Requirements Analysis,

from the perspective of Business Analysis.
• The unit:
– explained why requirements are important in business analysis,
– explained the classification of requirements,
– differentiated between the types of system/solution
requirements,
– differentiated between requirements and design, and
– introduced eight examples of techniques that can be used to
elicit and gather requirements.
• The unit also examined the Requirements Life Cycle Management
knowledge area