Functional Requirements

1
Functional Requirements
Requirements Eng. Project Manag.

• Jerzy Nawrocki
• Jerzy.Nawrocki_at_put.poznan.pl

2
Aim of the lecture
To present how to specify functional requirements
with use cases.
3
Agenda

• Earlier approaches to FR
• Use cases
• If-then considered harmful
• Use-case patterns
• Use cases and IEEE 830

4
Agenda

• Earlier approaches to FR
• Use cases
• If-then considered harmful
• Use-case patterns
• Use cases and IEEE 830

5
Requirement in RequisitePro
Rational RequisitePro

• name (tag),
• text,
• attributes

6
Attribute Matrix in RequisitePro
Tag
Short text
Attribute
Attribute
Full text
7
Lost rationale
Do we need a given functionality?
8
Agenda

• Earlier approaches to FR
• Use cases
• If-then considered harmful
• Use-case patterns
• Use cases and IEEE 830

9
Ivar Jacobson
1967 Ericsson, telecommunication systems 1985
Ph.D., The Royal Institute of Tech.,
Stockholm 1987 Founder of Objectory AB 1995
Objectory AB merges with Rational 2003 IBM buys
Rational
http//www.analisi-disegno.com/uml/JacobsonIntervi
ew.html http//www.jaczone.com/
10
Use Case Diagram in UML
Airline reservation
Travel agent
Merchant bank
11
Use case
A story describing how an actor (user or device)
cooperates with the system to accomplish a given
purpose.
12
A Use Case

• Updating personal data
• Actor Member
• Main scenario
• Member enters his account and password.
• System presents the personal web page.
• Member selects the update option.
• System presents the personal data ready for
  update.
• Member changes the data.
• System asks for acknowledgement.
• Member confirms the changes.
• Extensions
• 1a. Account or password is incorrect.
• 1a1. System presents a message and returns
  to Step 1.

13
A Use Case

• Use-case name
• Actor Name
• Main scenario
• Action
• Action
• Action
• . . .
• Extensions
• Step.a. Event
• Step.a1. Action
• Step.a2. Action
• Step.b. Event
• Step.b1. Action

Updating personal data
14
A Use Case

• Use-case name
• Actor Name
• Main scenario
• Action
• Action
• Action
• . . .
• Extensions
• Step.a. Event
• Step.a1. Action
• Step.a2. Action
• Step.b. Event
• Step.b1. Action

Updating personal data
15
A Use Case

• Use-case name
• Actor Name
• Main scenario
• Action
• Action
• Action
• . . .
• Extensions
• Step.a. Event
• Step.a1. Action
• Step.a2. Action
• Step.b. Event
• Step.b1. Action

Member
Updating personal data
16
A Use Case

• Use-case name
• Actor Name
• Main scenario
• Action
• Action
• Action
• . . .
• Extensions
• Step.a. Event
• Step.a1. Action
• Step.a2. Action
• Step.b. Event
• Step.b1. Action

Member
Updating personal data
Member enters his account and password
17
A Use Case

• Use-case name
• Actor Name
• Main scenario
• Action
• Action
• Action
• . . .
• Extensions
• Step.a. Event
• Step.a1. Action
• Step.a2. Action
• Step.b. Event
• Step.b1. Action

Member
Updating personal data
Member enters his account and password
Account or password is incorrect
18
Use cases
The same goal

• A use case
• Main scenario
• Step
• Step
• Extensions
• 1a. Event
• 1a1. Alternative step

Scenario 1
Scenario 2
Scenario 3
19
Shortest form of use cases

• Dean
• Sets number of places for each MS Degree
  Programme.
• Gets list of students assigned to each MS
  Programme.
• Student
• Enters her preferences by sequencing MS Degree
  Programmes from the most to the least
  interesting.
• Gets information about the MS Programme to which
  she has been assigned.

Scope description
20
Human-Computer Interaction Description
Definition of a use case
A story describing how an actor (user person or
device) cooperates with the system other actors
(people or devices) to accomplish a given purpose.
21
Business Process Description
Definition of a use case
A story describing how an actor (user person or
device) cooperates with the system other actors
(people or devices) to accomplish a given purpose.
22
Business Process Description
Get Paid for Car Accident Actors Claimant
-- Accident victim making claim
Insurance Company -- Company insuring
Claimant Agent
-- Insurance Company representative Main 1.
Claimant submits claim with substantiating
data. 2. Insurance Company verifies that Claimant
owns a valid policy. 3. Insurance Company assigns
Agent to examine the case. 4. Agent verifies that
all details are within policy guidelines. 5.
Insurance Company pays Claimant. Extensions 1a.
Submitted data is incomplete 1a1.
Insurance Company requests missing information.
1a2. Claimant supplies missing
information. 2a. Claimant does not own a valid
policy . . .
23
Agenda

• Earlier approaches to FR
• Use cases
• If-then considered harmful
• Use-case patterns
• Use cases and IEEE 830

