Scribd
Upload
40 views5 pages

Requirements Analysis: F U R P S

The document discusses requirements analysis for a time tracking system. It begins by outlining the standard approach of using natural language specifications and common problems with ambiguity and management. It then introduces the goal of defining product requirements through a requirements document and key diagrams. The main diagram presented is FURPS, which categorizes requirements by Functionality, Usability, Reliability, Performance, and Supportability. The document also discusses use cases and use case diagrams to model system behaviors. It provides an example for a time tracking system, identifying actors, use cases, and describing the "Start and stop counting" use case in detail.

Uploaded by

RaphaelGbologah
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
40 views5 pages

Requirements Analysis: F U R P S

The document discusses requirements analysis for a time tracking system. It begins by outlining the standard approach of using natural language specifications and common problems with ambiguity and management. It then introduces the goal of defining product requirements through a requirements document and key diagrams. The main diagram presented is FURPS, which categorizes requirements by Functionality, Usability, Reliability, Performance, and Supportability. The document also discusses use cases and use case diagrams to model system behaviors. It provides an example for a time tracking system, identifying actors, use cases, and describing the "Start and stop counting" use case in detail.

Uploaded by

RaphaelGbologah
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 5

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

You might also like