Software Engineering

Instructor: Mohammed Oumer[M.Sc.]

momoumer2014@gmail.com
Samara University
 Chapter Three: RE
This Chapter Covers:
 Overview of Requirement elicitation
 Requirements elicitation concepts
 Requirements elicitation activities
 Managing requirements elicitation
 Overview of Requirement Elicitation
Requirements elicitation and analysis involves:-
First collecting as many potential requirements as
possible.
 Then refining them to form a complete, concise and
consistent set of high-quality functional and non-functional
requirements.
 Then analyzing them to start forming a preliminary (the
initial) model.
Functional requirements are often modeled with the aid
of use-cases and scenarios, while the analysis step starts to
identify some of the candidate objects / classes that will be
needed in the system.
 Requirements Elicitation Concepts
Functional requirements
 Describe what the system should do.
 They can often be derived from "stories" about how the
system will be used, which may be in the form of
scenarios, use-cases, or just a simple description of
operations.
 What inputs the system should accept.
 What outputs the system should produce.
 What data the system should store that other systems
might use.
 What computations (process) the system should perform.
 Non functional Requirements
Nonfunctional requirements are properties (entity) or
characteristics (attributes) that the system must have, other
than its basic functionality.
 Performance requirements
 Usability – the degree of easy with w/c products such as
SW can be used to achieve required goals effectively and
efficiently.
 Reliability – is the probability of failure-free SW operation
for a specified period of time in a specified environment.
 Performance – an indicator of how well a SW system or
component meets its requirements for timeliness.
(timeliness – is measured in terms of response time),
response time is the time required to respond to a request.
 Requirements Validation
Requirements validation is a quality assurance step,
usually performed after requirements elicitation or after
analysis.
- Completeness: All possible scenarios, in which the system
can be used are described.
- Consistency: No requirements that contradict each other.
- Clarity: Requirements can only be interpreted in one way.
- Correctness : The requirements represent the client’s
view.
- Realism: Is the requirement reasonably attainable?
Requirements can be implemented and delivered.
 Requirements Validation

- Traceability : Each system behavior can be traced (find)

to a set of functional requirements.

- Verifiable / Measurable / Testable : requirements

must also be specific.
 Different Types of Req`s Elicitation
Greenfield Engineering
• Development starts from scratch, no prior system
exists, requirements come from end users and clients.
• Triggered by user needs.
Re-engineering
• Re-design and/or re-implementation of an existing
system using newer technology.
• Triggered by technology enabler.
Interface Engineering
• Provision of existing services in a new environment.
• Triggered by technology enabler or new market needs.
 Requirements Elicitation Activities

What is an Actor?

A role that a user plays with respect to the system, including

human users and other systems. e.g., inanimate physical
objects (e.g. robot).

Include all user roles that interact with the system.

Include system components only if they responsible for

initiating/triggering a use case.
 ATM Stakeholders
Stackholders – defined as an individual or group that has an
interest in any decision or activity of an organization.
 Bank customers – Someone who access bank.
 Bank managers – A person who directs the business.
 Database administrators – The information technician
responsible for directing or performing all activities
related to bank.
 Security staff – A team whose job is to protect money.
 HW and SW maintenance engineers – Fixing bugs and
errors related to SW and HW devices.
 Banking regulators – provide charters (written
document) to banks operating.
 Viewpoints
Viewpoints are a way of structuring (organizing) the
requirements to represent the perspectives of different
stakeholders. Stakeholders may be classified under different
viewpoints.

This multi-perspective analysis is important as there is no

single correct way to analyze system requirements.
 Types of viewpoint
Interactor viewpoints
People or other systems that interact directly with the
system. In an ATM, the customer’s and the account
database are interactor VPs.
Indirect viewpoints
Stakeholders who do not use the system themselves but
who influence the requirements. In an ATM, management
and security staff are indirect viewpoints.
Domain viewpoints
Domain characteristics and constraints that influence the
requirements. In an ATM, an example would be standards
for inter-bank communications (relating to transaction or
communication between banks).
 Viewpoint Identification
 Identify viewpoints using :-
Providers and receivers of system services.

Systems that interact directly with the system being

specified.

Regulations and standards.

Engineers who have to develop and maintain the system.

 Order of Steps when Formulating US
First step: name the use case with verb phrase.

 Use case name: Deposit money

Second step: Find the actors.

 Participating Actors: Branch officer etc…

Third step: Then concentrate on the flow of events.

 Use informal natural language.

 Use case Description
Use case name: Deposit money
Use case ID: UC6
Actor: Branch officer
Description: is activated (switch on) when the customer
wants to deposit money.
Pre-condition: user must be login to the system and the
customer should have an account.
Basic flow of events:
1. The branch officer chooses the core banking link.
2. Then the branch officer chooses the deposit link.
3. fill the deposit form.
4. Click on deposit button.
 Cont.
5. The system verifies that the deposit form was filled
correctly.
6. The system displays ” successfully deposited
notification”.
7. Use case ends.
Alternative flow: A system unable to deposit money.
A-5. The system verified that the user filled the
information incorrectly.
A-6. The system displays an error message that shows
the user filled the form incorrectly.
A-7. Use case resume from step 3 of main flow of events.
Post condition: The system displays “successfully
message” and update the customer’s account balance.
 Managing Requirements Elicitation
Requirements management is the process of managing
changing requirements during the requirements
engineering process and system development.

Requirements are inevitably (can not be avoided)

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.
 Requirements Change Management
Should apply to all proposed changes to the requirements.

Principal stages :-

 Problem analysis. Discuss requirements problem and

propose change.

 Change analysis and costing. Assess (evaluate) effects

of change on other requirements.

 Change implementation. Modify requirements

document and other documents to reflect change.
 Documenting Req`s Elicitation
The results of the requirements elicitation activity and
the analysis activity are documented in the Requirements
Analysis Document (RAD).
This document completely describes the system in terms of
functional and nonfunctional requirements and serves as a
contractual basis between the client and the developers.
The audience for the RAD includes the client, the users, the
project management, the system analysts.
The first part of the document, including use cases and
nonfunctional requirements, is written during requirements
elicitation.
Thank You ...