Chapter 1

Introduction to Requirement Engineering

By:
Hailemichael Kefie
Software Engineering Dept.
 What are Requirement?
 A requirement is some aspect of a system’s content or
behavior, which is necessary or desired by the customer or
client
 Provides a clear understanding of the problem domain
 Establishes a context of the need/problem

 Requirements define
 What the system must do
 What characteristics the system must have
 What information is involved
 What degree of quality is expected
 What constraints apply to the solution
 Who will use the system
 How the system is to be used
 What are Requirement cont.…?

Well defined requirements are measurable & provide

the basis for defining project success

In simple terms, it's a requested need not yet

implemented.

Requirements should always be statement of what a

system should do rather than a statement of how it
should do it.
 Requirements Engineering

The disciplined application of scientific principles and

techniques for developing, communicating, and managing
requirements.

Requirements engineering(re) provides

 The basic agreement between end-users and developers on what the software
should do.
 It is a clear statement on the scope and boundaries of the system to be analyzed and
studied.

 It gives stakeholders an opportunity to define their requirements understandable to the

development team
 Requirements Engineering

 RE “involves all life-cycle activities(Process)

Identification of user requirements,

Analysis of the requirements to derive additional requirements,
 Documentation of the requirements as a specification, and
 Validation of the documented requirements against user
needs,
 as well as processes that support these activities”
 Stakeholders…

There are three main categories of stakeholders:

 The acquirers of the software product
 The suppliers of the software product and
 Other stakeholders.
 Stakeholders…

The acquirer type stakeholders can be divided into two

major groups.
Customers who request, purchase, and/or pay for the software product in
order to meet their business objectives.
Users, also called end-users, who actually use the product directly or use the
product indirectly by receiving reports, outputs, or other information
generated by the product.
 Stakeholders…
The suppliers of the software product include individuals and
teams that
 Are part of the organization that develops the software product or
 Are part of the organizations that distribute the software product or
 Are involved in other product delivery methods (for example, outsourcing).

 System analysts, designers, developers etc are some

examples among suppliers
 Suppliers who pay for the development of the product are
called client.
 Stakeholders: Example

 Assume WKU has signed an agreement with a software

company called ABC for the automation of the clinic
system which encompasses subsystems like clinical lab
subsystem, patient admission subsystem and the like.
 Stakeholders: Example

Identify all stakeholders for the system mentioned.

WKU, WKU managers, Students, doctors and other health officials, the
company ABC, etc

If the University sells the system to other universities so as to get

reimbursed for what it has spent, who is the client, the customer and
the user?
Client: WKU
Customers: Other Universities
Users: Anyone using the system
 Requirements Engineering…

 By the end of requirements engineering,

All parties concerned should have a clear idea of

exactly what the system will and will not provide.
The Inputs & Outputs of RE …
 Success Attributes that Requirements
Engineering Affect {produce change}
User Involvement

Clear Statement of requirements

Proper Planning

Realistic Expectations

Smaller Project Milestones

Clear Vision and Objectives

Hard Working, Focused Team

Spirit & Staff(Team worlk)

 Chapter 2
Types of Requirements
By:
Hailemichael Kefie
Software Engineering Dept.
 User Requirements

Should describe functional and non-functional requirements so

that they are understandable by system users who don’t have
detailed technical knowledge
 They are called user requirements because they are written
from a user’s perspective

User requirements are defined using statements in natural

language, tables, diagrams.

Written primarily for customers

 User Requirements

User Requirement Readers

 System Requirements
Are expanded versions of the user requirements that are used by

software engineers as the starting point for the system design.

They add detail and explain how the user requirements should be

provided by the system

Capture the vision of the customer, enable defining the scope of the

system, and allow estimating the cost and schedule required to build the

system.

A structured document setting out detailed descriptions of the system’s

functions, services and operational constraints.

 System Requirements
Defines what should be implemented so may be part of a
contract between client and contractor.

May serve as a contract between client and developer.

System requirement readers

 Software Design Specification
Requirements
Implementation oriented abstract description of software design
which may utilize formal (mathematical) notations.

Written for developers.

Software design specification readers

 Types of requirements

