Chapter 1

Introduction to Requirement Engineering

 Contents
 What are requirements?
 Types of requirements
 Functional, non-functional & domain requirements
 Business, user & System requirements
 Requirement Engineering: Introduction
 What is requirement engineering?
 Why Requirement Engineering?
 Requirement requirements: How
 Requirement requirements: When
 Stakeholders in Requirement Engineering: Who

2
 What are requirements?
 Software requirements are the descriptions of the system
services (essential & desired) and constraints (on System
operation and software development process).
 Requirements are statements of what the system must do,
how it must behave in particular situations, the properties
it must exhibit, the qualities it must possess, and the
constraints that the system and its development must
satisfy.
 According to Institute of Electrical and Electronics
Engineers (IEEE) standard 729, a requirement is defined
as follows:
 a condition or capability needed by a user to solve a
3
problem or achieve an objective
  a condition or capability that must be met or
possessed by a system or system component to
satisfy a contract, standard, specification, or other
formally imposed document
 a documented representation of a condition or
capability as in definition 1 or 2 [IEEE 1990a] .
 Requirement: A statement that identifies a product
or process operational, functional, or design
characteristic or constraint, which is un ambiguous,
testable or measurable, and necessary for product
or process acceptability (by consumers or internal
quality assurance guidelines).
4
 Requirements might describe:
