CHAPTER THREE

REQUIREMENT ENGINEERING

1
 Software Requirements

Requirements are descriptions of the services that a software system must provide
and the constraints under which it must operate
 Requirements are also called software requirements.
 Software requirements are description of features and functionalities of the target
system.
 A software requirement is also a capability of the system/software needed by the
user to solve a problem or to achieve an objective.
 In other words, software requirement is a software capability that must be met or
possessed by a system or system component to satisfy a contract, standard,
specification, or other formally imposed documentation.
2
 Software Requirements ----

 The requirement types are, functional, non-functional, architectural,

customer requirements, and etc.
 The set of requirements as a whole represents a negotiated agreement among
the stakeholders.
 A collection of requirements is a requirements document
Requirements may serve a dual function:
 As the basis of a bid for a contract
 As the basis for the contract itself

3
 Requirement Engineering
Requirements Engineering is the process of understanding and defining what services are
required from the system and identifying the constraints on the system’s operation and
development.
 Requirements engineering aims at defining the requirements of the system under
development.
 The process to gather the software requirements from client, analyse and document them is
known as requirement engineering.
The goal of requirement engineering is to develop and maintain sophisticated and
descriptive ‘System Requirements Specification’ document.
 Requirements Engineering – a matter of definition.
Anyone involved in the development of products, systems or software is faced with various
5
questions:
 Requirement Engineering -----

 What are the requirements–i.e. the capabilities and characteristics of the desired
product?
 How can these requirements be specified–i.e. collected, analysed, documented and
validated?
 How should requirements be managed– i.e. released, possibly modified and tracked?
The answers to these questions are provided by requirements engineering (RE):
 RE is the systematic procedure for defining, specifying and managing requirements
for a system, product or software. 
Requirement engineering – includes:
 Elicitation –System specification
6
 Requirement Engineering Process

Requirements engineering helps software engineers to better understand the

problem they will work to solve.
 It encompasses the set of tasks that lead to an understanding of
what the business impact of the software will be,
what the customer wants and how end-users will interact with the software.
Requirement Engineering Process includes:
 Feasibility Study
 Requirements Elicitation and Analysis
 Requirements Specification
 Requirements Validation 7
The Requirements Engineering Process

Feasibility Requirements
stud y elicitation and
anal ysis
Requirements
specification
Feasibility Requirements
repor t validation

System
models
User and system
requirements

Requirements
document

8
 1. Feasibility Study
 A feasibility study decides whether or not the proposed system is
worthwhile.
 A short focused study that checks
If the system contributes to organisational objectives;
If the system can be engineered using current technology and
within budget;
If the system can be integrated with other systems that are used.

9
 Feasibility Study-------
1.1. Economic Feasibility
 Concerned with assessing the financial benefits and costs associated with the
project.
This is also called a cost-benefit analysis.
Benefits and costs can be tangible or intangible
 Tangibles are items which can be quantified in monetary terms and with certainty.
Ex. equipment costs, staff/personnel costs, materials costs, conversion costs,
training costs.
 Intangibles are items for which a value cannot be precisely determined,
Ex. Customer goodwill, employee morale. Operational efficiency 10
 Feasibility Study-------
1.2. Operational Feasibility
 This process examines whether the new project will attain its desired objectives.
 The goal of this study is to understand the degree to which the proposed system will likely
solve the business problems or take advantage of the opportunities specified in the
Systems requirement documents.
1.3. Technical Feasibility
 The goal of this study is to understand the organization’s ability to construct the
proposed system.
 This analysis also includes an assessment of the development group’s understanding of
the possible target hardware, software and operating environments as well as the size,
complexity and the group’s experience with similar systems 11
 Feasibility Study-------
1.4. Schedule Feasibility
 Assessing the degree to which the potential time frame and completion dates for all major
activities within a project meet organizational deadlines and constraints for affecting
change.
1.5. Legal and Contractual Feasibility
 Assessing potential legal and contractual ramification due to the construction of a system
 This study include copyright or nondisclosure violation, labor laws, antitrust legislation,
foreign trade regulations and financial reporting standards as well as current or pending
contractual obligations.
1.6. Political Feasibility
 The process of evaluating how key stakeholders within the organization view the proposed
