Fundamental of Software Engineering

Chapter Three
Requirement Engineering

School of Electrical Engineering and

Computing
Department of computer Science and
Engineering
ASTU
September 9, 2025 1
 Software Requirements
Requirements are descriptions of the services
that a software system must provide and the
constraints under which it must operate.
RE: is the process of defining, documenting
and maintaining the requirements. It is a
process of gathering and defining service
provided by the system.
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 may serve a dual function: 2
The Requirement Engineering
Process
Requirements engineering help 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

 Feasibility Study
 Requirements elicitation and analysis
 Requirements Specification
 Requirements Validation

4
The Requirements Engineering
Process
Require ments
Feasibility
elicitation and
study
analy sis
Require ments
specification

Feasibility Require ments

report validation

System
models
User and system
requirements

Require ments
document

5
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.
Feasibility Study Implementation
Based on information assessment (what is
required), information collection and report
writing.
Questions for 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?
Requirements Elicitation
It is the practice of obtaining the requirements of a
system from users, customers and other stakeholders.
The practice is also sometimes referred to as
Requirement gathering.

Requirements elicitation methods include the

following:
 Interviews
 Questionnaires
 User observation
 Workshops
 Brain storming
 Use cases
 Role playing
 And prototyping

8
Requirements Elicitation activities:
1. Identifying actors. During this activity,
developers identify the different types of users
the future system will support.
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,
3. Identifying use cases: developers derive from
the scenarios a set of use cases that completely
represent the future system.
cases are abstractions describing all possible
 use

cases.
9
Cont…
[Link] use cases: developers ensure that the
system specification is complete, by detailing
each use case and describing the behavior of the
system in the presence of errors and exceptional
conditions.
[Link] relationships among use cases:
developers consolidate the use case model by
eliminating redundancies. This ensures that the
system specification is consistent.
[Link] nonfunctional 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 10
Scenarios
Scenarios are real-life examples of how a
system can be used.
They should include
A description of the starting situation;
A description of the normal flow of events;
What can go wrong and how this is handled
Information about other concurrent activities;
A description of the state when the scenario
finishes.

11
Example 1:
Scenario for collecting medical history in MHC-PMS

12
Scenario for collecting medical history
in MHC-PMS

13
Use cases
A scenario-based technique in UML which
identify the actors in an interaction and
which describe the interaction itself.
Used also to clarify the system boundaries.
A set of use cases should describe all possible
interactions with the system.
Sequence diagrams show the interactions
and event processing inside a use case.

14
Use cases for the MHC-PMS

15
Problems of requirements elicitation
Stakeholders don’t know what they really want.
Stakeholders express requirements in their own
terms.
Different stakeholders may have conflicting
requirements.
Organisational and political factors may influence
the system requirements.
The requirements change during the analysis
process. New stakeholders may emerge and the
business environment change.

17
Requirements Analysis
Requirements Analysis, determining whether
the stated requirements are clear, complete,
consistent and unambiguous.

18
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)
 Organizations responsible for the system
19
2. Identify Types of Requirements:
I. Customer Requirements:
a) Operational distribution or deployment: Where will the
system be used?
b) Mission profile or scenario: How will the system
accomplish its mission objective?
c) Performance and related parameters: What are the
critical system parameters to accomplish the mission?
d) Utilization environments: how are the various system
components to be used?
e) Effectiveness requirements: How effective or efficient
must the system be in performing its mission?
f) Operational life cycle: How long will the system be in
use by the user?
g) Environment: what environments will the system be
expected to operate in an effective manner?

21
Cont..
II. 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.

22
Cont..
III. 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.

23
Cont..
IV. Non-Functional Requirements:
 They are requirements that specify criteria that can be
used to judge the operation of a system, rather than
specific behavior.
 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

scalability.

24
 Cont…
Example: Problem statement

Idea: A Library Management System should

be designed. Information on books, CDs,
DVDs, Journals, etc. can be stored and
retrieved. Functional Req.
 Possible Requirements:
Searching by Title, Author, and/or ISDN should be
possible Implementation req.
User Interface should be web-based (accessible via
WWW Browser) Performance req.
At least 20 transactions per seconds should be
Availability req.
possible
All services should be available within 10 minutes
Security req. 25
Requirements Specifications
Requirements Specification is the direct
result of a requirement analysis and can refer
to:
Software Requirements Specification
Hardware Requirements Specification

