REQUIREMENTS ENGINEERING

JIMMA UNIVERSITY
JIMMA INSTITUTE OF TECHNOLOGY
FACULTY OF COMPUTING AND INFORMATICS

CHAPTER TWO

BUSINESS AND REQUIREMENTS PROCESSES

A N D N AT U R E O F R E Q U I R E M E N T S
Topics we will cover
2

Business and Requirement Process

Process Improvements
Basics of Requirements
Functional Requirements
Requirement’s imprecision
Requirements completeness and consistency
 Business and Requirement Process
3

As-Is Process: A detailed view of the To-Be Process: An optimized future

current process state, showing how state of the process, designed to
tasks are done today with all roles, improve efficiency and outcomes. It
activities, and resources. It helps to includes streamlined steps, new roles,
identify inefficiencies, redundancies, and technology to eliminate current
and bottlenecks. pain points and achieve target goals.
Business and Requirement Process
4
 Activity
5

Consider your assignment title and identify the core

processes, subprocesses, and major stakeholders.
• For example, if we consider an HR System, the core
processes can be talent acquisition, onboarding,
performance management, offboarding, etc. As a
subprocess of Talent Acquisition, we can have job posting,
screening, interviewing, offer and agreement. The major
stakeholders include HR personnel and employees.
Business and Requirement Process :Inputs and Outputs

6
 Inputs
7

Existing system information: Information about the functionality of

systems to be replaced or other systems which interact with the system being
specified.
Stakeholder needs: Descriptions of what system stakeholders need from
the system to support their work.

Organizational standards: Standards used in an organization regarding

system development practice, quality management, etc.

Regulations: External regulations such as health and safety regulations

which apply to the system.

Domain information: General information about the application domain

of the system
 Outputs
8

Agreed requirements : A description of the system

requirements which is understandable by stakeholders,
and which has been agreed by them.
System specification: This is a more detailed
specification of the system functionality which may be
produced in some cases.
System models: A set of models such as a data-flow
model. an object model, a process model, etc. which
describes the system from different perspectives.
 Process variability
9

Processes vary from one organization

to another.

Factors contributing to this variability

include:
• Technical maturity.
• Disciplinary involvement.
• Organizational culture. – Application domain.

There is therefore no ‘ideal’ business

and requirements process
 Process Models
10

A process model is a simplified description of a process

presented from a particular perspective.

Types of process model include:

• Coarse-grain activity models

• Role-action models
Coarse-grain Activity Model of RE
11
Role- Action Model
12
 Role Descriptions
13

Domain expert Responsible for providing information about

the application domain and the specific
problem in that domain which is to be solved.

System end-user Responsible for using the system after delivery

Requirements Responsible for eliciting and specifying the
engineer system requirements

Software engineer Responsible for developing the prototype

software system

Project manager Responsible for planning and estimating the

prototyping project
 Process Improvement
14

A systematic approach to enhancing existing processes by identifying

and addressing inefficiencies, redundancies, and bottlenecks.

Improvement objectives:
• Quality
• Efficiency
• Cost

Planning process improvement

• What are the problems with current processes?
• What are the improvement goals?
• How can process improvement be introduced to achieve these goals?
• How should process improvements be controlled and managed?
 Basics of Requirements
15

Discussion

What do you think is the effect of poor requirements in the

software development process?
 Basics of Requirements
16

“The beginning is the most important part of the work”

• Requirements capture what a proposed system should do, and

the constraints they should follow.
• Poor requirements are the source of all evil.
• Poor requirements:
• The Engineering Argument: Engineering is about
developing solutions to problems. A good solution can only be
developed if engineers understand the problem.
• The Economic Argument: Errors cost more to correct the
longer they go undetected.
• The Empirical Argument: Failure to understand and
manage requirements is the biggest single cause of cost and
schedule over-runs
 Basics of Requirements
17

Discussion

Assume that you have been delegated as a requirements engineer to

define and document the requirements for the Jimma University
Examination and Assessment System. What do you think are the
potential requirements for the proposed application?
 Basics of Requirements
18

View Exam Schedule Jimma University

Examination and
Easy to use with no training or user manuals. Assessment App
Should be accessible only through the Jimma
University LAN network
App
Web based, Mobile app(Android, iOS)

Generate Exam Reports

Save Answers Automatically

Secure access through two- authentication

techniques

etc.
 Types of Requirements
19

• User requirements: Statements in natural

