Requirement Engineering

Annibale Panichella

!1
 Roadmap

• The requirement engineering process

• Functional and non-functional requirements

• Requirements checking and reviews

• Use Case Diagrams

!2
Previously on SEM…

3
Software Development Life Cycle
SDLC is the process followed in SE for planning, designing,
developing, testing, and deploying software projects

Different SDLC models can be used.

Analysis
Analysis Design
Most of the existing models use forms
of the same five steps, but differ on
emphasis, frequency, order.

Implementation Here are a few SDLC models:

Planning • Waterfall (Wiston W. Royce, 1970)
• Spiral (Barry Bohem, 1986)
• V-model (1991)
Maintenance • Agile (2001)
• Scrum (2001)

!4
 “The hardest single part is
deciding what to build.”

F. Brooks (1987)

!5
 私は分かり What can I do
ません for you?

Software
Customer
Engineer

!6
 How many
Uhm, not players are in
sure yet! your game?

Software
Customer
Engineer

!7
Requirement Engineering Process
May user needs be satisfied using current
Feasibility
Study software and hardware technologies?
Within existing budgetary constraints?

The result should inform the decision of whether or

Feasibility
Report
not to go ahead with a more detailed analysis

!8
Requirement Engineering Process
Feasibility
Study Requirement
It is about understanding the
Elicitation &
Analysis problem

Feasibility
Report
System
Models Deriving the requirements through
observation of existing systems,
discussions with potential users and
procedures, task analysis, etc.

!9
Requirement Engineering Process
Feasibility
Study Requirement
Elicitation &
Analysis Requirement
Specification
Feasibility
Report
System
Models User and
System
Requirements

!10
Requirement Engineering Process

Requirement
It is about describing what to deliver
Specification

Translating the information gathered during the

User and
previous stages into a document that describes the set
System
of requirements (and understandable to the customer).
Requirements
User requirements are abstract statements for the
customer and end-user of the system

System requirements are a more detailed description

of the functionality to be provided

!11
Requirement Engineering Process
Feasibility
Study Requirement
Elicitation &
Analysis Requirement
Specification
Feasibility Requirement
Report Validation
System
Models User and
System
Requirement

Requirements
“Software Engineering”
Ian Sommervile (Chapter 2) Document
!12
Requirement Engineering Process

Requirement Reaching an agreement upon the nature of the

Validation problem

This activity checks the requirements for realism,

Requirements consistency, and completeness.
Document
During this process, errors in the requirements
document are inevitably discovered. The documents
must then be modified to correct these problems.

!13
Requirement Engineering Process

Determine if the user needs can be satisfied with

Feasibility Study
the available technology and budget

Requirements Understanding what the system stakeholders

Analysis require from the system

Requirements Define what the requirements are and present them

specification in a form understandable to the customer

Requirements Define the requirements in detail, written as a

validation contract between client and contractor

!14
 Requirements Analysis
In this activity, software engineers meet customers and system end-
users to find out about:
• the application domain
• what services the system should provide
• the required performance of the system
• hardware/software constraints (e.g., the software is for Windows
Platform)
•…

This activity involves system stakeholders, i.e., anyone who will interact
directly or indirectly with the system: end users, business managers,
domain experts and trade union representatives.

!15
The Process for Requirements Analysis

1 Requirements
Discovery
Requirements discovery is the
process of interacting with
stakeholders to discover their
Requirements requirements.
Requirement
Classification
Specification There are several complementary
& Organization
techniques that can be used for
requirements discovery:
• Interviewing
Requirements • Scenario-based elicitation
Prioritization & (write real-life examples, use
Negotiation cases and scenarios)

!16
The Process for Requirements Analysis

1 Requirements
Discovery

2 Requirements classification and

organization: in this step,
Requirements engineers take the unstructured
Requirement
Classification requirements and group them in
Specification
& Organization coherent clusters.

Requirements can be grouped by

functionalities, sub-systems,
Requirements
users and so on.
Prioritization &
Negotiation

!17
The Process for Requirements Analysis

1 Requirements
Discovery Requirements prioritization and
negotiation: in this stage,
2 requirements are prioritized
based on importance and time to
Requirements deliver each functionality.
Requirement
Classification
Specification
& Organization Usually, when interviewing
different stakeholders it is very
common to end up with
conflicting requirements. These
Requirements
requirements should be identified
Prioritization &
and resolved via negotiation with
Negotiation 3 the stakeholders.

!18
The Process for Requirements Analysis

1 Requirements
Discovery