26
Requirements Specifications
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)

27
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

29
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 30
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
33
Requirement Management
 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
customer observable features
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
aspects of the system.

34
System

models
Different models may be produced during
the requirements analysis activity
Requirements analysis may involve three
structuring activities which result in these
different models
 Partitioning. Identifies the structural (part-of)
relationships between entities
 Abstraction. Identifies generalities among
entities
 Projection. Identifies different ways of looking at
a problem

35
Cont…
The System/analysis model is composed of three
individual models:
1. Functional model , represented by use cases and scenarios
2. Analysis object model , represented by class and object
diagrams
3. Dynamic model , represented by statechart and sequence
diagrams.

Fig. The System/analysis model is composed of the 36

Cont.
Use case diagram
Derived from use-case study scenarios. It is an
overview of use cases, actors, and their
communication relationships to demonstrate
how the system reacts to requests from external
users. It is used to capture system requirements.
Sequence diagram
Describes time sequence of messages passed
among objects in a timeline

37
Use case Diagram

38
Quiz
1. Developing a new version of a mobile operating
system.
2. CSE department prepare simple mobile
application development contest between ASTU and
AASTU students, the department prepare the
requirement of the Application and students are
expected to complete the application based on
requirement within a two days.
3. Assume you are the owner of the a given company
and you need to develop new large system but to get
acceptance from the customers you should release
some features of the system to the market .
4. When you are requested to develop a new system
which its requirement is not clear at the beginning of
the project but you will get the requirement through 39
Quiz
Ethiopian football federation has a plan to automate
Ethiopian premier league Management system which is
expected to automate major premier league activities. Some
of Major activates are registrations of (clubs, referees,
players, matches, stadiums, schedule, results, punishment
and users), announcement for a (meeting, decisions and
schedule ), sending letters to clubs, displayed live match
result through scoreboard, calculate rank using(points, goal
deposit), identify top goal scorer player based on the
registered data, send a text message for club administrator
Mobile-phone and email if there is any urgent issues. Sport
clubs update information about club, player and staff
information on the system.
 Ethiopian premier league officers are responsible for all
primer leagues activities in the system. Clubs
Funs/Supporters participate on prediction of the next
match and view the premier league information. The
system also sends information to the Ethiopian premier 40
Quiz
5. Identify Participating actors?
6. Identify
Functional requirement?
Non Functional requirement?

7. Draw usecase diagram of the system and

describe the relationship between use
cases?

41
Sequence diagram
 In software engineering, a sequence diagram is a type of interaction
diagram that illustrates the flow of messages and interactions between
different objects or components within a system.
 It depicts the dynamic behavior of a system by showing the sequence of
actions and the order in which they occur.
 A sequence diagram is a type of interaction diagram because it describes
how—and in what order—a group of objects works together.
 Here are some key elements and concepts related to sequence diagrams:
1. Objects: Objects represent the various components or entities within the
system. Each object is depicted as a vertical lifeline, which represents its
existence over time.
2. Lifelines: Lifelines are the vertical lines that represent the objects involved
in the sequence diagram. They show the lifespan of an object and the
duration of its participation in the interactions.
3. Messages: Messages represent the communication or interaction between
objects.
4. Activation: Activation bars or activation boxes represent the time period
during which an object is actively processing a message.
5. Control Flow: The control flow in a sequence diagram is represented by
the order in which messages are exchanged between objects.
6. Return Messages: Return messages are used to depict the response or
return value from a method or operation.
42
Sequence Diagram

43
Cont.…
Collaboration Diagram
Describes the sequence of message passing among
objects in the system. Equivalent to sequence
diagram , except that it focuses on the objects role.
Each communication link is associated with a
sequence order number plus the passed messages.
type of interaction diagram that illustrates the
interactions and relationships between objects or
components within a system.
Here are some key elements and concepts related
to collaboration diagrams:

44
Cont.…
1. Objects/actors : Objects represent the various
components or entities within the system. Each object is
depicted as a rectangular box, labeled with its name and
class or type.
2. Links: Links represent the relationships or associations
between objects. Links can be simple associations,
aggregations, compositions, or other types of
relationships.
3. Messages: Messages represent the communication or
interaction between objects. They are depicted as arrows
that flow between the objects.
4. Lifelines: Lifelines are not explicitly shown in
collaboration diagrams.

