Chapter 1

Introduction to Requirement Engineering

By Elsabet M.
 Contents
 What are requirements?
 Requirement Engineering: Introduction
 Why Requirement Engineering?
 Requirement requirements: How
 Requirement requirements: When
 Stakeholders in Requirement Engineering: Who

2
 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
 Well defined requirements are measurable & provide the basis
for defining project success
3
 What are Requirement cont.…?
 A requirement is a condition or capability needed by a user
 to solve a problem or to achieve an objective or
 that must be met by a system or system component to satisfy
a contract, standard, specification, or other formally imposed
document.
 In simple terms, it's a requested need not yet implemented.

4
 What are requirements cont.?
 Requirements should always be statement of what a system should
do rather than a statement of how it should do it.
 However, sometimes it is necessary for the requirement documents
to include information about the design of the system.
 Because:Readers are often practical engineers – they can relate
it to implementation descriptions
 The system may be one of several systems in an environment - to
be compatible with its environment specifying implementation
issues are important
 The specifiers are often experts in the application domain where
the system is to be used.
 The requirements may be descriptions of how to carry out a
computation using application domain

5
 Contd..
 Snowballing cost of early mistakes: Requirements are cheap to
change while they are being worked on.
 High price of failure: The most common reasons for project
failures are not technical and Table 1.1 identifies the main reasons
why projects fail.
 Incomplete requirements 13.1%
 Lack of user involvement 12.4%
 Lack of resources 10.6%
 Unrealistic expectations 9.9%
 Lack of executive support 9.3%
 Changing requirements/specifications 8.7%
 Lack of planning 8.1%
 Didn’t need it any longer 7.5%
6Hence giving emphasis to requirements is crucial in any system
 Why do you need good requirements?

Distribution of Software errors

ü Requirement:82%,Design:13%,code:1%,othere:4%
Cost of rectifying errors
7 ü Design:27%,code:7%,Req:56%,other:10%
 Requirement Characteristics
 Type: the source and contractual applicability
 Application: the object of requirement
 Compliance level: the depth of compliance mandated for a requirement
 Priority: relative importance of requirement
Requirement Types
 Stated Requirements: Requirements stated in the Statement of Work (SOW)
or similar documentation identifying specific problems to be solved
 Unstated Requirements: Requirements implied or understood although not
apparent in the SOW or similar documentation
 Derived Requirements: Requirements identified during the analysis effort
Compliance of Requirement
 Mandatory: Must be implemented
 Guidance: Desirable that it can be implemented
 Information: Non-binding statements which significantly influence the
context, meaning, and understanding of other requirements…

8
 A Good set of requirements are …
 Well defined requirements are
Needed – Discrete
Correct – Unique
Complete – Verifiable
Concise – Traceable
Unambiguous – Consistent
Requirements understanding is hard
 Visualizing a future system is difficult
 Capability of the future system is not clear, hence needs are not
clear
 Requirements change with time
 It is essential to gather appropriate requirements then a proper
analysis and specification of requirements before proceeding
to the Design
9
 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
 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”
10
 Requirements Engineering
 Requirement engineering is a systematic process for eliciting,
documenting, validating, and managing requirements throughout
the software development lifecycle. It is a critical phase in software
engineering that focuses on understanding the needs and constraints
of stakeholders to define the functionality, performance, and other
characteristics of the software system to be developed.


11
 Requirement Engineering…
 The term “requirements engineering” is often too narrowly equated
with requirements analysis, which is just one of the activities within
the wider discipline. The emphasis on engineering is useful for two
main reasons:
 Dealing with requirements is an essential part of every
engineering endeavor. Indeed, requirements engineering is a
subset of systems engineering in general, not just software
engineering.
 The term subsumes the wide variety of other titles given to
activities relating to requirements, such as requirements analysis
and the two terms used for key process areas: requirements
management and requirements development (CarnegieMellon
2006).

12
 Requirement Engineering…
 the subset of systems engineering concerned with discovering,
developing, tracing, analyzing, qualifying, communicating and
managing requirements that define the system at successive
levels of abstraction.
 Requirements engineering is complex because of the three roles
involved in producing even a single requirement: the requestor
(referred to as the "user" in the IEEE definition), the developer
(who will design and implement the system), and the author
(who will document the requirements).

13
 Requirements Engineering…
 Typically, the requestor understands the problem to be solved by
the system but not how to develop a system.
 The developer understands the tools and techniques required to
construct and maintain a system but not the problem to be solved
by that system.
 The author needs to create a statement that communicates
