Fundamental of Software Engineering

CSE 3205
Chapter Three
Requirement Engineering

School of Electrical Engineering and Computing

Department of computer Science and Engineering
ASTU
Tuesday, November 23, 2021

1
 Software Requirements
Requirements are descriptions of the services that a
software system must provide and the constraints
under which it must operate
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:
As the basis of a bid for a contract
As the basis for the contract itself

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
Feasibility Requirements
stud y elicitation and
anal ysis
Requirements
specification
Feasibility Requirements
repor t validation

System
models
User and system
requirements

Requirements
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.
 use cases are abstractions describing all possible cases.

9
Cont…
4.Refining 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.
5.Identifying relationships among use cases: developers
consolidate the use case model by eliminating redundancies.
This ensures that the system specification is consistent.
6.Identifying 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 the system,
its documentation, the resources it consumes, its security,
and its quality.
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.
 Possible Requirements: Functional Req.

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

User Interface should be web-based (accessible via WWW
Browser) Implementation req.
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. 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.

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
Sequence Diagram

39
Cont.…
Collaboration Diagram
Describes the sequence of message passing among objects
in the system. Equivalent to sequence diagram , except that
it focuses on the object—s role.
Each communication link is associated with a sequence
order number plus the passed messages.
Class Diagram
Class diagrams can be derived from use-case diagrams
or from text analysis of the given problem domain.
A class diagram is generated by system analysts and
designers and will be iteratively refined in the subsequent
phases during the software development life cycle.
40
Collaboration diagram

41
Class Diagram

42
Cont.
Activity Diagram
Outline of activities— data and control flow among
related objects. 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.

43
Activity Diagram

44
Cont.…
State chart diagram
Describes the life cycle of objects using a finite state of
machine.
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.
Component diagram
It Describes all components in a system, their
interrelationships, interactions, and the interface of the
system. It is an outline of the composition structure of
components or modules 45
State Diagram

46
Component Diagram

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

48
Deployment Diagram

49
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

50
Usecase

51
 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 Actor’s Goal (what the actor intends to accomplish) Use Case Name
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)
Landlord To create a new user account and allow access to home. AddUser (UC-3)
Landlord To retire an existing user account and disable access. RemoveUser (UC-4)
To find out who accessed the home in a given interval of
Tenant InspectAccessHistory (UC-5)
time and potentially file complaints.
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 requirements52)
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)

53
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

actor lude
» UC7: AuthenticateUser
«inc
«participate»
«initiate» »
UC1: Unlock t i c i pate
« par
«in
it «particip LockDevice
iat ate»
e»
Tenant
ate»
e» «particip
it iat
«in
«pa LightSwitch
rt i c i
«initiate» UC2: Lock pate
»
«initiate + participate»
communication use case
Landlord Timer

54
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
«init clu
iate de
» »
Landlord »
te «inclu
a UC4: RemoveUser de»
ti ci p
par
« UC8: Login
de»
i nc lu
«
te» UC5: InspectAccessHistory
«initia »
ude
l
nc
«initi
ate» «i

Tenant UC6: SetDevicePrefs

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

Activate for valid key Activate for burglary attempt

Lights Air-conditioning Alarm bell Send SMS

Music Heating Police …

Apply Close

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

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

Authorized Person
UC9: ManageUsers

Tenant Landlord UC3: AddUser UC4: RemoveUser

Actor Generalization Use Case Generalization

57
 Optional Use Cases: «extend»
Example optional use cases:
UC5: InspectAccessHistory
te n d»
«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. ]
58
Login Use Case?
BAD: GOOD:

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

59
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

60
Schema for Detailed Use Cases
Use Case UC-#: Name / Identifier [verb phrase]

Related Requirements: List of the requirements that are addressed by this use case

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 be true
Postconditions:
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 to a
 2.
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
    …
   
The arrows on the left indicate the direction of interaction:  Actor’s action;  System’s reaction 61
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]

62
 Thank You!
Q?

63
 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

64