45
Collaboration diagram

46
Class

Diagram
In software engineering, a class diagram is a type of static
structure diagram that represents the structure and
relationships of classes, interfaces, and their associations
within a system.
 It provides a visual representation of the classes and their
attributes, methods, and relationships.
 Here are some key elements and concepts related to class
diagrams:
 1. Classes: Classes represent the blueprint or template for
creating objects. They define the properties (attributes)
and behaviors (methods) of objects. Each class is depicted
as a rectangle, divided into three compartments: the class
name, attributes, and methods.
 2. Associations: Associations represent the relationships
between classes. They show how classes are connected or
related to each other. Associations can be one-to-one, one-
to-many, or many-to-many.
 3. Inheritance: Inheritance represents the "is-a"47
Class

Diagram
4. Aggregation and Composition: Aggregation and
composition represent the "has-a" relationship between
classes. Aggregation is a weaker form of association, where
one class contains or owns another class, but the contained
class can exist independently.
 5. Multiplicity: Multiplicity indicates the number of
instances that can participate in a relationship. It specifies
the cardinality or range of the association between classes.
Multiplicity is represented using numbers or symbols near
the ends of the association lines.

48
Class Diagram

49
Cont.
Activity Diagram
 An activity is an action for a system
operation or a business process, such as
those outlined in the use-case diagram.
It also covers decision points and threads of
complex operation processes.
It describes how activities are orchestrated
to achieve the required functionality.
It provides a visual representation of the
sequential and parallel activities, decision
points, and the flow of control between them.

50
Cont.
Here are some key elements and concepts related to activity
diagrams:
1. Activities: Activities represent the tasks or actions that are
performed within the system. They can be simple actions, such as
calculations or data processing, or complex processes involving
multiple steps. Each activity is depicted as a rounded rectangle with a
label describing the action.

2. Control Flow: Control flow represents the sequence of activities and

the order in which they are performed. It shows the flow of control
from one activity to another. Control flow is depicted using arrows
that connect the activities, indicating the direction of the flow.
3. Decision Nodes: Decision nodes represent decision points or
branching in the flow of activities. They are used to model conditions
or choices that determine the next activity to be executed. Decision
nodes are depicted as diamonds, with arrows representing the
different possible paths based on the conditions.
4. Initial and Final Nodes: Initial nodes represent the starting point
of the activity diagram, indicating where the flow of activities begins.
Final nodes represent the ending point of the activity diagram

51
Activity Diagram

52
Cont.…
State chart diagram
 The diagram consists of states and the transitions between
states. Transitions are usually caused by external stimuli or
events. They can also represent internal moves by the
object.
 a type of behavior diagram that represents the different
states and transitions of an object or system.
 It provides a visual representation of how an object or
system responds to events and changes its state over time.
Here are some key elements and concepts related to state
chart diagrams:
 1. States: States represent the different conditions or

modes that an object or system can be in. Each state

represents a specific behavior or set of conditions. States
are depicted as rounded rectangles with labels describing
the state.
 2. Transitions: Transitions represent the change from one
state to another in response to an event or condition. They
53
Cont.…
3. Events: Events represent the occurrences or
stimuli that trigger a transition from one state
to another. They can be internal events, such
as a timer or a condition within the system.
4. Actions: Actions represent the activities or
behaviors that are performed when a
transition occurs. They specify what happens
when the system or object moves from one
state to another.
5. Initial and Final States: Initial states
represent the starting point of the state chart
diagram, indicating the initial state of the
system or object. Final states represent the
ending point of the state chart diagram

54
State Diagram

55
Component

Diagram
component diagram is a type of structural diagram that
represents the physical or logical components of a system
and their relationships.
 It provides a visual representation of the high-level
structure and organization of a software system, showing
how different components interact and collaborate to
achieve the system's functionality.
 It models the physical view of a system such as
executables, files, libraries, etc. that resides within the
node.
 It visualizes the relationships as well as the organization
between the components present in the system.
 It helps in forming an executable system. A component is a
single unit of the system, which is replaceable and
executable.

