slides for software requirements styles and techniques soren lauesen 3. functional requirement...

Slides for

Software requirements Styles and techniques

Soren Lauesen

3. Functional requirement styles

August 2006

© 2002, Pearson Education retains the copyright to the slides, but allows restricted copying for teaching purposes only. It is a condition that the source and copyright notice is preserved on all the material.

Introduction

• Data requirements specify the data to be stored in the system.

• Functional requirements specify what data is to be used for, how it is recorded, computed, transformed, etc.

Fig 2.1 The hotel system

Task listBook guestCheckinCheckoutChange roomBreakfast list &other services

Data aboutGuestsRoomsServices

From: Soren Lauesen: Software Requirements© Pearson / Addison-Wesley 2002

Human-computer - who does what?

• Domain model: humans and computers united• Physical model: what each of them do

Fig 3.1 Human-computer - who does what?

FindFreeRoom

guest’swishes

Roomsguest name+ chosen room#

Domain model:parties joined

guest’swishes

Rooms

guest name

User Product

choice

period+room type

FindFreeRoom

free rooms

chosen room#

Physical model:work split


Context diagram

• A diagram of the product and its surroundings (user groups and external systems) .

• It shows the scope of the product.

• It is useful to outline a context diagram early in the project and keep it updated during analysis.

Hotelsystem

Guest

Accountsystem

Fig 3.2 Context diagram

confirmation,invoice

booking,checkout,service note,. . .

R1: The product shall have the following interfaces: Receptionist

Telephonesystem


Hotelsystem

Guest

Accountsystem

Accountant

Waiter

R2 ??:The reception domain communicates with the surroundings in this way:

ReceptionRecep-tionist

Context diagram

• Advantages:– Validation– Verification

Event list & function list

• An event is something that requests a system to perform some function.

• Usually an event arrives with some data telling the system what to do.

• Since an event causes the system to perform a function, we can make a similar list of the functions that the system can perform.

Event list & function list

• Domain events arrive to the domain from the surroundings ( sometimes called business events or triggers).

• Product events arrive at the product from the domain.

Fig 3.3 Event list & function list

R1: The product shall support the following businessevents / user activities / tasks:

R1.1 Guest booksR1.2 Guest checks inR1.3 Guest checks outR1.4 Change roomR1.5 Service note arrives

. . .

Product eventsDomain events(business events)

Domain-product:many-to-many

R2: The product shall handle the following events / The product shall provide the following functions:

User interface:R2.1 Find free roomR2.2 Record guestR2.3 Find guestR2.4 Record bookingR2.5 Print confirmationR2.6 Record checkinR2.7 CheckoutR2.8 Record service

Accounting interface:R2.9 Periodic transfer of account

data. . .


Feature requirements

• A feature is one or more related product functions and related data.

• Another definition: a service the system provides to fulfill one or more stakeholder needs

Fig 3.4 Feature requirements

R1: …..

R2: The product shall be able to show and print a suggestion for staffing during the next two weeks based on historical room occupation. The supplier shall specify the calculation details.

R3: The product shall be able to run in a mode where rooms are not booked by room number, but only by room type. Actual room allocation is not done until checkin.

R4: The product shall be able to print out a sheet with room allocation for each room booked under one stay.


Screens & prototypes

• Screen pictures and what the “buttons” do.

• Excellent as deign-level requirements if carefully tested.

• Not suited for COTS-based systems.

Fig 3.5A Screens & prototypes

R1: The product shall use the screen pictures shown in App. xx.

R2: The menu points and buttons shall work according to the process description in App. yy.Error messages shall have texts as in . . .

R3: Novice users shall be able to perform task tt on their own in mm minutes.

Certificate: The requirements engineer

has usability tested this design according

to the procedures in App. zz.

Makes sense?


The customer imagines screens likethose in App. xx.

Appendix xx. Required screensAppendix xx. Required screens

Fig 3.5B Screens & prototypes

Appendix yy. Required functions

Stay windowBook: . . .Checkin:If stay is booked, record the

booked rooms as occupied.If stay is not recorded,

Check selected rooms free and guest information complete.Record guest and stay. Record selected rooms as occupied.

If stay is checked in, . . .

Appendix yy. Required functions

Stay windowBook: . . .Checkin:If stay is booked, record the

booked rooms as occupied.If stay is not recorded,

Check selected rooms free and guest information complete.Record guest and stay. Record selected rooms as occupied.

If stay is checked in, . . .


Task descriptions

• Structured text describing user tasks.• Easy to understand for user as well as developer.• Easy to verify.• Domain level requirements- also suited to COTS

Fig 3.6A Task descriptions

Work area: 1. ReceptionService guests - small and large issues. Often alone, e.g. during night.

Users: Reception experience, IT novice.

R1: The product shall support tasks 1.1 to 1.5

Work area: 1. ReceptionService guests - small and large issues. Often alone, e.g. during night.

Users: Reception experience, IT novice.

