Functional Requirements

Functional Requirements

Jerzy [email protected]

Requirements Eng. & Project Manag.

Functional Requirements (2)


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• Use cases and IEEE 830



Agenda




Requirement in RequisitePro

• name (tag), • text, • attributes

Rational RequisitePro



Attribute Matrix in RequisitePro

Tag

Full text

Short text Attribute Attribute



Lost rationale

Do we need a givenfunctionality?



Agenda




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/



Use Case Diagram in UML

Construct itinerary

Merchant bank

Find flight

Travel agent

Airline reservationReserve

flight

Issue ticket



Use case

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



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.



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





Updating personal data





Updating personal dataMember






Member enters his account and password






Member enters his account and password

Account or password is incorrect



Use cases

The same goal

Scenario #1

Scenario #2

Scenario #3

A use caseMain scenario:1. Step2. StepExtensions:1a. Event 1a1. Alternative step



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.



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



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



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: . . .



Agenda




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.



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



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 ...

















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)



Agenda




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.



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



Use case patterns

Behaviour description

Use cases are for behavioural description. User interface should be described elsewhere.











Use case patterns

Actor Intention Accomplished

Write each step to show clearly which actor is performing the action, and what the actor gets accomplished.



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. . . .



Use case patterns

Use case length

A use case should have from 3 to 9 steps.



Agenda




Software Requirements Specification

1. Introduction2. Overall description of the product3. Functional requirements4. Non-functional requirementsAppendicesIndex

IEEE Std 830-1998



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



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.



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.



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!



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.



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.



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



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



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.



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.



2.4 Constraints

The system must obey requlations imposed by the Polish act concerning personal data [personal-data-act].



2.5 Assumptions and dependencies

The presented requirements are based on requlations known as of 1 September 2005.



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



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.



Summary




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?







Thank you for your attentionThank you for your attention!!

Documents

Functional Requirements