Functional requirements
Non functional requirements - Quality Attributes
Domain requirements
 Functional requirements
Describes system services or functions which are expected by the users
of the system.
 How it should react to particular inputs,
 How it should behave in particular situations.

Examples:
 The user shall be able to search either all of the initial set of databases or select a
subset from it.
 The system shall provide appropriate viewers for the user to read documents in the
document store.

Functional requirements describe what the system or software must do

and sometimes called behavioral or operational requirements.
 Non- Functional requirements
Define the overall qualities or attributes of the resulting system
like: (security), usability, reliability, performance & supportability

NR specify system properties, such as reliability and safety.

NR are often called “quality attributes”
More critical than functional requirements.
Represents 20% of the requirements of a system
Hardest to elicit and specify
Defining good nfrs requires not only the involvement of the customer but
the developers too
 Non- Functional requirements

All requirements must be verifiable

 If not ‘verifiable’ then there is no indications that these requirements
have been satisfied.

 Some must also be measured.

 Some may be directly measured; some measured via simulation.

 If not met, the system may be useless.
 They are not “second class” requirements.
 Non- Functional requirements
NR place restrictions on the product being developed, the
development process, and specify external constraints that the
product must meet.

Example
The product must be available at the beginning of the next year

The product shall operate on a 3G mobile telephone.

The system shall be easy to use

The system should not fail more than twice in a week.

The system shall respond to every user action in less than 3 seconds
 Domain Requirements
 Requirements that come from the application domain of the system
and that reflect characteristics of that domain.
 Functional or non-functional requirements derived from
application domain (e.G., Legal requirements or physical laws).
 Derived from the application domain rather than user needs.

 May be new functional requirements or constraints on existing

requirements.
 If domain requirements are not satisfied, the system may be
unworkable.
 Domain Requirements
Example:

 A train control system has to take into account the braking characteristics in
different weather conditions. This is a domain requirement for a train
protection system.

 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.
Organizational requirements(Process)
 Are a consequence of organizational policies and procedures e.G.
Process standards used, implementation requirements, etc.

 Are constraints placed upon the development process of

the system
 Process requirements include:
 Requirements on development standards and methods which must be
followed
 CASE tools which should be used
 The management reports which must be provided
Organizational requirements(Process)
Examples
 The development process to be used must be explicitly defined and must
be conformant with ISO 9000 standards

 The system must be developed using the XYZ suite of CASE tools

 Management reports setting out the effort expended on each identified

system component must be produced every two weeks

 A disaster recovery plan for the system development must be specified

 External requirements
Arise from factors which are external to the system and its development
process e.G. Interoperability requirements, legislative requirements, etc.

External requirements are based on:

 Application domain information
 Organisational considerations
 The need for the system to work with other systems
 Health and safety or data protection regulations
 Or even basic natural laws such as the laws of physics

Examples
 Medical data system - the organisation’s data protection officer must certify that
all data is maintained according to data protection legislation before the system
is put into operation
 What are Quality Attributes…?
A set of constraints the system must satisfy and the standards which
must be met by the delivered system.
 Performance,
 Reliability,
 Usability,
 Efficiency,
 Maintainability,
 Portability, Scalability,
 Security,

 Integration etc.,

Describes “how” the system achieves its functional requirements

 Chapter 3 and 4
Requirement Engineering Process,
By:
Hailemichael Kefie
Software Engineering Dept.
Requirements Engineering Processes
 Five distinct steps of R.E process
Feasibility study

Requirements elicitation

Requirements analysis

Requirements specification

System modeling

Requirements validation &verification

Requirements management
Feasibility Study

Feasibility study leads to a decision:

go ahead
do not go ahead
think again

In research, feasibility study is often in the form of a proposal.

A feasibility study decides whether not the proposed system is

worthwhile.
Feasibility Study
It is a short focused study that checks
If the system contributes to organizational objectives or not;
If the system can be engineered using current technology and within budget
or not;
If the system can be integrated with other systems that are used or not;

Feasibility Report….
Based on information assessment (what is required),information
collection, Feasibility report writing will be carried over…..
 Requirements Elicitation
 Is the process through which the customer and developer