12
 Feasibility Study Implementation
 Based on information assessment (what is required), information collection and
report writing.
To implement feasibility study, the following questions are prepared and asked the
users or people in the organisation:
 What if the system wasn’t implemented?
 What are current process problems?
 How will the proposed system help?
 What will be the integration problems?
 Is new technology needed? What skills?
 What facilities must be supported by the proposed system? 13
 2. Requirements Elicitation and Analysis
2.1 Requirements Elicitation
 Requirements elicitation is the process of gathering and defining the requirements
for a software/system.
The practice is also sometimes referred to as Requirement gathering.
 The goal of requirements elicitation is to ensure that the software development
process is based on a clear and comprehensive understanding of the customer
needs and requirements.
 Requirements elicitation involves the identification, collection, analysis, and
refinement of the requirements for a software/system.
 It is a critical part of the software development life cycle and is typically performed at
14
 2.1 Requirements Elicitation-------
Requirements elicitation involves stakeholders from different areas of the
organization, including business owners, end-users, and technical experts.
 The output of the requirements elicitation process is a set of clear, concise,
and well-defined requirements that serve as the basis for the design and
development of the software/system.
Requirements elicitation is perhaps the most difficult, most error-prone and
most communication intensive software development.
 It can be successful only through an effective customer-developer
partnership.
It is needed to know what the users really need 15
 2.1 Requirements Elicitation-------
 Requirement Elicitation involves communication among developers, clients, and users to
define a new system.
It focuses on describing the purpose of the system.
 At this stage the client, the developers, and the users identify a problem area and define
a system that addresses the problem.
Such a definition is called a requirements specification and serves as a contract
between the client and the developers.
 The requirements specification is structured and formalized during analysis to produce
an analysis model.
 Failure to do so in requirement elicitation will lead to “unwanted” system
Errors introduced at this stage are expensive system 16
 Requirements Elicitation Methods
Requirements elicitation methods include the following:
 Existing Document Analysis
 Interviews
 Questionnaires
 User observation
 Workshops
 Brain storming
 Use cases
 Role playing and
 Prototyping 17
 Requirements Elicitation Methods-----
1. Existing Document Analysis
 A method by which the system analyst go through each documents used and
relevant to all the processes covered by the system.
 The documents will give information about the data to be captured and the
presentation of the data to the users of the system.
2. Direct Observation
 Direct observation is a method used to verify the already gather information
and to add on to requirement.
 The method will help to see how users behave and do things in their day to day
activity. 18
 Requirements Elicitation Methods-----

3. Questionnaires and Surveys

 The Survey method is an electronic or paper based method of soliciting needs

or requirements from stakeholders.

 The survey method is a list of questions, directed at identifying stakeholder

needs or requirements.

4. Interviews
 An interview is a conversation with stakeholders to elicit or validate needs and

requirements.
 An interview may include one or more stakeholders. 19
 Requirements Elicitation Methods-----

 The interview may also involve a question and answer session used to

discover other potential stakeholders and any discrepancies between needs;

the high-level requirements derived from those needs; and the resulting

detailed requirements.
 Interviews facilitate obtaining approval from stakeholders on their needs,

requirements, and any changes to them.

5. Brainstorming Sessions 
 This technique is used to generate new ideas and find a solution for a specific
issue. 20
 Requirements Elicitation Methods-----
 The members included for brainstorming can be domain experts, subject
matter experts.
This session is generally conducted around the table discussion lead by
highly trained facilitator is required to handle group bias and group
conflicts.
 All participants should be given an equal amount of time to express their
ideas.
 Every idea is documented so that everyone can see it.
 Finally, a document is prepared which consists of the list of requirements
21
and their priority if possible.
 Requirements Elicitation Methods-----
Brainstorming technique is used to answer the following questions:
 What is the expectation of a system?
 What are the risk factors that affect the proposed system development
and what to do to avoid that?
 What are the business and organization rules required to follow?
 What are the options available to resolve the current issues?
 What should we do so that this particular issue does not happen in the
future?

22
 Requirements Elicitation Activities:

 Requirement Elicitation activities map a problem statement into a