56
Component Diagram
Here are some key elements and concepts related to component
diagrams:
1. Components: Components represent the modular and reusable
parts of a system that encapsulate specific functionality. They can be
software modules, libraries, classes, or even physical devices. Each
component is depicted as a rectangle with a label describing its
name.
2. Interfaces: Interfaces define the contract or set of operations that
a component provides or requires. They specify how components
interact with each other and communicate. Interfaces are depicted
as labeled connectors between components, indicating the required
or provided functionality.
3. Relationships: Relationships represent the associations and
dependencies between components. They show how components
depend on each other or collaborate to achieve the system's
functionality. Relationships can be depicted using various types of
connectors, such as dependency, association, or aggregation.

4. Ports: Ports represent the connection points or interfaces through

which components interact with each other or with the external57
Component Diagram

58
Cont.
Deployment Diagram
Describes system hardware, software, and
network connections for distributed
computing.
It covers server configuration and network
connections between server nodes in real-
world setting.
The deployment diagram visualizes the
physical hardware on which the software will
be deployed.
59
Deployment Diagram

60
Use Cases
Used for Functional Requirements Analysis
and Specification
A use case is a step-by-step description of
how a user will use the system-to-be to
accomplish business goals
Detailed use cases are usually written as usage
scenarios or scripts, showing an envisioned sequence
of actions and interactions between the external actors
and the system-to-be

61
Usecase

62
 Deriving Use Cases from System Requirements
REQ1: Keep door locked and auto-lock 1
2
REQ2: Lock when “LOCK” pressed 3
REQ3: Unlock when valid key provided 4
REQ4: Allow mistakes but prevent dictionary attacks 5
X
REQ5: Maintain a history log Y
REQ6: Adding/removing users at runtime
REQ7: Configuring the device activation preferences
REQ8: Inspecting the access history
REQ9: Filing inquiries

Actor’s Goal (what the actor intends to

Actor Use Case Name
accomplish)
Landlord To disarm the lock and enter, and get space lighted up. Unlock (UC-1)
Landlord To lock the door & shut the lights (sometimes?). Lock (UC-2)
To create a new user account and allow access to
Landlord AddUser (UC-3)
home.
Landlord To retire an existing user account and disable access. RemoveUser (UC-4)
To find out who accessed the home in a given interval InspectAccessHistory
Tenant
of time and potentially file complaints. (UC-5)
Tenant To disarm the lock and enter, and get space lighted up. Unlock (UC-1)
Tenant To lock the door & shut the lights (sometimes?). Lock (UC-2)
Tenant To configure the device activation preferences. SetDevicePrefs (UC-6)
LockDevice To control the physical lock mechanism. UC-1, UC-2
LightSwitch To control the lightbulb. UC-1, UC-2
[to be To auto-lock the door if it is left unlocked for a given
AutoLock (UC-2)
identified] interval of time.
( Actors already given if working from user stories instead of system requirements63)
Types of Actors
Initiating actor (also called primary actor or
simply “user”): initiates the use case to achieve
a goal
Participating actor (also called secondary
actor): participates in the use case but does not
initiate it. Subtypes of participating actors:
Supporting actor: helps the system-to-be to complete
the use case
Offstage actor: passively participates in the use case,
i.e., neither initiates nor helps complete the use case, but
may be notified about some aspect of it (e.g., for keeping
records)
64
Use Case Diagram: Device Control UC1: Unlock
UC2: Lock
UC3: AddUser
UC4: RemoveUser
UC5: InspectAccessHistory
UC6: SetDevicePrefs
UC7: AuthenticateUser
UC8: Login

system
boundary First tier use cases Second tier use cases

ude» UC7: AuthenticateUser

actor «incl
«participate»
«initiate» »
UC1: Unlock t ic i pate
r
«pa
«in
i «particip LockDevice
t ia ate»
te»
Tenant
ate»
e» «particip
i t iat
«in
«pa LightSwitch
rtici
«initiate» UC2: Lock pate
»
«initiate + participate»
communication use case
Landlord Timer

65
Use Case Diagram: Account Management
UC1: Unlock
UC2: Lock
UC3: AddUser
UC4: RemoveUser
UC5: InspectAccessHistory
UC6: SetDevicePrefs
UC7: AuthenticateUser
UC8: Login

Account Management Subsystem

«initiate»
UC3: AddUser
« in
«ini c lu
tiate de
» »
Landlord »
te «inclu
a UC4: RemoveUser de»
ip
rtic
a
«p UC8: Login
de»
i nc lu
«
te»
«initia UC5: InspectAccessHistory
e»
l ud
nc
«initi
ate» «i

