functional requirements
DESCRIPTION
Requirements Eng. & Project Manag. Functional Requirements. Jerzy Nawrocki [email protected]. Aim of the lecture. To present how to specify functional requirements with use cases . Agenda. Earlier approaches to FR Use cases If-then considered harmful Use-case patterns - PowerPoint PPT PresentationTRANSCRIPT
Functional Requirements (2)
Requirements Eng. & Project Manag.
Aim of the lecture
To present how to specify functional requirements with use cases.
Functional Requirements (3)
Requirements Eng. & Project Manag.
Agenda
• Earlier approaches to FR• Use cases• If-then considered harmful• Use-case patterns• Use cases and IEEE 830
Functional Requirements (4)
Requirements Eng. & Project Manag.
Agenda
• Earlier approaches to FR• Use cases• If-then considered harmful• Use-case patterns• Use cases and IEEE 830
Functional Requirements (5)
Requirements Eng. & Project Manag.
Requirement in RequisitePro
• name (tag), • text, • attributes
Rational RequisitePro
Functional Requirements (6)
Requirements Eng. & Project Manag.
Attribute Matrix in RequisitePro
Tag
Full text
Short text Attribute Attribute
Functional Requirements (7)
Requirements Eng. & Project Manag.
Lost rationale
Do we need a givenfunctionality?
Functional Requirements (8)
Requirements Eng. & Project Manag.
Agenda
• Earlier approaches to FR• Use cases• If-then considered harmful• Use-case patterns• Use cases and IEEE 830
Functional Requirements (9)
Requirements Eng. & Project Manag.
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/JacobsonInterview.htmlhttp://www.jaczone.com/
Functional Requirements (10)
Requirements Eng. & Project Manag.
Use Case Diagram in UML
Construct itinerary
Merchant bank
Find flight
Travel agent
Airline reservationReserve
flight
Issue ticket
Functional Requirements (11)
Requirements Eng. & Project Manag.
Use case
A story describing how an actor (user or device) cooperates with the system to accomplish a given purpose.
Functional Requirements (12)
Requirements Eng. & Project Manag.
A Use CaseUpdating personal data
Actor: MemberMain scenario:1. Member enters his account and password.2. System presents the personal web page.3. Member selects the update option.4. System presents the personal data ready for update.5. Member changes the data.6. System asks for acknowledgement.7. Member confirms the changes. Extensions:1a. Account or password is incorrect. 1a1. System presents a message and returns to Step 1.
Functional Requirements (13)
Requirements Eng. & Project Manag.
A Use CaseUse-case name
Actor: NameMain scenario:1. Action2. Action3. Action4. . . .Extensions:Step.a. Event Step.a1. Action Step.a2. ActionStep.b. Event Step.b1. Action
Updating personal data
Functional Requirements (14)
Requirements Eng. & Project Manag.
A Use CaseUse-case name
Actor: NameMain scenario:1. Action2. Action3. Action4. . . .Extensions:Step.a. Event Step.a1. Action Step.a2. ActionStep.b. Event Step.b1. Action
Updating personal data
Functional Requirements (15)
Requirements Eng. & Project Manag.
A Use CaseUse-case name
Actor: NameMain scenario:1. Action2. Action3. Action4. . . .Extensions:Step.a. Event Step.a1. Action Step.a2. ActionStep.b. Event Step.b1. Action
Updating personal dataMember
Functional Requirements (16)
Requirements Eng. & Project Manag.
A Use CaseUse-case name
Actor: NameMain scenario:1. Action2. Action3. Action4. . . .Extensions:Step.a. Event Step.a1. Action Step.a2. ActionStep.b. Event Step.b1. Action
Updating personal dataMember
Member enters his account and password
Functional Requirements (17)
Requirements Eng. & Project Manag.
A Use CaseUse-case name
Actor: NameMain scenario:1. Action2. Action3. Action4. . . .Extensions:Step.a. Event Step.a1. Action Step.a2. ActionStep.b. Event Step.b1. Action
Updating personal dataMember
Member enters his account and password
Account or password is incorrect
Functional Requirements (18)
Requirements Eng. & Project Manag.
Use cases
The same goal
Scenario #1
Scenario #2
Scenario #3
A use caseMain scenario:1. Step2. StepExtensions:1a. Event 1a1. Alternative step
Functional Requirements (19)
Requirements Eng. & Project Manag.
Shortest form of use cases
DeanDean: • Sets number of places for each MS Degree Programme.• Gets list of students assigned to each MS Programme.StudentStudent: • 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.
Functional Requirements (20)
Requirements Eng. & Project Manag.
Human-Computer Interaction Description
A story describing how an actor (user person or device) cooperates with the system other actors (people or devices) to accomplish a given purpose.
Definition of a use case
Functional Requirements (21)
Requirements Eng. & Project Manag.
Business Process Description
A story describing how an actor (user person or device) cooperates with the system other actors (people or devices) to accomplish a given purpose.
Definition of a use case
Functional Requirements (22)
Requirements Eng. & Project Manag.
Business Process DescriptionGet Paid for Car Accident
Actors: Claimant -- Accident victim making claim Insurance Company -- Company insuring Claimant Agent -- Insurance Company representativeMain: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: . . .
Functional Requirements (23)
Requirements Eng. & Project Manag.
Agenda
• Earlier approaches to FR• Use cases• If-then considered harmful• Use-case patterns• Use cases and IEEE 830
Functional Requirements (24)
Requirements Eng. & Project Manag.
Control flow in computer programs
Corrado BöhmINAC-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.
For every program there is an equivalent program using only sequence and iteration (while) as control structures.
Functional Requirements (25)
Requirements Eng. & Project Manag.
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. DijkstraEindhoven Univ. of Technology
Functional Requirements (26)
Requirements Eng. & Project Manag.
If-then-else considered harmfulBoolean 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) result= False; } return result; }
Functional Requirements (27)
Requirements Eng. & Project Manag.
If-then-else considered harmfulBoolean 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) result= False; } return result; }
Functional Requirements (28)
Requirements Eng. & Project Manag.
If-then-else considered harmfulBoolean 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) result= False; } return result; }
Checking if N is a primary numberMain: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 ...
Functional Requirements (29)
Requirements Eng. & Project Manag.
If-then-else considered harmfulBoolean 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) result= False; } return result; }
Checking if N is a primary numberMain: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 ...
Functional Requirements (30)
Requirements Eng. & Project Manag.
If-then-else considered harmfulBoolean 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) result= False; } return result; }
Checking if N is a primary numberMain: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 ...
Functional Requirements (31)
Requirements Eng. & Project Manag.
Step 3
Step 2
Step 1
Use-case paradigm
Action 1
Action 2
Action 3
Start
StopStep 2-2
Step 2-1Action 2-1
Action 2-2
Event 2a (interrupt)
Functional Requirements (32)
Requirements Eng. & Project Manag.
Agenda
• Earlier approaches to FR• Use cases• If-then considered harmful• Use-case patterns• Use cases and IEEE 830
Functional Requirements (33)
Requirements Eng. & Project Manag.
Use-case patterns
Creating employee record
Deleting employee record
Hiring employee
Firing employee
Use-case names
User-valued transactions
Identify the valuable services that the system delivers to the actors to satisfy their business purposes.
Functional Requirements (34)
Requirements Eng. & Project Manag.
Do you like it?Registering for a course
Main:1. Display a blank schedule.2. 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.
3. Do.4. Student clicks on a course.5. Update the lower window to show the times the course is
available.6. Student clicks on a course time and then clicks on the „Add
Course” button. . . .
Functional Requirements (35)
Requirements Eng. & Project Manag.
Do you like it?Registering for a course
Main:1. Display a blank schedule.2. 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.
3. Do.4. Student clicks on a course.5. Update the lower window to show the times the course is
available.6. Student clicks on a course time and then clicks on the „Add
Course” button. . . .
Too many user interface details
Functional Requirements (36)
Requirements Eng. & Project Manag.
Use case patterns
Behaviour description
Use cases are for behavioural description. User interface should be described elsewhere.
Functional Requirements (37)
Requirements Eng. & Project Manag.
Do you like it?Registering for a course
Main:1. Display a blank schedule.2. 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.
3. Do.4. Student clicks on a course.5. Update the lower window to show the times the course is
available.6. Student clicks on a course time and then clicks on the „Add
Course” button. . . .
Functional Requirements (38)
Requirements Eng. & Project Manag.
Use case patterns
Actor Intention Accomplished
Write each step to show clearly which actor is performing the action, and what the actor gets accomplished.
Functional Requirements (39)
Requirements Eng. & Project Manag.
A corrected use caseRegistering for a course
Main:1. System displays a blank schedule.2. Student points to a course he is interested in.3. System shows the times the course is available.4. Student chooses the course. . . .
Functional Requirements (40)
Requirements Eng. & Project Manag.
Use case patterns
Use case length
A use case should have from 3 to 9 steps.
Functional Requirements (41)
Requirements Eng. & Project Manag.
Agenda
• Earlier approaches to FR• Use cases• If-then considered harmful• Use-case patterns• Use cases and IEEE 830
Functional Requirements (42)
Requirements Eng. & Project Manag.
Software Requirements Specification
1. Introduction2. Overall description of the product3. Functional requirements4. Non-functional requirementsAppendicesIndex
IEEE Std 830-1998
Functional Requirements (43)
Requirements Eng. & Project Manag.
Software Requirements Specification
1. Introduction1.1 Purpose of the document1.2 Scope of the product1.3 Definitions, acronyms and abbreviations1.4 References1.5 Overview of the document
2. Overall description of the product3. Functional requirements4. Non-functional requirementsAppendicesIndex
IEEE Std 830-1998
Functional Requirements (44)
Requirements Eng. & Project Manag.
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.
Functional Requirements (45)
Requirements Eng. & Project Manag.
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 zł. The problem can be solved by acquiring an Internet-based system, e-Member, allowing updating address data by Internet.
Functional Requirements (46)
Requirements Eng. & Project Manag.
1.3 Definitions, acronyms and abbreviations
ASAP – As Soon As PossibleExplorer – see MS Explorer...MS Explorer – Microsoft’s product that allows reading web pagesNIP – Tax identification number in Poland (in Polish „Numer
identyfikacji podatkowej”)PWA – Polish Writers Associations
Alphabetic order!
Functional Requirements (47)
Requirements Eng. & Project Manag.
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 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.
Functional Requirements (48)
Requirements Eng. & Project Manag.
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.
Functional Requirements (49)
Requirements Eng. & Project Manag.
SRS Structure
1. Introduction2. Overall description of the product
2.1 Product perspective (context)2.2 User characteristics2.3 Main product functions2.4 Constraints2.5 Assumptions and dependencies
3. Functional requirements4. Non-functional requirementsAppendicesIndex
IEEE Std 830-1998
Functional Requirements (50)
Requirements Eng. & Project Manag.
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.
E-MemberMember
Board
PolCard
Functional Requirements (51)
Requirements Eng. & Project Manag.
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.
Functional Requirements (52)
Requirements Eng. & Project Manag.
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.
Functional Requirements (53)
Requirements Eng. & Project Manag.
2.4 Constraints
The system must obey requlations imposed by the Polish act concerning personal data [personal-data-act].
Functional Requirements (54)
Requirements Eng. & Project Manag.
2.5 Assumptions and dependencies
The presented requirements are based on requlations known as of 1 September 2005.
Functional Requirements (55)
Requirements Eng. & Project Manag.
SRS Structure
1. Introduction2. Overall description of the product3. 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 mail4. Non-functional requirementsAppendicesIndex
IEEE Std 830-1998
Functional Requirements (56)
Requirements Eng. & Project Manag.
A Use CaseUpdating the dataUpdating the data
ActorActor: MemberGoalGoal: Update personal data.Main scenarioMain scenario1. Member enters his account and password.2. System presents the personal web page.3. Member selects the update option.4. System presents the personal data ready for update.5. Member changes the data.6. System asks for acknowledgement.7. Member confirms the changes. ExtensionsExtensions1a.1a. Account or password is incorrect. 1a1.1a1. System presents a message and returns to Step 1.
Functional Requirements (57)
Requirements Eng. & Project Manag.
Summary
• Earlier approaches to FR• Use cases• If-then considered harmful• Use-case patterns• Use cases and IEEE 830
Functional Requirements (58)
Requirements Eng. & Project Manag.
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?
Functional Requirements (59)
Requirements Eng. & Project Manag.
Functional Requirements (60)
Requirements Eng. & Project Manag.
Functional Requirements (61)
Requirements Eng. & Project Manag.
Thank you for your attentionThank you for your attention!!