24
Control flow in computer programs
For every program there is an equivalent program
using only sequence and iteration (while) as
control structures.
Corrado Böhm INAC-CNR, Rome
C. Böhm, G. Jacopini, Flow diagrams, Turing
Machines and Languages with only Two Formation
Rules, Comm. of the ACM , 9(5) 366-371,1966.
25
Goto considered harmful

• Structured programming
• sequence
• selection (if-then-else)
• iteration (while-do)

E.W. Dijkstra, Go To Statement Considered
Harmful, Comm. of the ACM, Volume 11 (3) 147
148, 1968.  
Edsger W. Dijkstra Eindhoven Univ. of Technology
26
If-then-else considered harmful
Boolean Primary (int n) int i, result if
(n lt 1) result False ERROR
"Wrong input" else if
(n1 or n2) result True
else if (n 2 0) result
False else result True for
(i3 i lt n/2 i2) result
False return result
27
If-then-else considered harmful
Boolean Primary (int n) int i, result if
(n lt 1) result False ERROR
"Wrong input" else if
(n1 or n2) result True
else if (n 2 0) result
False else result True for
(i3 i lt n/2 i2) result
False return result
28
If-then-else considered harmful
Boolean Primary (int n) int i, result if
(n lt 1) result False ERROR
"Wrong input" else if
(n1 or n2) result True
else if (n 2 0) result
False else result True for
(i3 i lt n/2 i2) result
False return result
Checking if N is a primary number Main 1. User
enters N. 2. System set an auxiliary variable
RESULT to TRUE and K to 3. 3. In case N is
divisible by K system sets RESULT to FALSE. 4.
System increments K by 2 and returns to step
3. Extensions 2a. N lt 1 2a1. Error message
is displayed. 2b. N1 or N2 2b1. RESULT is
set to TRUE. 2c. N is even ...
29
If-then-else considered harmful
Boolean Primary (int n) int i, result if
(n lt 1) result False ERROR
"Wrong input" else if
(n1 or n2) result True
else if (n 2 0) result
False else result True for
(i3 i lt n/2 i2) result
False return result
Checking if N is a primary number Main 1. User
enters N. 2. System set an auxiliary variable
RESULT to TRUE and K to 3. 3. In case N is
divisible by K system sets RESULT to FALSE. 4.
System increments K by 2 and returns to step
3. Extensions 2a. N lt 1 2a1. Error message
is displayed. 2b. N1 or N2 2b1. RESULT is
set to TRUE. 2c. N is even ...
30
If-then-else considered harmful
Boolean Primary (int n) int i, result if
(n lt 1) result False ERROR
"Wrong input" else if
(n1 or n2) result True
else if (n 2 0) result
False else result True for
(i3 i lt n/2 i2) result
False return result
Checking if N is a primary number Main 1. User
enters N. 2. System set an auxiliary variable
RESULT to TRUE and K to 3. 3. In case N is
divisible by K system sets RESULT to FALSE. 4.
System increments K by 2 and returns to step
3. Extensions 2a. N lt 1 2a1. Error message
is displayed. 2b. N1 or N2 2b1. RESULT is
set to TRUE. 2c. N is even ...
31
Use-case paradigm
Main
Start
Action 1
Extension
Action 2
Action 3
Stop
32
Agenda

• Earlier approaches to FR
• Use cases
• If-then considered harmful
• Use-case patterns
• Use cases and IEEE 830

33
Use-case patterns
Use-case names
Creating employee record Deleting employee record
Hiring employee Firing employee
User-valued transactions Identify the valuable
services that the system delivers to the actors
to satisfy their business purposes.
34
Do you like it?

• Registering for a course
• Main
• Display a blank schedule.
• Display a list of all classes in the following
  way The left window lists all the courses in the
  system in alphabetical order. The lower window
  displays the times the highlighted course is
  available. The third window shows all the courses
  currently in the schedule.
• Do.
• Student clicks on a course.
• Update the lower window to show the times the
  course is available.
• Student clicks on a course time and then clicks
  on the Add Course button.
• . . .

35
Do you like it?
Too many user interface details

• Registering for a course
• Main
• Display a blank schedule.
• Display a list of all classes in the following
  way The left window lists all the courses in the
  system in alphabetical order. The lower window
  displays the times the highlighted course is
  available. The third window shows all the courses
  currently in the schedule.
• Do.
• Student clicks on a course.
• Update the lower window to show the times the
  course is available.
• Student clicks on a course time and then clicks
  on the Add Course button.
• . . .

36
Use case patterns
Behaviour description Use cases are for
behavioural description. User interface should be
described elsewhere.
37
Do you like it?

• Registering for a course
• Main
• Display a blank schedule.
• Display a list of all classes in the following
  way The left window lists all the courses in the
  system in alphabetical order. The lower window
  displays the times the highlighted course is
  available. The third window shows all the courses
  currently in the schedule.
• Do.
• Student clicks on a course.
• Update the lower window to show the times the
  course is available.
• Student clicks on a course time and then clicks
  on the Add Course button.
• . . .

38
Use case patterns
Actor Intention Accomplished Write each step to
show clearly which actor is performing the
action, and what the actor gets accomplished.
39
A corrected use case

• Registering for a course
• Main
• System displays a blank schedule.
• Student points to a course he is interested in.
• System shows the times the course is available.
• Student chooses the course.
• . . .