2
Requirements Requirements specification: the
Requirement requirements collected in the
Classification
Specification previous stages are documented.
& Organization
The resulting report is then used
4 as input for the next round of the
spiral.
Requirements
Prioritization &
Negotiation 3

“Software Engineering”
Ian Sommervile (Chapter 4)
!19
 Common Problems
• Stakeholders don’t know what they
really want
• Stakeholders express requirements in
their own terms
• Different stakeholders may have
conflicting requirements
• Organizational and political factors may
influence the system requirements


• New stakeholders may emerge

!20
 Use Cases and Scenarios
Use cases are a requirements discovery method introduced in 1993
for Objectory method and nowadays it is the most frequently used
method to elicit requirements.

A use case is the specification of actors that interact with the

systems and the actions (and their variants) that a system can
perform
• e.g., buy a DVD through the internet

Scenario: a particular trace of action occurrences, starting from a

known initial state
• e.g., connect to mydvd.com & go to the “search” page

!21
Unified Modeling Language (UML)

Use Case Show external actors and their interactions (use

Diagrams cases) with the system under development

Sequence Visualize temporal message ordering of a concrete

Diagrams scenario of a use case

Visualize the logical structure of the system regarding

Class Diagrams classes, objects, and relationships

Specify the abstract states of an object and the

State Diagrams
transitions between the states

!22
 Use Case Diagrams

“Software Engineering”
Ian Sommervile (Figure 4.15)
!23
 Sequence Diagrams

“Software Engineering”
Ian Sommervile (Figure 5.6)
!24
Functional and Non-Functional Requirements

• Functional requirements describe what services the

system should provide and how the system should react to
particular inputs. They may also include what the system
should not do.

• Non-functional requirements are constraints on the

services or functions offered by the system. They include
timing constraints, constraints on the development
process, and constraints imposed by standards.

!25
 Functional Requirements

The functional requirements for a system describe what the system should
do:
e.g., functions, its inputs, and outputs, exceptions, etc.

Some examples:
• The user shall be able to search the appointments in its calendar.
• The system shall generate each day a list of patients who are expected to
attend appointments that day.
• Each student shall be uniquely identified by his or her eight-digit number

Functional requirements may be written at different levels of abstraction

!26
 Functional Requirements
Imprecision in the requirements specification is the cause of
many software engineering problems:
- “The system shall provide appropriate viewers for the user to read documents
in the document store” - What does “appropriate” mean?

Functional requirements specs should be complete & consistent

- Complete: all services required by the user are defined
- Consistent: Requirements should not have contradictory definitions

For large, complex system it is practically impossible to achieve

completeness and consistency
- Reason 1: It is easy to make mistakes and omissions
- Reason 2: Different stakeholders have different-often inconsistent-needs

!27
Non-Functional Requirements

Product Specify that the product must behave in a particular

requirements way e.g., execution speed, reliability

Are a consequence of organizational policies and

Organizational procedures
requirements e.g., process standards used, implementation
requirements

Arise from factors which are external to the system

External and its development process
requirements e.g., interoperability requirements, legislative
requirements

!28
Types of Non-Functional Requirements
Efficiency Performance
Requirements Requirements

Product Dependability Space

Requirements Requirements Requirements

Security
Requirements Usability
Requirements

Environmental
Non-Functional Organizational Requirements Operational
Requirements Requirements Requirements Development
Requirements
Regulatory
Requirements

External Ethical Accounting

Requirements Requirements Requirements

Legislative Safety/Security
“Software Engineering” Requirements Requirements
Ian Sommervile (Chapter 4) !29
Example of Non-Functional Requirements

It shall be possible for all necessary communication between the

Product
APSE and the user to be expressed in the standard Ada character
requirements set

The system development process and deliverable documents shall

Organizational
conform to the process and deliverables defined in XYZCo-SP-
requirements STAN-95

The system shall provide facilities that allow any user to check if
External personal data is maintained on the system. A procedure must be
requirements defined and supported in the software that will allow users to
inspect personal data and to correct any errors in that data

!30
 Security Requirements
Security requirements are non-functional requirements
(properties that a system must have).

Development of secure software includes integrating security in

different phases of the software development.

Early consideration for security helps in tackling security

problems - software that satisfies security requirements should
lead to better code.

!31
 Requirements Verifiability
Requirements must be written to be objectively verified

Imprecise:
•The system should be easy to use by experienced controllers and should be
organized in such a way that user errors are minimized
•Locutions like ‘easy to use’ and ‘errors shall be minimized’ are useless
specifications

Verifiable:
•Experienced controllers should be able to use all the system functions after
a total of two hours of training. After this training, the average number of
errors made by experienced users should not exceed two per day

!32
Precise Requirements Measures
Property Measure