•A user-level facility (e.g. the word processor must include a
spell checking and correction command)
•A very general system property (e.g. the system must
ensure that personal information is never made available
without authorization)
•How to carry out some computation (e.g. the overall mark
is computed by adding the students exam, project &
coursework marks based on the following formula. Total =
[2 * exam + 3*(project + coursework)]/5
• constraint on the development of the system (e.g. The
system must be developed using java) Etc..
• [Davis 1990a, Faulk 1997a]. "The inability to produce
complete, correct, and unambiguous software requirements
5
is still considered the major cause of software failure
today" .
 What are requirements?...
 As much as possible, requirements should describe what the
system should do, but not 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
6
using application domain
  The most common reasons for project failures are not
technical. Below the main reasons why projects fail is
identified. The data is drawn from surveys conducted by the
Standish Group in 1995 and 1996.
 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%
7
Hence giving emphasis to requirements is crucial in any system
dev’t.
 Types of requirements
 Software requirements are often classified as functional
requirements, non-functional requirements or domain
requirements
 Functional requirements: Functional requirements capture
the intended behavior of the system. This behavior may
be expressed as services, tasks or functions the system is
required to perform. i.e. “What the system should do?”.
 IEEE defines functional requirements as 'a function that a
system or component must be able to perform.'
 Statements of services the system should provide, how the
system should react to particular inputs and how the
system should behave in particular situations.
8
 In order to find out functional requirements of a system try
to answer the questions below
 What inputs the system should accept?
 What outputs the system should produce?
 What data the system should store that other systems
might use?
 What computations the system should perform?
 E.g. The system shall display the longitude and latitude
of the employee through GPS.
 Non-functional requirements (NR): define the overall
qualities or attributes of the resulting system like:
portability, (security), maintainability, reliability, scalability,
performance, reusability, flexibility,…
 They are basically the quality constraints that the system
9
must satisfy according to the project contract.
 Types of requirements…
 NR place restrictions on the product being developed, the
development process, and specify external constraints that the
product must meet.
 Constraints on the services or functions offered by the
system such as timing constraints, constraints on the
development process, standards, etc.
 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.
10  The system shall respond to every user action in less than 3 sec.
 Types of requirements…
 Functional Vs Non-Functional Requirements
 There is no a clear distinction between functional and
non-functional requirements.
 Whether or not a requirement is expressed as a
functional or a non-functional requirement may depend:
 on the level of detail to be included in the
requirements document
 the degree of trust which exists between a system
customer and a system developer.

11
 Types of requirements…
 Example: The system shall ensure that data is protected from
unauthorised access.
 Conventionally, this would be considered as a non-
functional requirement because it does not specify specific
system functionality which must be provided. However, it
could have been specified in slightly more detail as
follows:
 The system shall include a user authorisation procedure
where users must identify themselves using a login name
and password. Only users who are authorised in this way
may access the system data.
 In this form, the requirement looks rather more like a
functional requirement as it specifies a function (user login)
12
which must be incorporated in the system.
 Types of requirements…
 Domain Requirements
 Constraints on the system from the domain of operation.
 Requirements that come from the application domain of
the system and that reflect characteristics of that domain.
 They are the requirements which are characteristic of a
particular category or domain of projects.
 Domain requirements are not from specific needs of
system users.
 They usually include specialized terminologies reference
to domain concept - they are difficult to understand
 They may be new functional requirements (may be
defining specific computations) or can be constraints on
existing requirements.
 If domain requirements are not satisfied, the system may
13
be unworkable.
  For instance, in an academic software that maintains
records of a school or college, the functionality of
being able to access the list of faculty and list of
students of each grade is a domain requirement.
These requirements are therefore identified from that
domain model and are not user specific.
Domain requirements problems
 Understandability
 Req’ts are expressed in the language of the application
domain; often not understood by software engineers.
 Implicitness
 Domain specialists understand the area so well that they
do not think of making the domain requirements explicit.
14
 Kinds of requirements based on the intended purpose
and target audience:
 Business Requirements:
 Describes why the project is being started and what is
its scope and objective.
 These are used to state the high-level business objective
of the organization or customer requesting the system or
product.
 They are used to document main system features and
functionalities without going into their nitty-gritty (basic
important) details.
 E.g. Implement a web and mobile-based employee tracking
system that tracks field employees and increases efficiency by
means of monitoring employee activity, absenteeism, and
15
productivity.
 User Requirements:
 User requirements add further detail to the business
requirements.
 What services the system is expected to provide to
system users and the constraints under which it must
operate.
 They are called user requirements because they are
written from a user’s perspective and the focus of user
requirement describe tasks the user must be able to
accomplish in order to fulfill the above stated business
requirements.
 E.g. The system should be easy to use by site
engineers and should be organized in such a way
16 that user errors are minimized.
System Requirements:
 Detailed description of what the system should do
including the software system's functions, services, and
operational constraints.
 The system requirements document (sometimes called a
functional specification) should define exactly what is to
be implemented.
 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
 Written as a contract between client and contractor
17
18
 Requirement Engineering: Introduction
 Requirement Engineering is the process of defining,
documenting and maintaining the requirements.
 It is the process of understanding and defining what
services are required and identifying the constraints on
these services.
 Requirement engineering provides
 the appropriate mechanism to understand what the customer
desires,
 analyzing the need, and assessing feasibility,
 negotiating a reasonable solution,
 specifying the solution clearly,
 validating the specifications and
 managing the requirements as they are transformed into a
19
working system.
 Requirements Engineering(RE) provides the basic
agreement between end-users and developers on what
the software should do.
 RE “involves all life-cycle activities devoted to
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”
(DoD 1991).
 A branch of SWE concerned with the real world goals for,
functions of, and constraints on software systems and also
concerned with the relationship of these factors to precise
specifications of software behavior (Zave 1997).

20
  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 author (who will document the requirements).
 the developer (who will design and implement the
21
system), and
 Contd…
 Typically, the requestor understands the problem to be
solved by the system but not how to develop a 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.
 The developer understands the tools and techniques
required to construct and maintain a system but not the
problem to be solved by that system.

22
 What is Requirement Engineering?
 Definition

23
 Why Requirement Engineering?
 There are many issues that can have a negative impact on software
development projects and products if practitioners don’t do a good
job of defining their software requirements.
 These issues include:
 Incomplete requirements
 software product does not meet all of the customer and user’s
needs.
 Lack of user involvement
 Requirements churn
 changes in the requirements after they are initially agreed to
and baselined.
 Wasted resources
 Requirements errors account for 70 to 85 percent of the rework
costs on a software project
24
 Why Requirement Engineering?...
 Gold plating
 developer adds functionality to the software that was not in the
requirements
 Inaccurate estimates
 Without a clear picture of that scope, estimates of the project
schedule, cost, and quality will be less accurate.

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)
25 No Silver Bullet: Essence and Accidents of Software Engineering.
 Requirement Engineering: How
 Software requirements engineering is a disciplined, process-
oriented approach to the definition, documentation, and
maintenance of software requirements throughout the software
development life cycle.
 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, analysing, specifying, and validating the
requirements.
 The activities used for requirement engineering vary widely
depending on the application domain, the people involved
26 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 on-going
activity throughout the software development life
27
cycle, encompasses all of the activities involved in:
Contd….
 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.
28
 Requirements engineering is an iterative process
 Stakeholders: The Who of RE
 Stakeholders are individuals who affect or are affected
by the software product and therefore have some level of
influence over the requirements for that software product.
 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.

29
 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
30
generated by the product.
 The suppliers of the software product include individuals
and teams that:
 are part of the organization that develops the software product
 are part of the organizations that distribute the software product
 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.
 Other stakeholders includes legal or contract
management, manufacturing or product release
management, sales and marketing, upper management,
government or regulator agencies, and the society at
31
large .
 Stakeholders: Example
Assume MAU 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.

 MAU, MAU managers, Students, doctors and other health
officials, the company ABC, etc
 If the University sells the system to other universities so as to get
compensated for what it has spent, who is the client, the customer
and the user?
 Client: MAU
 Customers: Other Universities
32
 Users: Anyone using the system