Requirement Engineering

<< SEng3051 >>

Chapter – One
Introduction

04/09/2021 By Software Engineering Department 1

 Contents

 What are Requirements ?

 Types of Requirements
Functional Requirements
 Non Functional Requirements
 Domain Requirements
 Business Requirements
 User and System Requirements
 Requirement Engineering
 Requirement Engineering (How ? and When ?)
 Stakeholders in Requirement Engineering (Who ?)

04/09/2021 By Software Engineering Department 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,
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.

04/09/2021 By Software Engineering Department 3

 Cont.….
• 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 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).

04/09/2021 By Software Engineering Department 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..

04/09/2021 By Software Engineering Department 5

 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
By Software Engineering Department
04/09/2021 6
[Davis 1990a, faulk 1997a]. "The inability to produce complete, correct, and unambiguous software
requirements is still considered the major cause of software failure today" .

• 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.
04/09/2021 By Software Engineering Department 7
Types of Requirements
Software Requirements are classified as:
 User Requirements
 System Requirements
………………………………………………….
System Requirements are further classified as:
 Functional Requirements
 Non-Functional Requirements

04/09/2021 By Software Engineering Department 8

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.
• They are captured in the requirement definition document.
• Statements in natural language plus diagrams of the services the system
provides and its operational constraints. Written for customers.

04/09/2021 By Software Engineering Department 9

 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 should be implemented so
may be part of a contract between client and contractor

04/09/2021 By Software Engineering Department 10

 System 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.
• Functional requirements 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?

04/09/2021 By Software Engineering Department 11

 Cont.…..

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.
• NR place restrictions on the product being developed, the development process,
and specify external constraints that the product must meet.

04/09/2021 By Software Engineering Department 12

 Cont.….
NR Example

• The product must be available at the beginning of the next year

• The product shall operate on a 3G mobile telephone.
• The system should not fail more than twice in a week.
• The system shall respond to every user action in less than 3 seconds

Be careful while writing non-functional requirements. They should not be

ambiguous.

04/09/2021 By Software Engineering Department 13

 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.
Example: the system shall ensure that data is protected from unauthorised
access.

04/09/2021 By Software Engineering Department 14

Further Classifications of Requirements
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 or 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 may be unworkable.

04/09/2021 By Software Engineering Department 15
 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 organization in achieving them.

04/09/2021 By Software Engineering Department 16

 Requirement Engineering
… Deeping our toe into the course …

• RE is the branch of software engineering 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).
• 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.
04/09/2021 By Software Engineering Department 17
 Requirement Engineering
• 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.
• 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

04/09/2021 By Software Engineering Department 18

 Cont.…
• 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).

04/09/2021 By Software Engineering Department 19

 Cont.…
• 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).
• 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.

04/09/2021 By Software Engineering Department 20

 RE – Basic Definition

04/09/2021 By Software Engineering Department 21

 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.

04/09/2021 By Software Engineering Department 22

 Cont.…
• 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.

04/09/2021 By Software Engineering Department 23

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 and the organisation developing the
requirements.

04/09/2021 By Software Engineering Department 24

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

04/09/2021 By Software Engineering Department 25

 Cont.…
• 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

04/09/2021 By Software Engineering Department 26

 Stakeholders: The Who 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.
• Stakeholders have a tendency to state requirements in very general and vague
terms
• different stakeholders have different requirements – sometimes even conflicting.

04/09/2021 By Software Engineering Department 27

 Cont.…
• 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)
• 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)

04/09/2021 By Software Engineering Department 28

 Cont.…
• People or organizations opposed to the system (negative stakeholders; see
also misuse case)
• those organizations who integrate horizontally with the organization for
whom the analyst is designing the system
• 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
04/09/2021 By Software Engineering Department 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 generated by the product.

04/09/2021 By Software Engineering Department 30

 Stakeholders…

• The suppliers of the software product include individuals and teams that
are
• 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.

04/09/2021 By Software Engineering Department 31

 Stakeholders: Example

• Assume Wollo 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.

WOU, WOU 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: WOU
Customers: Other Universities
Users: Anyone using the system

04/09/2021 By Software Engineering Department 32

 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

04/09/2021 By Software Engineering Department 33

 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 care.
• Health care managers who obtain management information from the
system.
04/09/2021 By Software Engineering Department 34
 Cont.…
• 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.

04/09/2021 By Software Engineering Department 35

 ?? Home Work Questions
 Select one software system /you “might” or “might not” know before/ and write at
least:
Ten Functional Requirements
Ten Non Functional Requirements
 Four Domain Requirements
Three Business Requirements
Five User Requirements
Five System Requirements
 List and describe the possible stakeholders of the selected system

04/09/2021 By Software Engineering Department 36