Processed transactions/second, User/Event response time, Screen

Speed
refresh time

Size Megabytes, Number of RAM chips

Ease to use Training time, Rate of errors made by users, Number of help dialogs

Mean time to failure, Probability of unavailability, Rate of failure

Reliability
occurrence
Time to restart after failure, Percentage of events causing failure,
Robustness
Probability of data corruption on failure
Percentage of target dependent statements, Number of target
Portability
systems

!33
 MoSCoW Method
It is a prioritization technique for software requirements. Functional
requirements are divided into four categories:

1. Must have: functional requirements that are critical to the current

delivery timebox for a successful project
2. Should have: functional requirements that are important but not as time-
critical as the must-have requirements. Therefore, they can be delivered
in the future delivery timebox.
3. Could have: functional requirements that are desirable but not necessary.
Usually, these requirements improve user or customer experience.
4. Won’t have: requirements that are perceived as the least-critical by
stakeholders. This category includes requirements that are dropped and
considered for inclusion in a future version of the project.

!34
Requirements Checking
And Reviews

35
Requirements Checking and Reviews

Does the system have the functions that best support

Validity
the customer’s needs?

Consistency Are there any requirements conflicts?

Completeness Are all functions required by the customer included?

Can the requirements be implemented in the available

Realism
budget and technology?

!36
 Security Reviews

Regular reviews should be held while the requirements definition

is being formulated

Both client and contractor staff should be involved in the reviews

Reviews may be formal (with completed documents) or informal

•Good communication between developers, customers, and users can resolve
problems at an early stage

!37
 Review Checks

Verifiability Is the requirement realistically testable?

Comprehensibility Is the requirement properly understood?

Traceability Is the origin of the requirements clearly stated?

Can the requirement be changed without large impact

Adaptability
on other requirements?

!38
Sample Requirements Checklist
Does each specific requirement have a unique identifier?
• Is each requirement atomic and simply formulated? (Typically a single sentence.
Composite requirements must be split)
• Are requirements organized into coherent groups? (If necessary, hierarchical; not
more than about 10 per group)
• Is each requirement prioritized? (Is the meaning of the priority levels clear?)
• Are all unstable requirements marked as such? (e.g., TBC = to be confirmed, TBD =
to be defined)
• Is each requirement verifiable (in a provisional acceptance test)? (Measurable:
where possible, quantify, capacity, performance, accuracy)
• Are the requirements consistent? (Non-conflicting)
• Are the requirements realizable within budget and time?
…

!39
 Traceability
To protect against changes you should be able to trace back
from every system component to the original requirement that
caused its presence
• A software process should help keeping this table up-to-date
• Simple techniques are quite valuable (e.g., naming conventions)

C1 C2 C3
Req 1 x
Req 2 x
…
Req n x x

!40
Use Cases

!41
 Use Cases
Use cases have been introduced by Ivar Jacobson in the early 1990s and
document the behavior of the system from the user’s points of view.

‘User’ means anything external to the system being developed which interacts
with the system. A user might be a person, another information system, a
hardware device, etc.

Use case modeling helps with three of the most difficult aspects of
development:
• capturing requirements
• planning iterations of development
• validating systems.

!42
 Notation
An actor represents an user of the system. Remember a "user"
is anything external to the system that interacts with it (not only
humans)

A use case is represented as a named oval. It corresponds to a

task which has to be done with support from the system under
development

There is a line connecting an actor to a use case if the actor may

interact with the system to play some part in the task.

!43
Some Examples

Using UML: Software Engineering with

Objects and Components (Chapter 7)
!44
 Primary and Secondary Actors
Primary Actor
• Acts on the system
• Initiates an interaction with the system
• Uses the system to fulfill his/her goal
• Events Something we don’t have control over

Secondary Actor
• It is invoked/used by the system
• Helps the system to fulfills its goal
• Something the system uses to get its job done

!45
 System Boundary
Optionally, there can be a box around the use cases in a use case diagram, labeled with the
name of the system. The box represents the system boundary. This can be useful when
modeling a complex system which is split into different subsystems: you could have one use
case diagram for each subsystem.

Using UML: Software Engineering with

Objects and Components (Chapter 7)
!46
 Relationships
Relationship is an association between use case and actor. There are
several Use Case relationships:

Association
<<extend>>
Extend

Generalization
<<include>>
Include

!47
 Include Relationship
An include relationship indicates that a use case is included as parts of
other use cases. The notation for this relationship is a dotted line with an
open arrow and the keyword <<include>>.

This relationship allows to factor out common behavior from two or more
of our original use cases, or (better still) when we discover that we can
implement part of one of our use cases by using a component.

