Requirements

Engineering
REQUIREMENTS INCEPTION
PROF. ALAA EL-HALEES
Outline
 Definition
 Business Needs
Stakeholder Analysis
Product Vision
 Product Roadmap
Product Scope

2
 Definition
 In general, most software projects begin
when there is a problem to be solved, or
an opportunity identified.
 At inception, the problem scope and its
nature is defined. 
 Requirement engineering is concerned with
developing and managing effective solutions
to problems.
 Definition
 Inception is the first phase of the
requirements analysis process.
 This phase gives an outline of how to get
started on a project.
 In the inception phase, all the basic questions
are asked on how to go about a task or the
steps required to accomplish a task.
 Definition
 The purpose of the inception phase is NOT
to define all the requirements.
 The inception phase should be relatively
short for most projects, such as one or a few
weeks long.
 Definition
 Requirements Inception should contain at
least:
Business Needs
Stakeholders Analysis
Product Vision
Product Roadmap
Product Scope
Outline
 Definition
 Business Needs
Stakeholder Analysis
Product Vision
 Product Roadmap
Product Scope

7
Business Need
Business needs are gaps between the current state
of the company and its goals.
Needs are the basic factors of changes in
the organization , which are defined as requirements.
Business Need
 Business needs is a high-level representation of
the requirement needed. The need is the end result
or purpose. It is the "why we are doing this".
 Business Need

 To have a requirement , we need to have an

objective, so we can say that need is an objective
or business case that generates requirements.

 When we have need or objective clear, it helps

to find out possible and effective solutions.

 It also helps in another way to find out why we

created a particular requirement.
Business Need
Therefore, Business need is to start with a “Parent”
requirement.
The easiest way to think of this is to ask yourself,
“What is the objective of this project?”
Business Need
For example
The business needs is:
To build my website
The requirements are:
•The website shall allow clients to contact me
•The website shall have a blog
•The website shall present my projects
Business Need
If we are building a system for the call center department
that allows us to capture customers' information. 
The need is to help the marketing team reach out to non-
paying customers and offer new products to convert them to
paying customers
.
Now that we understand why we are building this system,
let's take a look at the following requirements and identify
what is necessary and what does not satisfy the need:
Business Need
•The system shall save users' name, email and phone
number ✔
•The system shall allow customers to post their
photos ✖
•The system shall allow call center staff to send
follow-up emails ✔
•The system shall require customers' emails in order
to contact the support team ✔
Business Need
Note that the above example seeks to illustrate the
importance of understanding business needs. While
there may be benefits to including an function to
allow customers to post their photos, this kind of
feature does not obviously satisfy the need.
Business Need vs.
Requirements
Business needs are goals and objectives a
business must achieve

Requirements are the things we need to do in

order to achieve a need

Let’s take a look at these examples:

Business Need vs. Requirements
Requirements Needs (I need to...)
- The house shall have 3 - build a big house for my
bedrooms large family
- 2 small bedrooms
- 1 master bedroom
- The house shall have a backyard
- The house shall be 3 levels
-The floors shall be wood
The wood color shall be dark
brown
 Business Need
Requirements Needs (I need to...)
 I should take a BA course  get a BA job
 I should create a resume
 I should practice mockup interviews

 My blog shall have a subscription  I need to be able to communicate

option for readers to enter their with people visiting my blog.
emails
- My blog shall have a contact me
section
- My blog shall collect all emails and
integrate with mailchimp to send
newsletters
Outline
 Definition
 Business Needs
Stakeholder Analysis
Product Vision
 Product Roadmap
Product Scope

19
 Stakeholder Analysis
A stakeholder of a system is a person or an
organization that has an (direct or indirect)
influence on the requirements of the system.

 Stakeholders are a vital part of any software

project, which makes Stakeholder Analysis a critical
part of the system Inception phase.
 Stakeholder Analysis
 The only way to make sure that we are building a
product that is relevant and valuable is to engage people
and understand why they may be interested in the product
and bring them into the process.
 If we don't involve stakeholders from the very
