Requirements Analysis
Standard approach:
Use natural language specifications written with a Word
Processor (e.g. MS Word)
Software Engineering
Laboratory
Standard problems:
Difficulties in understanding how the system works
Ambiguities/Incompleteness in the specifications
Requirements Management (impact of requirements,
traceability, )
Requirement Analisys
Lesson 2
Software Engineering Laboratory
Requirements Analysis
Software Engineering Laboratory
Requirements
Goal:
Define the requirements of the product
Output
Requirements Document
(possibly containing various UML diagrams)
Main Diagram for Requirements Analysis:
Functionality Functions performed, Security, ...
Usability User Interaction, Look & Feel, Documentation, ...
Reliability Mean time between failures, Recovery, Accuracy
of Results,
Performance Memory, Processor, ...
Use Case Diagrams
S
Software Engineering Laboratory
Supportability Compliance to standards, Portability,
Configurability
Software Engineering Laboratory
Use Cases and Use Case Diagrams
Use Case
Set of scenarios describing a coherent unit of
functionality as seen by a user of the system.
Software Engineering
Laboratory
Use Case Diagram
A graph collecting the use cases, the actors taking place
in the use cases, and the relationship among use cases
and actors.
Use Cases and Use Case Diagrams
Lesson 2
Software Engineering Laboratory
Example: Time Tracker
Software Engineering Laboratory
Step 1: Identify Actors
We have been contacted by a small software
firm.
An actor is someone or some thing
that must interact with the System
Under Development
They want us to build a system for letting
employees track how they spend their time
when working on a computer. The idea is that
of a stop
- watch: the users of the system can
start and stop counting the time spent on
different activities; the system logs such
activities and can be used to produce reports.
The system can also be integrated with a
billing system. The billing system receives all
the information about the time spent by
programmers on the different projects and
computes the cost of projects. This
information is then used to charge clients.
Software Engineering Laboratory
Software Engineering Laboratory
Step 1: Identify Actors
Step 1: Time Tracker
We have been contacted by a small software firm.
An actor is someone or something that
must interact with the System Under
Development
They want us to build a system for letting employees track
how they spend their time when working on a computer. The
idea is that of a stop
- w
atch: the users of the system can start
and stop counting the time spent on different activities; the
system logs such activities and can be used to produce
reports by an administrator.
The system can also be integrated with a billing system. The
billing system receives all the information about the time spent
by programmers on the different projects and computes the
cost of projects.
Software Engineering Laboratory
User of the system
Administrator
Step 2: Identify Use Cases
Software Engineering Laboratory
10
Step 2: Time Tracker
A use case is a pattern of behavior the system
exhibits
We have been contacted by a small software firm.
They want us to build a system for letting employees track
how they spend their time when working on a computer. The
idea is that of a stop
- w
atch: the users of the system
can start and stop counting the time spent on different
activities; the system logs such activities and can be used to
produce reports by an administrator.
Each use case is a sequence of related transactions performed by
an actor and the system in a dialogue
Strategies for identifying Use Cases
Examine Actors to determine their needs
The system can also be integrated with a billing system. The
billing system receives all the information about the time spent
by programmers on the different projects and computes the
cost of projects.
Find verbs and actions in the description
Software Engineering Laboratory
Billing System
11
Software Engineering Laboratory
12
Step 2: Identify Use Cases
Step 3: Use Case Diagram
A use case is a pattern of behavior the system
exhibits
Each use case is a sequence of related transactions performed by an
actor and the system in a dialogue
Start and stop counting
Use case diagrams are created to visualize
the relationships between actors and use
cases
User of the system
Show
Start and stop counting
Produce reports
Administrator
Compute the cost of projects
Produce reports
Software Engineering Laboratory
Billing System
13
Step 4: Describe Use Cases
Show the cost of projects
Software Engineering Laboratory
Step 4: Start and stop counting
A flow of events document is created for each use cases
Written from an actor point of view
This use case begins when the user logs onto the TimeTracker
and enters his/her password.
Details what the system must provide to the actor when the
use cases is executed
The system verifies that the password is valid (E
- 1) and
prompts the user to select the current activity. The user enters
the activity (E
- 2) and the system starts the timer.
This use case ends when the user logs out and the system
stops the timer.
Typical contents
How the use case starts and ends
Normal flow of events
Alternate flow of events
Exceptional flow of events
Software Engineering Laboratory
14
- 1: if the password isnt valid the system logs out
E
-E 2: if the activity doesnt exist the system asks for a new
activity
15
Software Engineering Laboratory
16
Hint 1. Use Cases
Hint 2. Use Case Descriptions
The process of describing use cases (and of reading them!) is
greatly simplified if the same structure is used for all the use
cases: always stick to the same notation!
Use cases show the way in which actors interact with the
system.
Although they can be used to represent a functional
decomposition of the system, use cases work better if you
focus on how the user performs tasks with the
application.
try and define one: we will present one in the next lesson
Software Engineering Laboratory
17
Software Engineering Laboratory
18
Home Work
HomeWork: Reservation System
Reservation System
How could you organize the previous exercises
in a coherent requirements document?
We want to build a system for the electronic reservation of seats
of a group of movie theatres. The users can either buy tickets for
a particular show or buy subscriptions, also by phone. Payments
can be performed in cash or by credit card (debit) card. A
supervisor can print the list of seats available for a particular show
and see the status of sales performed so far.
Think about the following problems:
What could the summary of the document be?
How can you organize diagrams and descriptions?
A secretary updates the list of shows (by adding/deleting/...)
F is ok! What about the URPS?
Software Engineering Laboratory
19
Software Engineering Laboratory
20