language plus diagrams of the services the
system provides and its operational constraints.
Written for customers.
• System requirements: A structured
document setting out detailed descriptions of the
system services. Written as a contract between
Requirements client and contractor.
• Software specification requirements: A
fall into three detailed software description which can serve as
a basis for a design or implementation. Written
categories: for UI/UX designer and developers
 Types of Requirements
20

User, system and

software
specification
requirements can be:

Functional Non-functional
Domain requirements
requirements requirements
 Functional Requirements
21

Functional Requirements: Statements of services the system should provide, how the
system should react to particular inputs and how the system should behave in particular
situations.

Describe functionality or system services.

Example: Some of the functional requirements for the Examination and Assessment App.

The application must send a notification whenever a new schedule is available.

The application must allow users to send feedback about the exam
The application must allow users to share the exam schedule to their friends.
etc.
 Requirement’s Imprecision
22

“A major reason to project failure is the failure to

spend the time at the beginning of the project to
clearly define the product requirements before
beginning product development i.e. gathering
imprecise requirements”
• Requirements imprecision: problems arise when functional
requirements are not precisely stated.
• Ambiguous requirements may be interpreted in different ways by
developers and users.
• User intention Developer interpretation
• Example: Consider the term “search events” requirement in the event
management application.
• User intention: Search for coming events in Jimma University.
• Developer interpretation: Search for events in Jimma University.
 Requirements Completeness and Consistency
23

In principle, requirements should be both

complete and consistent.
• Complete: They should include descriptions of all facilities
required.
• Consistent: There should be no conflicts or contradictions
in the descriptions of the system facilities.

In practice, it is impossible to produce a

complete and consistent requirements
document.
 Non-Functional Requirements
24

Non-functional requirements are the constraints, or the

requirements imposed on the system.

Non-functional requirements deal with issues like scalability,

maintainability, performance, usability, and many more.

Non-functional requirements classified into three major

categories.
• Product requirements: Requirements which specify that the delivered product
must behave in a particular way, e.g. execution speed, reliability etc.
• Organizational requirements: Requirements which are a consequence of
organizational policies and procedures, e.g. process standards used,
implementation requirements etc.
• External requirements: Requirements which arise from factors which are
external to the system and its development process, e.g. interoperability
requirements, legislative requirements etc.
Non-Functional Requirements
25
 Product Requirements
26

Usability: Understand the application/system in context of user, technology, task/activity

and environment.
• User: Setting up user profiles . Who are the users of the application?
• Tasks: Tasks are the activities undertaken to achieve a goal using the application. Descriptions of the activities
and steps involved in performing the task should be related to the goals that are to be achieved.
• Technology: Technology refers to the capabilities and constraints of technology platform needed for running the
application. This factor determines user interface related capabilities and constraints of the hardware and software
platform for the application.
• Environment: Environment refers to the Internet capability and availability needed for running the application.
 Product Requirements
27

Efficiency: Efficiency refers to the capability of the application

to provide appropriate performance, relative to the number of
resources used, under stated conditions.
• Performance requirements: the user should not spend a lot of time in doing
specific task.
• Space requirements: the system should not take a lot of space while doing a
specific task.

Reliability: Reliability refers to error handing of the application

and the extent to which the action history is dependable, trusted
and reach user mind stability.

Portability: Portability is the ease with which a software system

can be transferred from its current hardware or software
environment to another environment.
 Organization Requirements
28

Delivery requirements: Delivery Requirements are the deadlines

given by the customer to the software team for the completion of the
given system.

Implementation requirements: implementation requirements

are the requirements dealing with software installation and software
demonstrations with the actual users of the software.

Standard requirements: Describe the process standards to be

used during software development. For example, the software should
be developed using standards specified by the ISO and IEEE
standards.
 External Requirements
29

Interoperability requirements: Interoperability

requirements define how business processes are to be
shared.

Ethical requirements: Specify the rules and

regulations of the software so that they are acceptable
to users.

Legislative requirements: Ensure that the

software operates within the legal jurisdiction. For
example, pirated software should not be sold.
 Domain Requirements
30

Domain requirements: Requirements which are derived from the

application domain of the system instead of the needs of the users.

Domain requirements are expectations related to a particular type of

software, purpose or industry vertical.

Domain requirements problems:

• Understandability: Requirements are expressed in the language of the application
domain. This is often not understood by software engineers developing the system.
• Implicitness: Domain specialists understand the area so well that they do not think of
making the domain requirements explicit.
 Key Points
31

Business and requirement Process

Process improvement

Basics of Requirements

Functional Requirements

Requirement’s imprecision

Requirements completeness and consistency

Non-functional requirements

Domain requirements
Any Question?

32