requirements specification that we represent as a set of actors, scenarios,
and use cases.
Requirement Elicitation Activities includes:
 Identifying Actors
 Identifying Scenarios
 Identifying Use Cases
 Identifying Relationships
 Identifying Non-functional Requirements
23
 1. Identifying Actors
 During this activity, developers identify the different types of users the
future system will support.
 Actors represent external entities that interact with the system.
An actor can be human or an external system.
 The first step of requirements elicitation is the identification of actors.
This serves both to define the,
boundaries of the system and
to find all the perspectives from which,
the developers need to consider the system. 24
 1. Identifying Actors----------
When the system is deployed into an existing organization (such as a
company), most actors usually exist before the system is developed:
they correspond to roles in the organization.
 Actors are outside of the system boundary; they are external.
 Subsystems and objects are inside the system boundary; they are
internal.
Thus, any external software system using the system to be developed
is an actor.
25
 Questions for Identifying Actors
When identifying actors, developers can ask the following
questions: 
 Which user groups are supported by the system to perform their
work?
 Which user groups execute the system’s main functions?
 Which user groups perform secondary functions, such as
maintenance and administration?
 With what external hardware or software system will the system
26
interact?
 2. Identifying Scenarios
During this activity, developers observe users and develop a set of
detailed scenarios for typical functionality provided by the future
system.
 Scenarios are concrete examples illustrating a single case,
A scenario is “a narrative description of what people do and
experience as they try to make use of computer systems and
applications
 A scenario is a concrete, focused, informal description of a single
27
 2. Identifying Scenarios-----
 Scenarios cannot replace use cases, as they focus on specific
instances and concrete events (as opposed to complete and general
descriptions).
 Scenarios enhance requirements elicitation by providing a tool that
is understandable to users and clients.
 Scenarios can have many different uses during requirements
elicitation and during other activities of the life cycle.
Below is a selected number of scenario types taken from:
28
 2. Identifying Scenarios-----
As-is scenarios
 describe a current situation.
 During reengineering, for example, the current system is understood by observing
users and describing their actions as scenarios.
 These scenarios can then be validated for correctness and accuracy with the users.
Visionary scenarios
 describe a future system.
 Used both as a point in the modeling space by developers as they refine their ideas
of the future system and as a communication medium to elicit requirements from
users.
29

 2. Identifying Scenarios-----
Evaluation scenarios
 describe user tasks against which the system is to be evaluated.
 The collaborative development of evaluation scenarios by users and
developers also improves the definition of the functionality tested by these
scenarios.
Training scenarios
 Tutorials used for introducing new users to the system.
 These are step-by-step instructions designed to hand-hold the user through
common tasks.
30
 Questions for Identifying Scenarios
 What are the tasks that the actor wants the system to perform?
 What information does the actor access? Who creates that data? Can
it be modified or removed? By whom?
 Which external changes does the actor need to inform the system
about? How often? When?
 Which events does the system need to inform the actor about? With
what latency?

31
 2. Identifying Scenarios-----
 Developers use existing documents about the application domain to answer these
questions such as:
user manuals of previous systems, procedures manuals,
company standards,
user notes and cheat sheets,
user and client interviews.
 Drawing user interface mock-ups often helps to find omissions in the specification
and to build a more concrete picture of the system.
The emphasis for developers during actor identification and scenario identification
is to understand the application domain. mock-ups
32
 2. Sample example to Identifying Scenarios
Let’s use Course registration case to identify scenarios:
 Scenario-1
Registering a course at the College of Computer and Information Sciences (CCIS)
for the undergraduate level, involves both the registrar and the student. The
student submits to the registrar’s office, the student Id and a desired Section
number for a certain course. The registrar prints final schedule to the student.
1. Identify the actors from this scenarios.
The two ACTORS in this scenario are : STUDENT and REGISTRAR.
2. Identify the Use cases based on this scenarios
The two USE CASES are: RegisterCourse and PrintSchedule. 33
 2. Sample example to Identifying Scenarios

3. Draw a Use case Diagram.

 The two ACTORS involved in RegisterCourse are both the STUDENT
and the REGISTRAR, meanwhile the REGISTRAR is involved in
PrintSchedule.

34
 3. Identifying Use Cases:
 Developers derive from the scenarios a set of use cases that completely represent