R1: The product shall support tasks 1.1 to 1.5

Task: 1.1 BookingPurpose: Reserve room for a guest.

Task: 1.1 BookingPurpose: Reserve room for a guest.

Task: 1.2 CheckinPurpose: Give guest a room. Mark it

asoccupied. Start account.

Trigger/Precondition: A guest arrivesFrequency: Average 0.5

checkins/room/dayCritical: Group tour with 50 guests.

Sub-tasks:1. Find room2. Record guest as checked in3. Deliver key

Variants:1a. Guest has booked in advance1b. No suitable room2a. Guest recorded at booking2b. Regular customer

Task: 1.2 CheckinPurpose: Give guest a room. Mark it

asoccupied. Start account.

Trigger/Precondition: A guest arrivesFrequency: Average 0.5

checkins/room/dayCritical: Group tour with 50 guests.

Sub-tasks:1. Find room2. Record guest as checked in3. Deliver key

Variants:1a. Guest has booked in advance1b. No suitable room2a. Guest recorded at booking2b. Regular customerTask: 1.3 Checkout

Purpose: Release room, invoice guest.. . .

Task: 1.3 CheckoutPurpose: Release room, invoice guest.. . .


Fig 3.6B Triggers, options, preconditions

Task: Change bookingPurpose: . . .Precondition: Guest has booked?Trigger: Guest calls. . .

Sub-tasks:1. Find booking2. Modify guest data, e.g. address (optional)3. Modify room data, e.g. two rooms (optional)4. Cancel booking (optional)

Makessense?

Task: Look at your new e-mailsPurpose: Reply, file, forward, delete,

handle later.Trigger: A mail arrives.

- Someone asks you to look.- You have been in a meeting and

are curious about new mail.Frequency: . . .


Fig 3.7 Features from task descriptions

Work area: 1. Reception

The product is normally operated standing, and there are many interruptions.

R1.1 Product shall allow mouse-free operation.R1.2 Product shall support switching between incomplete tasks.

The product must support checkin, i.e. the guest must get a room and a key, and accounting must start.

R1.3 Product shall find free rooms of various types.R1.4 Product shall record checkin and rooms occupied by that stay.R1.5 Product shall collect pay information for the stay.R1.6 Product shall provide electronic keys.

It may take too long time to check in a bus of pre-booked guests if they are checked in one by one.

R1.7 Product shall print registration forms inadvance for group stays.


Sub-tasks:

1. Find room.Problem: Guest wants neighbor rooms; price bargain.

2. Record guest as checked in.

3. Deliver key.Problem: Guest forgets to return the key; guest wants two keys.

Variants:

1a. Guest has booked in advance.Problem: Guest identification fuzzy.

Fig 3.8A Tasks & Support

Task: 1.2 CheckinPurpose: Give guest a room. Mark it . . .Trigger: A guest arrivesFrequency: . . .

Example solution:

System shows free rooms on floor maps. System shows bargain prices, time and day dependent.

(Standard data entry)

System prints electronic keys. New key for each customer.

System uses closest match algorithm.

Future:Computer part

Past: Problems

Domainlevel

From: Soren Lauesen: Software Requirements. © Pearson / Addison-Wesley 2002

Fig 3.8B Hospital roster planningTask 1.2 Make rosterGoal Staff all duties. Ensure regulations . . . Ensure low costFrequency Once every two weeks. In some departments . . .Critical Vacation periods . . .Sub-tasks: Example of solution:1 Initialize new roster period System generates roster for new period based on . . .2 Record staff leave

Two kinds of leave: . . .

Present problems: Leave requestskept on manual notes, often monthsinto the future.

System can record leave one year into the future.System warns if leave is against regulations. It mustbe easy to record a long period of leave (severalmonths).

3 Allocate staff for unstaffed duties.Ensure level of competence,regulations, leave days, and low cost.

Present problems: Difficult to ensurethis manually. Costs are higher thannecessary and errors occur.

System shows unstaffed duties and suggestions forstaffing. User selects the actual staff. System warns ifduties are unstaffed, leave or regulations violated, orcost unnecessary. Warnings must be immediate tosupport the "jigsaw puzzle".System supportsextensive undo and several temporary versions.

4 Send roster for review A print of the roster is sufficient.5 Modify roster The steps above suffice6 Authorize roster . . .Variants: Example of solution:3a Staff not yet recorded in the staff

fileUser enters preliminary data for new staff.

3b No staff available

Present problem: No informationabout staff in other departments

System suggests staff from other departments basedon their authorized rosters.

Fig 3.9 Vivid scenario

Scenario: The evening duty

Doug Larsson had studied all afternoon and was a bit exhausted when arriving 6 pm to start his turn in the reception. The first task was to prepare the arrival of the bus of tourists expected 7 pm. He printed out all the checkin sheets and put them on the desk with the appropriate room key on each sheet.