Base Use Case

!48
 Extend Relationship
An extend relationship indicates that some use cases extend the behavior
of other core use cases. The base use case implicitly incorporates the
behavior of another use case at certain points called extension points. The
notation for this relationship is a dotted line with an arrow point and
labeled <<extend>>

Beware: the arrow goes from the exceptional case to the normal case
!49
 Generalization
Generalization is a relationship between a general use case and a
more specific use case. Equivalently, it can be viewed as use cases
that are specialized versions of other use cases. The notation for this
relationship is a solid line with a hollow arrow point.

Pay via Paypal

Make Payment
Pay via
Credit Card
Customer

!50
 Use Case Description
A use case diagram shows not a single use case, but all use cases
for the given system. However, each use case is also described in
detail, usually in natural language.

A use case description should include:

• Title or Reference Name - meaningful name of the UC
• Author/Date - the author and creation date
• Modification/Date - last modification and its date
• Purpose - specifies the goal to be achieved
• Overview - short description of the processes
• Cross References - requirements references
• Actors - agents participating
• Pre Conditions - must be true to allow execution
• Post Conditions - will be set when completes normally
• The normal flow of events - the regular flow of activities
• The alternative flow of events - other flow of activities
• Exceptional flow of events - unusual situations

!51
 Example: Withdraw Cash
Withdraw failed

<<extends>>

Withdraw Cash
Bank System

<<include>>
Customer

<<extends>>
Authenticate Authentication
Failed

!52
 Example: Withdraw Cash
• Use Case: Withdraw Cash
• Author: AP
• Date: 12/09/2018
• Purpose: Withdraw some cash from a user’s bank account
• Overview: The customer inserts his/her card into the ATM. The
system requests the card PIN. The system validates the PIN via
connection to the bank circuits. If the validation is successful, the
customer can choose the withdraw operation; otherwise
(unsuccessful validation) a validation failure message is shown. The
customer enters the amount of cash she/he wants to withdraw. The
system checks whether the requested amount is <= the current
balance in the user bank account. In case of a positive check, the
system dispenses the cash and prints a withdraw receipt. Otherwise,
an error message is printed on the screen, and no cash is delivered.
• Cross-reference: Requirements R1, R2

!53
 Example: Withdraw Cash
• Use Case: Withdraw Cash
• Author: AP
• Date: 12/09/2018
• Purpose: Withdraw some cash from a user’s bank account
• Overview: The customer inserts his/her card into the ATM. The Normal flow
system requests the card PIN. The system validates the PIN via
connection to the bank circuits. If the validation is successful, the
customer can choose the withdraw operation; otherwise
(unsuccessful validation) a validation failure message is shown. The Alternative
customer enters the amount of cash she/he wants to withdraw. The
system checks whether the requested amount is <= the current
balance in the user bank account. In case of a positive check, the
system dispenses the cash and prints a withdraw receipt. Otherwise,
an error message is printed on the screen, and no cash is delivered.
• Cross-reference: Requirements R1, R2

!54
 Example: Withdraw Cash

• Actors: Customer and Banks

• Pre-conditions:
• The ATM must be in a state ready to accept transactions
• The ATM must be connected to the international bank circuit
• The ATM must have some cash available that it can dispense
• Post-conditions:
• The current balance in the user bank account is reduced by the
withdrawn amount
• A receipt was printed
• Flow of events: …

!55
 Example: Withdraw Cash
Customer Actions
1. Customer inserts a credit card
into ATM
3. Customer inserts his/her PIN
6. Customer chooses the
“withdraw” operation
8. Customer enter the amount
14. Customer takes the cash and
the receipt
System Action Bank Action
2. System reads the card and
asks for the PIN
4. The system connect to the
5. Validates the PIN
bank circuits
7. System asks for the amount to
withdraw
9. System cheks of the requested
amount is legal
10. Systems dispenses the
requested cash
11. Systems deduces the amount
from user account
12. System prints the receipts
13. System ejects cash and card
!56
 Example: Withdraw Cash

• The alternative flow of events:

• Step 4: the authorization failed. An error message is displayed, the

transaction is canceled and the card ejected.

• Step 9: Customer has insufficient money in his/her account. The system

displays an error message and goes to step 7.

• Step 9: Customer exceeds its legal amount. The system displays an error
message and goes to step 7.

!57
 References
Software Engineering Using UML: Software Engineering with
Ian Sommerville Objects and Components
Perdita Stevens, Rob Pooley

Chapters: 3, 7, 8
Chapters: 2,4
Chapter 2 for Object Concepts

!58