beginning, we can easily build an excellent product with
great features, but it's possible that no one will want or
need to use it.
Stakeholder Analysis
Stakeholder cooperation is essential for
building a shared understanding of the
problems to be addressed by the system-to-
be.
Such cooperative learning is a critical path to
obtaining complete, adequate and realistic
requirements. We should therefore select
the right sample of stakeholders.
 Stakeholder Analysis
The following criteria may be used for Identifying
the relevant stakeholders :
• Relevant position in the organization.
• Effective role in making decisions about the
system-to-be.
• Level of domain expertise.
• Experience to apparent problems.
• Influence in system acceptance.
 Stakeholder Analysis:
Company Stakeholders

https://www.youtube.com/watch?v=2_u7Nv7Wh-M&t=72s
Stakeholders
Not all stakeholders are equal.
Some stakeholders are less important to
a business than others.
The business would class them as either;
1) Primary stakeholders
2) Secondary stakeholders
Stakeholders
A) Primary Stakeholders:
Primary Stakeholders are People or
groups seen by the business to be vital
to the organization's success or failure.
Examples of Primary Stakeholders are:
 Stakeholders
1) Customer/Client
A customer is the one who buys goods and services from
the businesses or stores.
A client is the one who looks for professional services.
For an internal product, the client is probably a
product manager.
For the consumer market, the customer may be the
marketing department.

27
Stakeholders
2) Decision-makers:
Within the development organization and the user
organization, there will be decision-making
structures that relate to the system under
development.
The kinds of stakeholder here would include
managers of the development team, user
managers and financial controllers in both the
developer and the user organization.
28
 Stakeholders
3) User
 User of the current system or future system
 Experts of the current system: indicate which
functions to maintain or improve
Do not neglect interest groups
 Expert users, or with disabilities or handicaps
 Select users with care
 Different seniority
 Must speak with authority and be responsible and
motivated
29
Stakeholders
4) Domain Expert

A domain is the targeted subject area of a software

system.
For example, a particular software system might
have had as a goal, the creation of a program for a
particular hospital, and that hospital would be the
domain.


30
Stakeholders
4) Domain Expert
Domain Expert is the expert who knows the work involved
 Familiar with the problem that the software must solve.
For example:
 Financial expert for finance management software
 Meteorologist for weather forecasting system, etc…
 Librarian for library System.


31
Stakeholders
5) Software Engineer
 Expert who knows the technology and process
 Determines if the project is technically and
economically feasible
 Specifically estimates the cost and time of product
development
 Educates the buyer/client on the latest and innovative
hardware or software, and recommends new features
that will benefit from these technologies

32
Stakeholders
b) Secondary Stakeholders:
Secondary stakeholders People or group who may
involved in the organization's success or failure.

Examples of Secondary stakeholders People are:

Stakeholders
1) Inspector
◦ An expert in governmental rules and safety relevant to the
project
◦ Examples: safety inspectors, auditors, technical inspectors,
government inspectors.

2) Market research specialist

◦ Can play the role of the customer if the software is developed
for the general public
◦ Expert who has studied the market to determine trends and
needs of potential customers
34
Stakeholders
3) Lawyer
◦ Familiar with laws and legal aspects
◦ Standards relevant to the project

4) Expert of systems that interact with the system to be

built
◦ Knows the interfaces of the interacting systems
◦ May be interested in product features (if the product can help
the interacting system to perform its tasks)

35
Outline
 Definition
 Business Needs
Stakeholder Analysis
Product Vision
 Product Roadmap
Product Scope