40
Use case patterns
Use case length A use case should have from 3 to
9 steps.
41
Agenda

• Earlier approaches to FR
• Use cases
• If-then considered harmful
• Use-case patterns
• Use cases and IEEE 830

42
Software Requirements Specification
1. Introduction 2. Overall description of the
product 3. Functional requirements 4.
Non-functional requirements Appendices Index
43
Software Requirements Specification
1. Introduction 1.1 Purpose of the document 1.2
Scope of the product 1.3 Definitions, acronyms
and abbreviations 1.4 References 1.5 Overview of
the document 2. Overall description of the
product 3. Functional requirements 4.
Non-functional requirements Appendices Index
44
1.1 Purpose of the document
Role of SRS the readers
The document presents software requirements, i.e.
it describes functionality of the software that
will be built as well as other constraints
imposed on it. The document is aimed at
end-users, designers, programmers, testers, and
manual writers.
45
1.2 Scope of the product

• Identification of the product by name.
• What the product will do and what will not.
• Application of the specified product.

Polish Writers Association has over 10 000
members. The members frequently change their
address data and there are problems with updating
them fast. The problem concerns both the members
(about 500 change their data a year), and the
board, which suffers from communication troubles.
As a consequence unpaid member dues amount to
about 15 000 zl. The problem can be solved by
acquiring an Internet-based system, e-Member,
allowing updating address data by Internet.
46
1.3 Definitions, acronyms and abbreviations
ASAP As Soon As Possible Explorer see MS
Explorer ... MS Explorer Microsofts product
that allows reading web pages NIP Tax
identification number in Poland (in Polish Numer
identyfikacji podatkowej) PWA Polish
Writers Associations
Alphabetic order!
47
1.4 References
The system should present avarage value and
standard deviation Montgomery97.
Montgomery97 D.Montgomery, Introduction to
Statistical Quality Control, John Wiley Sons,
Boston, 1997. act2000 Polish act Ustawa z dnia
16.11.2000 o przeciwdzialaniu wprowadzaniu do
obrotu finansowego wartosci majatkowych
pochodzacych z nielegalnych lub nieujawnionych
zródel oraz o przeciwdzialaniu finansowaniu
terroryzmu, Dz.U. 22 December 2000.
48
1.5 Overview of the document
What is in the subsequent parts of the document?
In Chapter 2 a general description of the product
is presented along with short characteristic of
end-users and the functionality that will be
available to them. Chapter 3 containts detailed
description of functional requirements. They have
been split according to user classes (roles).
Those requirements are a starting point to
description of non-functional requirements that
are presented in Chapter 4.
49
SRS Structure
1. Introduction 2. Overall description of the
product 2.1 Product perspective (context) 2.2
User characteristics 2.3 Main product
functions 2.4 Constraints 2.5 Assumptions and
dependencies 3. Functional requirements 4.
Non-functional requirements Appendices Index
50
2.1 Product perspective
The described system is to communicate with the
PolCard system to implement electronic payments.
The context diagram is presented in Fig. 1.
51
2.2 User characteristics
The following roles has been identified Member
of the association Most of the PWA members
(over 80) are 30 to 55 years old. Some of them
have sight problems. From a inquire conducted
recently it follows that 80 members have a
computer at home and they know how to read web
pages or they are willing to get to know. Board
All the board members have computers and they are
proficient with using web pages.
52
2.3 Main product functions

• The product will offer the following
  functionality.
• An PWA member can
• Read his/her data stored in the system
• Update his/her data.
• PWA Board can
• Send serial mail to PWA members.

53
2.4 Constraints
The system must obey requlations imposed by the
Polish act concerning personal data
personal-data-act.
54
2.5 Assumptions and dependencies
The presented requirements are based on
requlations known as of 1 September 2005.
55
SRS Structure
1. Introduction 2. Overall description of the
product 3. Functional requirements 3.1 PWA
Member 3.1.1 Reading the data
3.1.2 Updating the data 3.2 PWA Board
3.2.2.1 Broadcasting mail 4. Non-functional
requirements Appendices Index
56
A Use Case

• Updating the data
• Actor Member
• Goal Update personal data.
• Main scenario
• Member enters his account and password.
• System presents the personal web page.
• Member selects the update option.
• System presents the personal data ready for
  update.
• Member changes the data.
• System asks for acknowledgement.
• Member confirms the changes.
• Extensions
• 1a. Account or password is incorrect.
• 1a1. System presents a message and returns
  to Step 1.

57
Summary

• Earlier approaches to FR
• Use cases
• If-then considered harmful
• Use-case patterns
• Use cases and IEEE 830

58
Bechmark for Use-Case Management System
What use cases (can) appear in practice? What
expressions appear within them and how
frequently? A standard (typical) FRS with use
cases. Are any papers on that subject?
59
(No Transcript)
60
(No Transcript)
61
Thank you for your attention!
62
Agenda

• Earlier approaches to FR
• Use cases
• If-then considered harmful
• Use-case patterns
• Use cases and IEEE 830
• User stories
• Acceptance testing