1. Functional Requirements
(c) Jerzy Nawrocki
Requirements Eng. & Project Manag.
Functional Requirements
Jerzy Nawrocki
XPrince dla architektów

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

3. Earlier approaches to FR Use cases If-then considered harmful
(c) Jerzy Nawrocki
Agenda
Earlier approaches to FR
Use cases
If-then considered harmful
Use-case patterns
Use cases and IEEE 830
XPrince dla architektów

4. Earlier approaches to FR Use cases If-then considered harmful
(c) Jerzy Nawrocki
Agenda
Earlier approaches to FR
Use cases
If-then considered harmful
Use-case patterns
Use cases and IEEE 830
XPrince dla architektów

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. Earlier approaches to FR Use cases If-then considered harmful
(c) Jerzy Nawrocki
Agenda
Earlier approaches to FR
Use cases
If-then considered harmful
Use-case patterns
Use cases and IEEE 830
XPrince dla architektów

9. 1967: Ericsson, telecommunication systems
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

10. Use Case Diagram in UML Find flight Construct itinerary
Airline reservation
Travel agent
Reserve flight
Issue ticket
Merchant bank

11. Use case
A story describing how an actor (user or device) cooperates with the system to accomplish a given purpose.

12. Updating personal data
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. Updating personal data
A Use Case
Use-case name
Actor: Name
Main scenario:
Action
. . .
Extensions:
Step.a. Event
Step.a1. Action
Step.a2. Action
Step.b. Event
Step.b1. Action
Updating personal data

14. Updating personal data
A Use Case
Use-case name
Actor: Name
Main scenario:
Action
. . .
Extensions:
Step.a. Event
Step.a1. Action
Step.a2. Action
Step.b. Event
Step.b1. Action
Updating personal data

15. Updating personal data
A Use Case
Use-case name
Actor: Name
Main scenario:
Action
. . .
Extensions:
Step.a. Event
Step.a1. Action
Step.a2. Action
Step.b. Event
Step.b1. Action
Member
Updating personal data

16. Updating personal data Member enters his account and password
A Use Case
Use-case name
Actor: Name
Main scenario:
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 . . .
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. The same goal Scenario #1 Scenario #2 Scenario #3
Use cases
The same goal
A use case
Main scenario:
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. Earlier approaches to FR Use cases If-then considered harmful
(c) Jerzy Nawrocki
Agenda
Earlier approaches to FR
Use cases
If-then considered harmful
Use-case patterns
Use cases and IEEE 830
XPrince dla architektów

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): ,1966.

25. Goto considered harmful
Structured programming:
sequence
selection (if-then-else)
iteration (while-do)
Edsger W. Dijkstra
Eindhoven Univ. of Technology
E.W. Dijkstra, Go To Statement Considered Harmful, Comm. of the ACM, Volume 11 (3): 147 – 148, 1968.  

26. If-then-else considered harmful
Boolean Primary (int n){
int i, result;
if (n < 1) {result= False;
ERROR "Wrong input" }
else if (n==1 or n==2)
result= True;
else if (n % 2 == 0)
result= False;
else { result= True;
for (i=3; i < n/2; i+=2)
return result;

27. If-then-else considered harmful
Boolean Primary (int n){
int i, result;
if (n < 1) {result= False;
ERROR "Wrong input" }
else if (n==1 or n==2)
result= True;
else if (n % 2 == 0)
result= False;
else { result= True;
for (i=3; i < n/2; i+=2)
return result;

28. If-then-else considered harmful
Boolean Primary (int n){
int i, result;
if (n < 1) {result= False;
ERROR "Wrong input" }
else if (n==1 or n==2)
result= True;
else if (n % 2 == 0)
result= False;
else { result= True;
for (i=3; i < n/2; i+=2)
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 < 1
2a1. Error message is displayed.
2b. N=1 or N=2
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 < 1) {result= False;
ERROR "Wrong input" }
else if (n==1 or n==2)
result= True;
else if (n % 2 == 0)
result= False;
else { result= True;
for (i=3; i < n/2; i+=2)
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 < 1
2a1. Error message is displayed.
2b. N=1 or N=2
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 < 1) {result= False;
ERROR "Wrong input" }
else if (n==1 or n==2)
result= True;
else if (n % 2 == 0)
result= False;
else { result= True;
for (i=3; i < n/2; i+=2)
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 < 1
2a1. Error message is displayed.
2b. N=1 or N=2
2b1. RESULT is set to TRUE.
2c. N is even ...

31. Main Extension Use-case paradigm Start Action 1 Action 2 Action 2-1
Step 3
Step 2
Step 1
Action 1
Extension
Event 2a (interrupt)
Step 2-2
Step 2-1
Action 2-1
Action 2-2
Action 2
Action 3
Stop

32. Earlier approaches to FR Use cases If-then considered harmful
(c) Jerzy Nawrocki
Agenda
Earlier approaches to FR
Use cases
If-then considered harmful
Use-case patterns
Use cases and IEEE 830
XPrince dla architektów

33. User-valued transactions
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. Registering for a course
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. Too many user interface details Registering for a course
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.
. . .

36. Behaviour description
Use case patterns
Behaviour description
Use cases are for behavioural description. User interface should be described elsewhere.

37. Registering for a course
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. Actor Intention Accomplished
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. Registering for a course
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. Earlier approaches to FR Use cases If-then considered harmful
(c) Jerzy Nawrocki
Agenda
Earlier approaches to FR
Use cases
If-then considered harmful
Use-case patterns
Use cases and IEEE 830
XPrince dla architektów

42. Software Requirements Specification
IEEE Std
1. Introduction
2. Overall description of the product
3. Functional requirements
4. Non-functional requirements
Appendices
Index

43. Software Requirements Specification
IEEE Std
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. Identification of the product by name.
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 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 zł. 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 – Microsoft’s 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 o przeciwdziałaniu wprowadzaniu do obrotu finansowego wartości majątkowych pochodzących z nielegalnych lub nieujawnionych źródeł oraz o przeciwdziałaniu 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
IEEE Std
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 E-Member
The described system is to communicate with the PolCard system to implement electronic payments. The context diagram is presented in Fig. 1.
E-Member
Member
Board
PolCard

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
IEEE Std
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
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. Earlier approaches to FR Use cases If-then considered harmful
(c) Jerzy Nawrocki
Summary
Earlier approaches to FR
Use cases
If-then considered harmful
Use-case patterns
Use cases and IEEE 830
XPrince dla architektów

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?

61. Thank you for your attention!