discover, review, articulate, and understand the users needs and
constraints on the software and development activities.

RE is about discovering what requirements a system should be

based upon.

This doesn’t involve just stakeholders what they want.

 It Requires a careful analysis of:
 The organization

 The application domain

 Organization process where the system will be used to determine what the
stakeholders need.
 Requirements Elicitation
It certainly seems simple enough to ask the customer, the users,
and others
What the objectives of the system are….?
What is to be accomplished…?
How the system or product fits into the needs of the business and
Finally, how the system or product is to be used on a day-to-day basis…..?

 But it isn’t simple—it’s very hard.

 Software Development Process:
Classify Requirements Elicitation

Requirements System Detailed Implemen-

Analysis Testing
Elicitation Design Design tation

Implemented
Expressed in By
Structured By Realized By
Terms Of Verified
By

class...
class...
class... ?
class.... ?
Use Case Application Solution
Domain Subsystems Source Test
Model Domain
Objects Code Cases
Objects
Components of requirements elicitation

Stakeholder
Application
Problem to context
Domain
be solved
Business
Needs and constraints
 Components of requirements elicitation
Application domain understanding : Application domain knowledge
is knowledge of the general area where the system is applied.

Problem understanding: The details of the specific customer problem

where the system will be applied must be understood.

Business understanding: You must understand how systems

interact and contribute to overall business goals.

Understanding the needs and constraints of system

stakeholders: You must understand, in detail, the specific needs of
people who require system support in their work.
Process of Requirements Elicitation: Products of Requirements Process
 Elicitation Techniques
Specific techniques which may be used to collect knowledge
about system requirements.

This knowledge must be structured:

Partitioning - aggregating related knowledge.
Abstraction - recognizing generalities.
Projection - organizing according to perspective.

Elicitation problems:
Not enough time for elicitation.
Insufficient preparation by engineers.
Stakeholders are unconvinced of the need for a new system.
Specific Elicitation Techniques
Specific Elicitation Techniques
1. Review of Literature
 All documentation on data carriers (forms, records, report, manuals
etc.) are organized and evaluated as and when available.

2. Onsite observations / Direct observation

 It requires going to user area & may cause adverse reactions by the
user staff if not handled properly.

 It is time- consuming

 OBJECTIVE: of on site observation is to get as close as possible to

the real system being studied, movement of people & work flow.
Specific Elicitation Techniques
3. Questionnaire:
 A set of questions designed to generate the statistical information from
a specific demographic needed to accomplish the research objectives
1. Close ended questionnaires
 Fill in the blanks, dichotomous (yes / no type), ranking scale, multiple-choice and
rating scale

2. Open ended questionnaires

• It requires no response direction or specific response

• Users can respond in their own words
• The answer is written in the space provided
• Scoring takes more time to analyze.
Specific Elicitation Techniques

4. Interview:
The requirements engineer or analyst discusses the system with different
stakeholders and builds up an understanding of their requirements.

Two types of interview:

 Closed interviews: the requirements engineer looks for answers to a pre-
defined set of questions.
 Open interviews: there is no predefined agenda and the requirements
engineer discusses, in an open-ended way, what stakeholders want from the
system.
Interviewing Tips
Interviewers should be open-minded, willing to listen to
stakeholders and should not have pre-conceived ideas about the
requirements.

During the interview

Behave professionally, you will receive the same attitude from your
interviewee.
Take notes of all the necessary information.
Don’t make the conversation too lengthy
Do not prepare too many questions to ask.
The interview paper and minutes are always useful for you and your
successor
Interviewing Tips

 It’s important to open and close the interview carefully

 When opening the interview, try to do it in a trustful, respective way with
your good will.
When closing the interview, you should recap the main points of the
interview, make arrangement for the following cooperation and leave the
issues open for discussion between both sides.
Specific Elicitation Techniques

5. Requirements reuse
Reuse involves taking the requirements which have been developed for
one system and using them in a different system.

Requirements reuse saves time and effort as reused requirements have

already been analyzed and validated in other systems.

Currently, requirements reuse is an informal process but more systematic

reuse could lead to larger cost savings.
Thank
ThankYou
You ...
...