Fundamental of Software Engineering

Chapter Three
Requirement Engineering

Department of Software Engineering

WCU

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
 Characteristics of a Good Requirement
⚫ Clear and Unambiguous
⚫ standard structure
⚫ has only one possible interpretation
⚫ Correct
⚫ A requirement contributes to a real need
⚫ Understandable
⚫ A reader can easily understand the meaning of the requirement
⚫ Verifiable
⚫ A requirement can be tested
⚫ Complete
⚫ Consistent
⚫ Traceable
3
The Requirement Engineering Process
⚫ RE process is the process of gathering the software requirements (from
clients and end users) , analyze and document them.

⚫ 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

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

⚫ And prototyping
8
Requirements Elicitation activities:
1. Identifying actors.
Actor: represent external entities that interact with the system.
• An actor can be human or an external system.
• During this activity, developers identify the different types of users
the future system will support.
When Identifying actors developers should prepare the following
questions:
▪ Which user groups are supported by the system to perform their work?

▪ Which user groups execute the system main function?

▪ Which user groups perform secondary functions, such as maintenance

and administration?
▪ With what external HW and SW the system will interact?
9
Requirements Elicitation activities:
2. Identifying scenarios.
• Scenario: is narrative description of what people do
and experience as they try to use the applications.
• 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

9
 3. Identifying use cases:
• Use case: set of all use cases that demonstrates the complete
functionality (overview) of the system and is an abstraction of scenario.

• Developers derive from the scenarios a set of use cases that completely
represent the future system.

⚫ use cases are abstractions describing all possible cases.

⚫ Use case is:

❖ f low events on the system

❖ Include interaction with actors

❖ It is initiated by actor

❖ Each use case has a name

❖ Each use case has termination condition

❖ It graphical notation is: oval 10

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 (detail description of use
case).

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

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

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

15
Use cases for the MHC-PMS

16
 Problems of Requirements Elicitation
⚫ Stakeholders don’t know what they really want.

⚫ Stakeholders express requirements in their own terms.

⚫ Different stakeholders may have conf licting 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 is 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
 III- Functional Requirements
➢ Describe functionality or system services.

➢ Depend on the type of software, expected users and the type of

system where the software is used.

➢ Functional user requirements may be high-level

statements of what the system should do.

➢ Functional system requirements should describe the system

services in detail.

➢ Essentially, these are the ‘whats’ of the system that we often refer
to. These are not ‘all that there is,’ but these should describe the
overall functionality ofChapter
the system.
4 Requirements engineering 23
 IV. Non-functional Requirements
➢ These define system properties and constraints e.g.
reliability, response time, maintainability, scalability,
portability, and storage requirements.
➢ Constraints are I/O device capability, system
representations, etc.
➢ Process requirements may also be specified mandating a
particular IDE, programming language or development
method.
➢ (Often internal to an organization or required for fit /
compatibility with other comparable systems.)
➢ Non-functional requirements may be more critical than
functional requirements. If these are not met, the system may
be useless.
Chapter 4 Requirements engineering 24
Functional Vs Non-Functional

25
 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. 26
 Requirements Specifications
⚫ Requirements Specification is the direct result of a
requirement analysis and can refer to:
⚫ Software Requirements Specification

⚫ Hardware Requirements Specification

27
 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)

28
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

30
 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

31
 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
34
 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.
35
 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

36
 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 state chart and sequence diagrams.

Fig. The System/analysis model is composed of the functional model, the

object model, and the dynamic model.
37
 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

38
Use case Diagram

39
Sequence Diagram

40
 Cont.…
Collaboration Diagram
⚫ Collaboration diagram describes how the objects of the
systems communicate with each other when the system
executes.

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

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

41
Collaboration diagram

42
Class Diagram

43
 Cont..
Activity Diagram
⚫ Flowchart to represent the flow control among
activities in a system.
⚫ 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.
44
Activity Diagram

45
 Cont.…
State chart diagram
⚫ Describes the life cycle of objects using a finite state of
machine.

⚫ This 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.

46
State Diagram

47
 Component Diagram
⚫ Used to demonstrate relationships between components among the
systems.

⚫ A component diagram is used to break down a large object- oriented

system into the smaller components, so as to make them more
manageable. It models the physical view of a system such as
executables, files, libraries, etc. that resides within the node.

⚫ A component is a single unit of the system, which is replaceable and

executable. The implementation details of a component are hidden

⚫ It is used to depict the functionality and behavior of all the

components present in the system

48
Component Diagram

49
 Deployment Diagram
• Describes system hardware, software and network
connections for distributed computing.

• We deal with how those components can be

implemented on different physical device.

• It covers server configuration and network

connections between server nodes in real-world
setting.

50
Deployment Diagram

51
 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

52
Use case

53
 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)

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

UC3: AddUser

Landlord
UC4: RemoveUser

UC8: Login

UC5: InspectAccessHistory

Tenant UC6: SetDevicePrefs

55
Use Case Generalizations UC1: Unlock
UC2: Lock
UC3: AddUser

⚫ More abstract representations can be derived

UC4: RemoveUser
UC5: InspectAccessHistory
UC6: SetDevicePrefs

from particular representations UC7: AuthenticateUser

UC8: Login

Authorized Person
UC9: ManageUsers

Tenant Landlord UC3: AddUser UC4: RemoveUser

Actor Generalization Use Case Generalization

56
 Optional Use Cases: «extend»
Example optional use cases:
UC5: InspectAccessHistory

ManageAccount

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. ]
57
Login Use Case?

BAD: GOOD:

Login

AddUser
AddUser
Login
Landlord
SetDevicePrefs Landlord SetDevicePrefs

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

59
Thank You!
Q?

60
 Assignment-1(10 %)
Choose one of the problem and Select the best process
model and justify your answer
1. Developing online payment system for online sale and deliver of items but before
deployment the system should be tested by end users.
2. Sami event organizer company need to Develop event notification system and the
company does not know full features of the system
3. develop a mobile application with in two day for application development
competition
4. Assume you develop ERP software that contain human resource, finance, purchasing
and store management system but the company need to implement and work
purchasing system within three months and other system will continue like this.
5. Assume you are requested to develop airplane flight assistance and management
software
6. WCU need to develop store management within six months and store manager and
store keeper must participate on the development process

61