the future system.
use cases are abstractions describing all possible cases.
 A scenario is an instance of a use case; that is, a use case specifies all possible
scenarios for a given piece of functionality.
 A use case is initiated by an actor.
 After its initiation, a use case may interact with other actors, as well.
 A use case represents a complete flow of events through the system in the sense
that it describes a series of related interactions that result from its initiation.
35
 3. Identifying Use Cases ----------
 A use case is a methodology used in in requirement elicitation or
analysis to identify, clarify and organize system requirements.
The method creates a document that describes all the steps taken
by a user to complete an activity.
 A use case is a collection of possible sequences of interactions
between the system and users (external actors) in a particular
environment and related to a particular goal.
The use case is complete when the goal has been satisfied
36
 3. Identifying Use Cases ----------
Use cases provide many benefits beyond defining user requirements. Use cases
can be used to:
 Illuminate and document current or goal-stated methods, systems and
stakeholders
 Identify business-domain classes and their associates
 Drive detailed application analysis and design
 Develop scripts for testing
 Suggest prototyping activity
 Clarify architecture requirements
 Highlight risks and needs for risk management 37
 3. Identifying Use Cases ----
Generalizing scenarios and identifying the high-level use cases that the
system must support enables developers to define the scope of the system.
 Developers name use cases, attach them to the initiating actors, and provide
a high-level description of the use case. 
 Describing the entry and exit conditions of a use case enables developers to
understand the conditions under which a use case is invoked and the impact
of the use case on the state of the environment and of the system.
 Describing the flow of events of a use case enables developers and clients to
discuss the interaction between actors and system.
38
 3. Identifying Use Cases ----
Helps to decide which actions are accomplished by the actor and
which actions are accomplished by the system. 
Describing the quality requirements associated with a use case
enables developers to elicit nonfunctional requirements in the
context of a specific functionality

39
 Simple Use Case Writing guide
1. Use cases should be named with verb phrases. The name of the use case should

indicate what the user is trying to accomplish (e.g., ReportEmergency,

OpenIncident).

2. Actors should be named with noun phrases (e.g., FieldOfficer, Dispatcher, Victim).

3. The boundary of the system should be clear. Steps accomplished by the actor and

steps accomplished by the system should be distinguished.

4. Use case steps in the flow of events should be phrased in the active voice. This

makes it explicit who accomplished the step.

5. The causal relationship between successive steps should be clear. 40

 Simple Use Case Writing guide -----
6. A use case should describe a complete user transaction.
7. Exceptions should be described separately.
8. A use case should not describe the user interface of the system. This takes
away the focus from the actual steps accomplished by the user and is better
addressed with visual mock-ups.
9. A use case should not exceed two or three pages in length. Otherwise, use
include and extend relationships to decompose it in smaller use cases.

41
 4. Identifying Relationships
Relationships usually, it is an association between actors and use cases
 It is represented by directional or non-directional edges
 It may be annotated by stereotypes
 Relationships may relate:
two use cases
two actors, or
use case and an actor
 Relationships among actors and use cases enable the developers and users
to reduce the complexity of the model and increase its understandability.
42
 To describe the system in layers of functionality.
 4. Identifying Relationships-------
 Extend relationships separates exceptional and common flows of events.
 Include relationships reduces redundancy among use cases.
 Communication relationships between actors and use cases represent the flow
of information during the use case
A. Association
 Actors may be connected to use cases by associations, indicating that the actor
and the use case communicate with one another using messages.
 It denoted as solid lines or paths.
Arrowheads may be used to indicate who initiates communication in the
interaction. 43
 4. Identifying Relationships-------

Fig: shows relationships between actors and use cases

B. Includes
The included use case never stands alone. It only occurs as a part of some
larger base that includes.
 It indicates that the base use case will contain the inclusion use case. 44
 4. Identifying Relationships-------
 The base use case explicitly incorporates the behavior of another use case at a
location specified in the base..
It is denoted as dashed lines with an open arrow-head pointing at the inclusion
use case and are labelled with the <<include>> keyword (stereotype).
 The include relationship – shows a standard use case linked to a mandatory
use case.
 Standard use case can not execute without the include case, tight coupling
Example:
 To Authorize Car Loan (standard use case), a Clerk must run Check Client’s