36
Product Vision
Every product or system we are going to
develop needs a vision.
A product vision is a description of what
you hope to achieve with your product.
A Product vision gives your team a bigger
picture of what they are working on and
why.
Product Vision
This vision will most likely be long term
spanning an entire year or many years. The
product vision helps stakeholders pass the
elevator pitch - the ability to explain the
project to someone within two minutes.
Product Vision
Without this high level, there's a really
good chance that your good work won't
amount to business advantage. Vision is
a starting point.
It needs to adjust to what you learn by
interacting with the market.
Product Vision
The elevator pitch is a way to clear the vision
so that it can handle the classic elevator test.
In this vision the product owner explains
Who’s the target customer? What problem
are you solving? Who is the competition?
What are your strengths/weaknesses?
Example
For dentists and their assistants
who need to efficiently schedule appointments
Dental Clinic 2.0 is desktop and web-based
appointment scheduling software
that supports office and remote access.
Unlike competitive products,
Dental Clinic 2.0 is easy to use and aggressively
priced.
Product Vision
The previous example follows the form (which is called
“elevator pitch”:
- For (target customer)
- Who (statement of the need or opportunity)
- The (product name) is a (product category)
- That (key benefit, compelling reason to buy)
- Unlike (primary competitive alternative)
- Our product (statement of primary differentiation)
Product Vision: Example
an example of a product vision statement for
Microsoft Surface:
Product Vision: Example
For the business user who needs to be
productive in the office and on the go, the
Surface is a convertible tablet that is easy
to carry and gives you full computing
productivity no matter where you are.
Unlike laptops, Surface serves your on-the-
go needs without having to carry an extra
device.
Product Vision- Example
For purchasers and suppliers in medium-sized
companies who need demands set and test the
IT systems that they build themselves. The
ReQtest, is a cloud service That Leads To
structured requirements and tests. Unlike
other software, Our Product Offers many user-
friendly features at a low cost.
Outline
 Definition
 Business Needs
Stakeholder Analysis
Product Vision
 Product Roadmap
Product Scope

46
 Product Roadmap
Once you define the Software vision,
it can provide input to the product
roadmap.
A product roadmap is a high-level
visual summary that maps out the
vision and direction of your product
offering over time.
Product Roadmap
 The product roadmap should be
updated at least every 6 months by
management.
Product Roadmap
A roadmap is a planned future, laid out in
broad hits — i.e. planned or proposed
product releases, listing high level
functionality or release themes, for a period
usually extending for 2 or 3 significant
feature releases into the future.
It gives your customers a feel for what you're
about and where you're going.
GO product roadmap
Goal Oriented Product Roadmap:
In this kind of Roadmap, the major focus is on
goals.
 It focus on goals enables steering on outcome
rather than steering on output.
The value and feature based approach enable the
product owner to plan on the most important
features.
 GO product roadmap
The Go (Goal Oriented) product roadmap consist of the following:

https://www.youtube.com/watch?v=NBNsnKPbah0
 GO product roadmap
The following is an example of email system GO statement:
Q3 Q2 Q1 Date
Release 3 Release 2 Release 1 Name

Revenue Retention of users Acquiring new users Goal

- Search Attachment - Advanced Search - Basic Email (create, send Features
- Get Address from - Create and open open, delete)
Contact HTML email - Basic email Search
- Import and Export - Manage Contacts - Manage Attachment
Contacts - Manage Calendar

5% of users purchase Engagement increase 1000 new Users Matrices

by 10%
GO Product Roadmap
Date or timeframe for the upcoming releases. You
can work with a specific date such as  1st of March,
or a period such as the first or second quarter.

 Name or version of the releases, for instance, iOS

14 or Windows 11.
GO Product Roadmap
Goal of each release, the reason why it is
worthwhile to develop and launch it.
Sample goals are to obtain or to activate users, to
retain users by enhancing the user experience, or
to go from free to paid software.
Working with goals shifts the conversation from
debating individual features to agreeing on desired
benefits making strategic product decisions.
GO Product Roadmap
Features necessary to reach the goal
They serve to create value and to reach the goal.
Try to limit the number of features for each release
to three, but do not state more than five.
Avoid detailing the features, and focus on the
product capabilities that are necessary to meet the
goal.
GO Product Roadmap
Metrics, the measurements that help
determine if the goal has been met, and if
the release was successful.
Make sure that the metrics you select allow
you to measure if and to which extent you
have met the goal.
GO product roadmap
Outline
 Definition
 Business Needs
Stakeholder Analysis
Product Vision
 Product Roadmap
Product Scope

58
Project Scope
Project Scope: identifies what portion of the
ultimate long-term product vision the
current project will address.
The project scope outlines the boundaries of
the project such as what is and is not to be
included or expected.
Project Scope
 Understanding the scope of a project is
critical to establishing requirements for it.
 In some cases, it may be simple and
clearly defined.
 However, in other cases, a project’s
boundaries can be vague or poorly
defined, and this is one of the biggest
sources of problems for writing effective
requirements.
System Context
The system context is the part of the system
environment that is relevant for the
definition as well as the understanding of the
requirements of a system to be developed.
Project Scope
The system context defines the boundaries of the
system under development to distinguish it from
neighboring systems.
The system context depicts the project scope at a high
level of abstraction.
The system context diagram deliberately reveals nothing
about the system internals: no information about
functionality, architecture, or look-and-feel. Nor does it
explicitly identify which features or functionality are in
scope and which are not.
System Context
System Context
The following possible aspects of reality influence the
context of a system:
1) People (stakeholders or groups of stakeholders)
2) Systems in operation (other technical systems or
hardware)
3) Processes ( e.g. accounting, recruitment, call
center, technical support….)
4) Events (e.g. fiscal year, semester)
4) Documents (e.g., laws, standards, system documentation)
System Context Example
Context Diagram
The Context Diagram shows the system under
consideration as a single high-level process and
then shows the relationship that the system has
with other external entities (systems, organizational
groups, external data stores, etc (
Context Diagram
The following is included in context diagram:
1) Indicate the people, organizations and systems
which communicate with our system.
2) Show the data which our system receives from the
outside world.
3) Show the data produced by the system and sent to
the outside world.
4) Show the data which is shared by the system with
the outside world.
5) Show the boundary between the system and the rest of the world.
 Context Diagram