In the middle of that a family arrived asking for rooms. They tried to bargain and Doug always felt uneasy about that. Should he give them a discount? Fortunately Jane came out from the back office and told them with her persuading smile that she could offer 10% discount on the children’s room. They accepted, and Doug was left to assign them their rooms. They wanted an adjoining room for the kids, and as usual he couldn’t remember which rooms were neighbors.

Around 10 pm, everything was quiet, and he tried to do some of his homework, but immediately became sleepy. Too bad - he wasn’t allowed to sleep at work until 1 AM. Fortunately the office computer allowed him to surf the net. That kept him awake and even helped him with some of his homework.


Fig 3.12A Use cases vs. tasks

Hotel system

Booking

Checkin

CheckoutReceptionist

Accountsystem

UML use casediagram:

Transferactor

actor

Human and computer separated:

Hotel system

. . .

Booking

Hotel system

Booking

. . .

Task descriptions. Split postponed:

Accountsystem

Transfer


Fig 3.12B Human and/or computer

Human and computer separated

Use case: Check in a booked guest

User action System actionEnter booking number

Show guest and booking detailsEdit details (optional)

Store modificationsPush checkin

Allocate free room(s)Display room number(s)

Give guest key(s)


Computer-centric use case

Use case: Check in a booked guest

Trigger: Receptionist selects check in

Read booking numberDisplay guest and booking detailsRead and store modificationsWait for checkin commandSelect free room(s) Mark them as occupiedAdd them to guest detailsDisplay room number(s)

End use case


Fig 3.12C Detailed product activities

Select checkin

Read bookingnumber

Retrievebooking

Display guest andbooking details

Display errormessage

Read and storemodifications

[not found]

[found]Activity diagram for first part of checkin


Fig 3.13 Tasks with Data

Task: 1.2 CheckinPurpose: Give guest a room. Mark it as occupied. Start account.Trigger: Guest arrivesFrequency: Average 0.5 checkins/room/dayCritical: Group tour with 50 guests.

Sub-tasks: Visible data Virt. windows

1. Find room Free rooms of kind x, price Rooms: kind, dates

1a. No suitable room All free rooms, Rooms : datesprice, discount

1b. Guest booked Guest and stay details Stay: name ...

2. Record guest Guest detail, chosen room Stay, Roomsas checked in

2a. Guest recorded Guest and stay details Stayat booking

2b. Regular customer Guest detail, chosen room Rooms, Stay : name ...

3. Deliver key Room numbers Stay


Fig 3.14A Dataflow - domain model

R1: The product shall support these activities?

Bookingrequest

Booking

Rooms

GuestsData expression:Booking request =

guest data + period +room type

guest data =guest name +address + pay method

Checkinrequest,

non-booked

Checkin,non-booked

Checkinrequest,booked

Checkin,booked

period+room#

guest data

ConfirmationTransfer

Accountsystem


Fig 3.14B Domain model, second level

Bookingrequest

FindFreeRoom

RecordBooking

SendConfirm

RecordGuest

Rooms

Guests

Checkinrequest,booked

FindGuest

RecordCheckin

Checkinrequest,

non-booked

FindFreeRoom

RecordGuest

Data description:Booking request =

guest data + period + room type

Booking request+ room#

room list


Fig 3.14C Dividing the work

Bookingrequest

Rooms

Guests

Bookingrequest

User Product

choice

period+room type

FindFreeRoom

free rooms

Current

room#

User Prod.

User Prod.

Guest data

+ chose

n room

RecordBooking

RecordGuest


The product shall handle the events as follows:

Findroom *)

FindFreeRoom

RecordBooking

OrCheckin

PrintConfirm

Recordguest

Findguest

RecordGuest

FindGuest

GuestsRooms

Fig 3.14D Dataflow - product level

Current

Recordbooking

or checkin

Printconfirm

*) Find room = period + room type

room#


Fig 3.15 Standards as requirements

R1: Data transfer to the account package shall be done through a file with the format described in WonderAccount Interface Guide xx.yy. The account numbers shall be . . .

R2: The user interface shall follow MS Windows Style Guide, xx.yy. The MS Word user interface should be used as a model where appropriate.

R3: Shall run under MS-Windows release xx.yy. Supplier shall port product to new releases within ______ months.

R4: Shall follow good accounting practice. The supplier shall obtain the necessary certification.

R5: The supplier shall update the payroll computations in accordance with new union agreements within one month after release of the agreement.


Fig 3.16 Development process as requirement

R1: System development shall use iterative development based on prototypes as described in App. xx.

R2: Supplier shall deliver additional screens with a complexity like screen S3 at a price of $____ per screen.

R3: All developers shall spend at least two days working with the users on their daily tasks.

R4: A special review shall be conducted at the end of each development activity to verify that all requirements and system goals are duly considered. The customer’s representative shall participate in the review.

R5: Customer and supplier shall meet at least two hours bi-weekly to review requests for change and decide what to do, based on cost/benefit estimates of the changes.

Generates new

requirements?


slides for software requirements styles and techniques soren lauesen 3. functional requirement...

Documents