Credit History (include use case). 45
 4. Identifying Relationships-------
 The standard UC includes the mandatory UC (use the verb to figure direction
arrow).
Let’s see the following figure to show the included use case includes the base
use case

Fig: shows the relationships between use cases (include relationship) 46

 4. Identifying Relationships-------
C. Extends
The base use case implicitly incorporates the behavior of another use case at
certain points called extension points.
 The base use case may stand alone, but under certain conditions its behavior may
be extended by the behavior of another use case.
 Enables to model optional behavior or branching under conditions
It is denoted as dashed lines or paths with an open arrow-head pointing an
extension use case and are labelled with the <<extend>> keyword (stereotype).
 Extend relationship – is used to show linking an optional use case to a standard
use case. 47
 4. Identifying Relationships-------

Example:
 The optional UC (Exam-Copy Request) extends the standard
UC (Exam-grade Appeal) shown in the diagram below.
Standard use case can execute without the extend case loose
coupling.

48
 4. Identifying Relationships-------
D. Generalization
The child use case inherits the behavior and meaning of the parent use case.
 The child may add to or override the behavior of its parent.
 Denoted as solid lines or paths with a hollow arrow-head pointing at the parent
use case

49
 Sample example to Identify Use Cases
 Based on the following scenario identify actors, use cases, relationships and draw use
case diagram
Scenario-2
 A private University Registration system requires students and the registrar to carry on
the regular Class Registration procedure. In certain cases, like Registration for a special
class, the student has to get the Instructor’s approval, or when registering for a course
that the student has not completed its prerequisites, he (the student) has to get the Dept.
Chairman’s approval. The Registrar prints a final schedule to the student. To pay for his
tuition fees, tuition invoices are mailed to the student from the Billing Dept. of the
University. 50
 Sample example to Identify Use Cases
1. Identify list of Actors.
 STUDENT
 REGISTRAR
 INSTRUCTOR
 DEPT. CHAIRMAN
 BILLING DEPT
2. Identify list of Use Cases.
 RegisterRegularCourse
 RegisterSpecialClass
 RegisterWithoutPrerequisite 51
 Sample example to Identify Use Cases
 PrintSchedule
 BillStudent
3. Enumerate and list the relations between Use-cases.
a. <<extends> between the two use cases:
 RegisterRegularCourse and RegisterSpecialClass
b. <<extends> between the two use cases:
 RegisterSpecialClass, and
 RegisterWithoutPrerequisite
4. Draw a Use case Diagram.
There are five actors and five Use-cases. 52
 5. Identifying Non-functional Requirements:
Developers, users, and clients agree on aspects that are visible to the
user but not directly related to functionality.
These include constraints on the performance of the system, its
documentation, the resources it consumes, its security, and its
quality.

53
 2.2. Requirements Analysis
 Requirement elicitation is a process that involves gathering, researching,
defining, documenting, and clarifying the requirements of a system/product.
 Note: It needs revision for Instructor
Requirement Elicitation is followed by requirement analysis to verify and ensure
the tasks performed during elicitation.
 Requirements Analysis, is a process of determining whether the stated
requirements are clear, complete, consistent and unambiguous.
 Requirement analysis is a software engineering process performed in order to
ensure clarity, completeness, and relevance of the requirements of the
system/software. 54
 Requirements Analysis process
1. Stakeholder Identification
 Stakeholders are people or organizations that have a valid interest in the
system.
 They may be affected by it directly or indirectly.
Stake holders may include:
 Anyone who operates the system
 Anyone who benefits from the system
 Anyone involved in purchasing or procuring the system
 People opposed to the system (negative stakeholders)
55
 Requirements Analysis process-----
1.1 Stakeholder Interviews
 Interviews are a common technique used in requirement analysis.
 This technique can serve as a means of obtaining the highly focused knowledge
from different stakeholders perspectives
2. Identify Types of Requirements:
A. Customer Requirements:
 Operational distribution or deployment:
Where will the system be used?
 Mission profile or scenario:
How will the system accomplish its mission objective? 56
 Requirements Analysis process-----
 Performance and related parameters:
What are the critical system parameters to accomplish the mission?
 Utilization environments:
How are the various system components to be used?
 Effectiveness requirements:
How effective or efficient must the system be in performing its mission?
 Operational life cycle:
How long will the system be in use by the user?
 Environment:
What environments will the system be expected to operate in an effective
57
 Requirements Analysis process-----
B. Architectural Requirements:
 A formal description and representation of a system, organized in a
way that support reasoning about the structure of the system which
comprises system components,
 The externally visible properties of those components, the
relationships and the behavior between them, and provides a plan
from which products can be procured and systems developed, that
will work together to implement the overall system
58
 Requirements Analysis process-----
C. Functional Requirements:
 Defines functions of a software system or its components.
 They may be calculations, technical details, data manipulation and processing
and other specific functionality that define “what a system is supposed to
accomplish?”
 They describe particular results of a system.
 Functional requirements are supported by Non-functional requirements.

D. Non-Functional Requirements:
 They are requirements that specify criteria that can be used to judge the
59
operation of a system, rather than specific behavior.
 Requirements Analysis process-----
 Functional requirements define what the system is supposed to do,
whereas non-functional requirements define how a system is
supposed to be.
 Non-functional requirements can be divided into two main
categories:
 Execution qualities, such as security and usability, which are
observable at runtime.
 Evolution qualities, such as testability, maintainability and
60
 Requirements Analysis process-----

Example: A Library Management System should be designed.

Information on books, CDs, DVDs, Journals, etc. can be stored and
retrieved. Problem statement

 Possible Requirements: Functional Req.

 Searching by Title, Author, and/or ISDN should be possible

Implementation req.
 User Interface should be web-based (accessible via WWW Browser)
 At least 20 transactions per seconds should be possible Performance req.

 All services should be available within 10 minutes Availability req.

 Users have no access to personal data of other users

Security req. 61
 3. Requirements Specifications
 Requirements Specification is the direct result of a requirement analysis and
can refer to:
Software Requirements Specification
Hardware Requirements Specification
 A Software Requirements Specification (SRS) –is a complete description of
the behavior of a system to be developed.
 It includes a set of use cases that describe all the interactions the users will have
with the software.
 In addition to use cases, the SRS also contains non-functional requirements
(such as performance requirements, quality standards, or design constraints)
62
 3. Requirements Specifications-------

A Software Requirements Specification (SRS)

 The software requirement specification document enlists all necessary
requirements for project development.
 To derive the requirements we need to have clear and thorough
understanding of the products to be developed.
A general organization of an SRS is as follows:
 Introduction
Purpose, Scope, Definitions, System Overview, References
63
 3. Requirements Specifications-------

 Overall Description
Product Perspective, Product functions, User characteristics,
constraints, assumptions and dependencies.
 Specific Requirements
 External Interface requirements, functional requirements,
performance requirements, design constraints, logical database
requirement, software system attributes.

64
 4. Requirements Validation and Verification

 Validation (& Verification), is the process of checking whether the

requirements, as identified, do not contradict the expectations about the
system of various stakeholders and do not contradict each other.
 It is Requirements Quality Control

65
 Validation Vs. Verification

 Validation: “Am I building the right product?” checking a work product

against higher-level work products or authorities that frame this
particular product.
Requirements are validated by stakeholders
 Verification: “Am I building the product right?” checking a work
product against some standards and conditions imposed on this type of
product and the process of its development.
Requirements are verified by the analysts mainly
66
 5. Requirements Management

 Requirements management is the process of managing changing

requirements during the requirements engineering process and system
development
 Requirements are inevitably incomplete and inconsistent
New requirements emerge during the process as business needs change and a
better understanding of the system is developed
Different viewpoints have different requirements and these are often
contradictory
69
 5. Requirements Management-----

 It is a set of activities that help project team to identify, control, and

track requirements and changes as project proceeds
 Requirements begin with identification.
 Each requirement is assigned a unique identifier.
 Once requirement have been identified, traceability table are
developed.
 Traceability Table:
 Features traceability table - shows how requirements relate to
70
 5. Requirements Management-----

 Source traceability table - identifies source of each requirement

 Dependency traceability table - indicate relations among
requirements
 Subsystem traceability table - requirements categorized by
subsystem
 Interface traceability table - shows requirement relations to internal
and external interfaces
 It will help to track, if change in one requirement will affect different
71