Introduction to Requirements engineering

1. Chapter 1
Introduction to Requirement Engineering

2. 2
 What are requirements?
 Types of requirements
 Requirement Engineering: Introduction
 What is requirement engineering?
 Why Requirement Engineering?
 Requirement requirements: How
 Requirement requirements: When
 Stakeholders in Requirement Engineering: Who
Contents

3.  Software requirements are the descriptions of the
system services (essential & desired) and
constraints (on System operation and software
development process).
 SWRequirements are statements of what the
system must do, how it must behave, the properties
it must exhibit, the qualities it must possess, and the
constraints that the system and its development
must satisfy.
 The Institute of Electrical and Electronics Engineers
(IEEE) defines a requirement as
 a condition or capability needed by a user to solve a
problem or achieve an objective
What are requirements?

4.  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

5. 5
 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
What are requirements?...

6.  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 is still
considered the major cause of software failure today" .
6

7. Examples of Requirements
 The system shall maintain records of all payments
made to employees on accounts of salaries,
bonuses, travel/daily allowances, medical
allowances, etc.
 The system shall interface with the central computer
to send daily sales and inventory data from every
retail store
 The system shall maintain records of all library
materials including books, serials, newspapers and
magazines, video and audio tapes, reports,
collections of transparencies, CD-ROMs, DVDs, etc
 The system shall allow users to search for an item by
title, author, or by International Standard Book
Number.
7

8. …Examples of Reqs.
 The system’s user interface shall be implemented
using a web browser
 The system shall support at least twenty
transactions per second
 The system facilities which are available to public
users shall be demonstrable in ten minutes or
less
8

9. Why Requirements….
 The most common reasons for project failures are not technical
and Table 1.1 identifies the main reasons why projects fail. 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%
Hence giving emphasis to requirements is crucial in any system
dev’t.
9

10. 10
 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.
 describe what the system or software must do and sometimes
called behavioral or operational requirements.
 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?
Types of requirements

11. Functional Requirements
 Statements describing what the system does
 Functionality of the system.
 Statements of services the system should provide
 Reaction to particular inputs
 Behavior in particular situations
 Abnormal behavior is also documented as
functional requirements in the form of exception
handling
 Functional requirements should be complete and
consistent
 Customers and developers usually focus all their
attention on functional requirements
11

12. Functional Requirement
Examples
 The system shall solve a quadratic equation using
the following formula
x = (-b+sqrt(b2 – 4*a*c))/2*a
 The user shall be able to search either the entire
database of patients or select a subset from it
(admitted patients, or patients with asthma, etc.)
 The system shall provide appropriate viewers for the
user to read documents in the document store
 The system shall allow customers to return non-
perishable items within fifteen days of the purchase.
A customer must present the original sale receipt to
return an item
12

13. Comments on Examples
 Notice the level of detail in different requirements
described above. Some are very detailed compared
to others.
 Notice the ambiguity in the requirement, which uses
the term ‘appropriate viewers’
 This requirement does not mention the formats of
documents and types of viewers, which can be used
 Notice the ambiguity in the requirement for solving
the quadratic equation. The requirement does not
speak about the possibility when the value of ‘a’ is
zero
 Incomplete and ambiguous requirements are open to
multiple interpretations and assumptions
 This can lead to the development of poor quality, or
13

14.  Non-functional requirements (NR): 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.
14
Types of requirements

15. 15
 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
Types of requirements…

16. 16
 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.
Types of requirements…

17. 17
 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) which must be
incorporated in the system.
Types of requirements…

18. 18
 Domain Requirements
 Requirements that come from the application
domain of the system and that reflect characteristics
of that domain.
 Domain requirements are not from specific needs
of system users.
 They usually include specialized terminologies
reference to domain concept - they are difficult to
understand
 Implicitness is another problem with domain
requirements
 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
Types of requirements…

19. Domain Requirements Example
 Banking domain has its own specific
constraints, for example, most banks do not
allow over-draw on most accounts, however,
most banks allow some accounts to be over-
drawn
 In a commission-based sales businesses, there
is no concept of negative commission.
However, if care is not taken novice developers
can be lured into developing systems, which
calculate negative commission.
 For 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
19

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

21. 21
 Software requirements are defined at various
levels of detail and granularity.
 Business Requirements:
 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.
 They are captured in a document describing the
project vision and scope.
 A key factor in the success of a system is the
extent to which the system supports the
business requirements and facilitates an

22. 22
 User Requirements:
 User requirements add further detail to the
business requirements.
 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.
 Eg. The system should be easy to use by
medical staff and should be organized in
such a way that user errors are minimized.

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

24. 24
 To understand customers’ requirements about
the software to be developed is extremely
important.
 However,
 Customers are unable to express requirements
explicitly
Typically, they can not tell you what they
want clearly.
The requirements that customers or end-
users present are often: incomplete,
inaccurate, and inconsistent.
 Stakeholders (Business and Technical groups)
speak different languages.
 Software requirements are often extremely

25. Inverse Requirements
 They explain what the system shall not do.
Many people find it convenient to describe their
needs in this manner
 These requirements indicate the indecisive
nature of customers about certain aspects of a
new software product
 Example:
The system shall not use red color in the user
interface, whenever it is asking for inputs from
the end-user
25

26. Design and Implementation Constraints
 They are development guidelines within which
the designer must work
 These requirements can seriously limit design
and implementation options
 Can also have impact on human resources
Examples
 The system shall be developed using the
Microsoft .Net platform
 The system shall be developed using open
source tools and shall run on Linux operating
system
26

27. Sources of Requirement
 Stakeholders
People affected in some way by the
system
 Documents
 Existing system
 Domain/business area
27

28. 28
Requirement Engineering: Introduction
 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

29. 29
 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 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).

30.  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).
30

31. Contd…
 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
31

32. 32
 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
Why Requirement Engineering?

33. 33
 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
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.

34. 34
 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, analyzing, specifying, and validating the
requirements.
 The activities used for requirement engineering vary widely
depending on the application domain, the people involved and the
organisation developing the requirements.
Requirement requirements: How

35.  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
35
Requirement Engineering: When

36.  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
36
Contd….

37. 37
 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.
 .
Stakeholders: The Who of RE

38. Contd..
 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)
38

39.  anyone who benefits from the system (functional,
political, financial and social beneficiaries)
 anyone involved in purchasing or procuring the
system. In a mass-market product organization,
product management, marketing and sometimes
sales act as surrogate consumers (mass-market
customers) to guide development of the product
 organizations which regulate aspects of the
system (financial, safety, and other regulators).
 those organizations who integrate horizontally
with the organization for whom the analyst is
designing the system
39

40. 40
 Example
 For an automated railway signaling system (a
system used to control railway traffic safely)
possible stakeholders are
 Train company operators responsible for
running the system
 Train crew
 Railway managers
 Passengers
 Equipment installation and maintenance
engineers
 Safety certification authorities

41. 41
 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.
Stakeholders…

42. 42
 The suppliers of the software product include
individuals and teams that are
 part of the organization that develops the
software product or
 part of the organizations that distribute the
software product or
 involved in other product delivery methods (for
example, outsourcing).
 System analysts, designers, developers etc are
some examples among suppliers

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

44. ATM stakeholders
 Bank customers
 Representatives of other banks
 Bank managers
 Counter staff
 Database administrators
 Security managers
 Marketing department
 Hardware and software maintenance engineers
 Banking regulators
44

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

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