Tenant UC6: SetDevicePrefs

66
GUI for UC6: Set Device Pref’s
Device Preferences
File Configure Help

Activate for valid key Activate for burglary attempt

Lights Air-
Air-conditioning Alarm bell Send SMS
Music Heating Police …

Apply Close

( NOTE: Lock device is mandatory, not an option )

67
Use Case Generalizations UC1: Unlock
UC2: Lock
UC3: AddUser
UC4: RemoveUser
 More abstract representations can be derived from UC5: InspectAccessHistory
UC6: SetDevicePrefs
UC7: AuthenticateUser
particular representations UC8: Login

Authorized Person
UC9: ManageUsers

Tenant Landlord UC3: AddUser UC4: RemoveUser

Actor Generalization Use Case Generalization

68
 Optional Use Cases: «extend»
Example optional use cases:
UC5: InspectAccessHistory
»
tend
«ex

ManageAccount
«ex
tend
»
UC6: SetDevicePrefs

Key differences between «include» and «extend» relationships

Included use case Extending use case
Is this use case optional? No Yes
Is the base use case complete
without this use case? No Yes

Is the execution of this use case conditional? No Yes

Does this use case change the
behavior of the base use case? No Yes

[ Source: Robert Maksimchuk & Eric Naiburg: UML for Mere Mortals, Addison-Wesley, 2005. ]
69
Login Use Case?
BAD: GOOD:

Login
«inc
lude
AddUser »
AddUser
Login
Landlord
SetDevicePrefs Landlord SetDevicePrefs lu de»
«inc

70
Traceability Matrix Purpose
To check that all requirements are covered
by the use cases
Mapping: System requirements to Use cases

To check that none of the use cases is

introduced without a reason (i.e., created not
in response to any requirement)
To prioritize the work on use cases

71
Schema for Detailed Use Cases
Use Case UC-#: Name / Identifier [verb phrase]
Related
List of the requirements that are addressed by this use case
Requirements:
Initiating Actor: Actor who initiates interaction with the system to accomplish a goal

Actor’s Goal: Informal description of the initiating actor’s goal

Participating Actors: Actors that will help achieve the goal or need to know about the outcome

Preconditions: What is assumed about the state of the system before the interaction starts
What are the results after the goal is achieved or abandoned; i.e., what must
Postconditions: be true about the system at the time the execution of this use case is
completed
Flow of Events for Main Success Scenario:
The initiating actor delivers an action or stimulus to the system (the arrow indicates the
 1.
direction of interaction, to- or from the system)
The system’s reaction or response to the stimulus; the system can also send a message
 2.
to a participating actor, if any
 3. …
Flow of Events for Extensions (Alternate Scenarios):
What could go wrong? List the exceptions to the routine and describe how they are handled
 1a. For example, actor enters invalid data
 2a. For example, power outage, network failure, or requested data unavailable
…
72
The arrows on the left indicate the direction of interaction:  Actor’s action;  System’s reaction
Use Case 1: Unlock
Use Case UC-1: Unlock

Related REQ1, REQ3, REQ4, and REQ5 stated in the previous slides
Requirem’ts:
Initiating Actor: Any of: Tenant, Landlord
Actor’s Goal: To disarm the lock and enter, and get space lighted up automatically.
Participating LockDevice, LightSwitch, Timer
Actors:
• The set of valid keys stored in the system database is non-empty.
Preconditions: • The system displays the menu of available functions; at the door keypad the menu
choices are “Lock” and “Unlock.”
Postconditions: The auto-lock timer has started countdown from autoLockInterval.
Flow of Events for Main Success Scenario:
 1. Tenant/Landlord arrives at the door and selects the menu item “Unlock”
2. include::AuthenticateUser (UC-7)
System (a) signals to the Tenant/Landlord the lock status, e.g., “disarmed,” (b) signals to
 3. LockDevice to disarm the lock, and (c) signals to LightSwitch to turn the light on
 4. System signals to the Timer to start the auto-lock timer countdown
 5. Tenant/Landlord opens the door, enters the home [and shuts the door and locks]

73
Thank You!
Q?

74
 Quiz-1 10%
1. Consider any social media it may be
facebook , tweeter …
a. Identify actors
b. Identify usecases
c. Show the relationship between usecase
d. Draw use case diagrm

75