unambiguously to the developer what the requestor desires.
Hence, requirements address a fundamental communications
problem.
 RE according to Laplante (2007) is "a subdiscipline of systems
engineering and SW engineering that is concerned with
determining the goals, functions, and constraints of HW&SW
systems.

14
 What is Requirement Engineering?
 Definition

15
 Why Requirement Engineering?
 In spite of new and effective software engineering techniques,
software systems
 Are delivered late and over budget
 Do not do what really users want
 Are prone to failure
 Some key aspects of successful software development are
 User input and involvement
 Effective management and support
 Resources
 Clearly defined, complete requirements
 Numerous software engineering studies show this repeatedly
 40-60% of all defects found in software projects can be traced
back to poor requirements.

16
 Why Requirement Engineering?...
The hardest single part of building a software system is deciding
precisely what to build. No other part of the conceptual work is as
difficult as establishing the detailed technical requirements,
including all the interfaces to people, to machines, and to other
software systems No part systems. of the work so cripples the
resulting system if done wrong. No other part is more difficult to
rectify later. (Brooks, 1987)
No Silver Bullet: Essence and Accidents of Software Engineering.

 Generally, defining and applying good, complete requirements is

hard to work, and success in this endeavor has eluded many
software engineers. Requirement Engineering alleviates this
problem

17
 Requirement requirements: How
 Software requirements engineering is made up of two major
processes:
 requirements development (RD) and requirements
management(RM).
 Requirements development encompasses all of the activities
involved in
 eliciting,
 analyzing,
 specifying,
 and validating the requirements.
 The activities used for requirement engineering vary widely
depending on the
 application domain,
 The people involved
18
 and the organisation developing the requirements.
 Requirement Engineering:When?
 Requirements development encompasses all the activities involved
in identifying, capturing, and agreeing upon the requirements.
 The majority of the requirements development activities occur
during the early concept and requirements phases of the life cycle.
 Continued elaboration of the requirements, however, can progress
into the later phase of the software development life cycle.
 Requirements management, which is an ongoing activity
throughout the software development life cycle, encompasses all of
the activities involved in

19
 Requirement Engineering:When?
 Requesting changes to the baselined requirements
 performing impact analysis for the requested changes
 approving or disapproving those changes, and implementing the
approved changes
 ensuring that all work products and project plans are kept
consistent and tracking the status of the requirements as one
progresses through the software development process.
 The implemented software product is validated against its
requirements during the testing phases of the life cycle to identify
and correct defects and to provide confidence that the product
meets those requirements.
 Requirements engineering is an iterative process

20
 Stakeholders:TheWho of RE
 System Stakeholders are people or organizations who will be
affected by the system and who have direct or indirect influence on
the system requirements.
 In order to develop a good requirement document, it is imperative
to involve all kinds of user in the requirement engineering process.
 You need to identify the stakeholders in a system and discover their
requirements.
 If you don’t do, you may find that they insist on changes during the
system development or after it has been delivered for use.

21
 Stakeholders:TheWho of RE
 Stakeholders have a tendency to state requirements in very
general and vague terms
 different stakeholders have different requirements –
sometimes even conflicting
 It is increasingly recognized that stakeholders are not limited to
the organization employing the analyst. Other stakeholders will
include:
 anyone who operates the system (normal and maintenance
operators)
 anyone who benefits from the system (functional, political,
financial and social beneficiaries)

22
 Stakeholders…
 There are three main categories of stakeholders:
 the acquirers of the software product
 the suppliers of the software product and
 other 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.

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

24
 Stakeholders: Example
Assume Injibara university 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.
 Identify all stakeholders for the system mentioned.
 INU, INU 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: INU
 Customers: Other Universities
 Users: Anyone using the system

25
Stakeholders in the MHC-PMS
 Patients whose information is recorded in the system.
 Doctors who are responsible for assessing and
treating patients.
 Nurses who coordinate the consultations with doctors
and administer some treatments.
 Medical receptionists who manage patients’
appointments.
 IT staff who are responsible for installing and
maintaining the system.
 A medical ethics manager who must ensure that the
system meets current ethical guidelines for patient
26 care.
 Contd…
 Health care managers who obtain management
information from the system.
 Medical records staff who are responsible for
ensuring that system information can be
maintained and preserved, and that record
keeping procedures have been properly
implemented.

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

28
 The Inputs & Outputs of RE …

29
 Success Attributes that
Requirements Engineering Affect
 User Involvement
 Clear Statement of requirements
 Proper Planning
 Realistic Expectations
 Smaller Project Milestones
 Clear Vision and Objectives
 Hard Working, Focused Team
 Spirit & Staff

30