Example Order
System New customer

Order Picking Slip

Order
Customer Invoice
System
Order Warehouse

Ship
Statement
Context Diagram
Context diagrams can be developed with the use of following types of
building blocks:
 Context Diagram
An external entity (terminator or source) is something
outside the system. It is shown as a square and is
identified by a lower case letter and name.`
Customer Sales Dept Accounts
Package

► Eg. people, departments, organisations that provide information to

the system (source) or receive information from the system (sink).

► If external entities have to be duplicated, an

Customer
angled line is put in the corner of the box (all copies).
Context Diagram : LOGIN (generic)
 Context Diagram
A process is an action on or transformation of
data. It is shown as a circle. In Context diagram it
describes the system.

Credit Split Adjust

Rating Order Stock
System System System
Context Diagram: Hotel
reservation System
 Data Flow
A data flow is shown as a named arrow.
Date
Invoice

► The name of the data flow is the name of the piece of data passing
between the 2 connected symbols.

► The direction of the arrow shows the direction in which the data is
flowing.

► Two way flows of data are best shown by 2 arrows, Stock

Adjustment
but may be shown by one double-headed arrow.
 Context Diagram
The final symbol is the data store, represented by parallel lines,
identified by a number and name. The name is usually in the
plural.
1 Customers Invoices

► The data in a data store is data at rest (persistent data), ie a file or

database.
► If data stores have to be duplicated, a vertical line is added to the left (all
copies).
1 Customers

► When data is written to a data store, the data flow is shown going in.
► When data is read from a data store, the data flow is shown coming out.
► If data is being read and written, a double-headed arrow can be used.
Context Diagram
Context Diagram
How to Construct Context Diagram
◦ A strategy
follows for determining the system’s boundary
and scope:
◦ Step 1: Think of the system as a ‘container’ in order to distinguish
the inside from the outside.
◦ Ignore the inner workings of the container .
◦ Step 2: Ask your end-users what business events or transactions a
system must respond to.
◦ These are the net inputs to the system.
◦ For each net input, determine its source.
◦ Sources will become external agents on the context diagram.
Context Diagram
◦ Step 3: Ask your end-users what responses must be
produced by the system.
◦ These are the net outputs to the system.
◦ For each net output, determine its destination.
◦ Destinations may be external agents.
◦ Step 4: Identify any external data stores.
◦ Many systems require access to the files or databases
of other systems.
◦ Step 5: Draw your context diagram from all of the
preceding information.
Context Diagram
Context Diagram
References
• Requirements Engineering for Software and Systems Ch 2
 An Introduction to Object-Oriented Analysis and Design Ch. 4
 Software Requirements ch.5
 Discovering Requirements Ch. 3 Ch. 4
 Business Requirements vs Functional Requirements? Who
Cares?
https://netmind.net/en/business-vs-functional-requirements-
who-cares/
 Defining Project Scope and Scope Creep
https://www.bmc.com/blogs/project-scope-creep/