IS550: Software requirements engineering Dr. Azeddine Chikh 2. Functional requirements styles

IS550: Software requirements engineering

Dr. Azeddine Chikh

2. Functional requirements styles

Soren Lauesen, "Software Requirements: Styles & Techniques"Addison-Wesley Professional 2002, 608 pp, ISBN-10: 0201745704 - ISBN-13: 9780201745702

Text

0. Introduction

3

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

In contrast, functional requirements specify what data is to be used for, how it is recorded, computed transformed, updated, transmitted, etc.

The user interface is in most systems as an important part of the functions because many data are recorded, updated and shown through it.

1. Human / computer – who does what ?

4

Domain model : humans and computers united

Physical model: what each of them do

Product requirements divide the work

A pervading issue is how the works divided between human and computer

The division is not given in advance, but is decided more or less through the requirements


5

What should we specify as functional requirements to the product ? The functions the product should have, for example, the screens we want ? If we do this, then we have chosen the division of labor.

That is a huge responsibility to the requirements engineer

We should either do it very carefully at requirements time, or we should avoid specifying product functions until design time

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


2. Context diagrams (CD)

7

What is this ? A diagram of the product and its surroundings It shows the scope of the product It is important but often overloaded

Advantages of CDs Verification. The CD gives developers an over-view of

the interfaces and serves as a high level checklist over what to develop.

Validation. Most customers can readily understand the CD, spot missing interfaces and discuss what is to be delivered and what is outside the product

Hotelsystem

Guest

Accountsystem

confirmation,invoice

booking,checkout,service note,. . .

R1: The product shall have the following interfaces: Recep-

tionist Telephonesystem

Hotelsystem

Guest

Accountsystem

Accountant

Waiter

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

ReceptionRecep-tionist

2. Context diagrams

3. Event list & function list (EL&FL)

9

What is this ? Events to be handled by the product (or a list of product

functions). Events to be handled by human + computer (or a list of user

tasks). Product events are design-level issues

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.

An event list shows the types of events that can arrive at the system. Since an event causes the system to perform a function, we can make a similar list of the functions that the system can perform


10

Domain events Domain events arrive to the domain from the surroundings.

Sometimes domain events are called business events or triggers.

Domain-level requirements. The requirements are that the product shall support the various domain events or tasks. It is left to the developer to design the necessary product events and product functions.

Product events Product events arrive at the product from the domain. Product -level requirements. The requirements are that the

product shall handle the various events or provide the various functions.


11

User-interface versus technical interface For human-computer interfaces, the list of functions is reasonable

as a product-level requirement, while a detailed list of product events is a design-level requirement.

For technical interfaces to other products, the detailed list of product events may be highly important. The reason is that in this case, the product events are determined by an existing system, whereas for the user interface, they have to be determined during system design.

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



13

Advantages of EL&FL Verification. Developers ca easily check that each event/function on

the list is supported or implemented Validation. Customers can to some extent validate the domain-level

lists of events and tasks. However, they may find it difficult to check whether all events are included. One of the problems is that there are many variants of each event or activity.

Analysts can make a consistency check to see that the lists are logically complete. They compare the lists against the data model : Is there an event / function that can Create, Read, Update, and Delete each entity in the data model ? If not, some event or function is probably missing. The check can made on the domain level as well as the product level


14

Disadvantages of EL&FL The event list for the user interface is a design issue. Make it only if

you need design-level requirements. If you want a commercial product, the list will be useless since the product has defined its own events already.

Customers cannot usually validate the list of product events and functions. Unfortunately, they are often asked to do so. Customers can better validate the list of domain events and tasks.

4. Feature requirements (FR)

15

What is this ? Text form : the product shall record /show/compute … Many people believe that this is the only acceptable type of

requirement Can lead to a false sense of security for user and analyst. It is difficult to ensure that users are adequately supported

and business goals covered

R1: The product shall be able to record that a room is occupied for repair in a specified period.

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.

In order to handle group tours with several guests, it is convenient to prepare for arrival by printing out a sheet per guest for the guest to fill in.

4. Feature requirements


17

Advantages of FRs Validation. Customers love features. They use the

customer’s language. Verification. It is straightforward to check that all the features

are implemented in the final product.


18

Disadvantages of FRs It is a problem that features are easy to formulate, because

customers may dream up so many features that the whole system becomes unrealistic.

If the customer expects to select a COTS-based system, for instance during a tender process, he may be tempted to write down the features of one particular system that he knows. This will favor the supplier of this particular system although other suppliers might have better solutions to his real problems

Validation. Although the customer readily understands the features, he has great difficulties in checking that the features allow him to reach his business goals.

5. Screens and prototypes

19

What is this ? Screens pictures and what the “buttons” do Excellent as design-level requirements if carefully tested Not suited for COTS-based systems

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

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



22

Advantages of screens as requirements Validation : the customer can ensure that the screens are

able to support the tasks and provide high usability. However, it is not enough to review the screens. Task analysis and usability tests have to be made.

Verification : it is straightforward to verify that the final user interface is as specified. Experience shows, however, that it is a good idea to repeat the usability test with the final product. Some problems may have crept in during development, for instance that the creative screen designer introduced flashing fields or fancy colors that make the screens less useful than in the prototype, or that the system response time is inadequate.


23

Disadvantages of screens as requirements Don’t use this requirements style when the product under

consideration is a commercial product – with or without modifications.

If the tasks are not well defined or the scope of the entire product is dubious, it is much too early to design screens and use them as requirements. However, prototypes may be very useful to help illustrate the various the various possibilities.

If screen design is not suitable for one reason or another, we recommend that task descriptions to be used as requirements

6. Task descriptions

24

What is this ? Structured text describing user tasks Easy to understand for user as well as developer Easy to specify variants and complexity Simple to verify Domain-level requirements –also suited to COTS A task is what user and product do together to achieve some

goal A use case is mostly the product’s part of the task A human task is the user’s part of the task

Work area: 1. ReceptionService guests - small and large issues. Normally standing. Frequent interrupts. 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. Normally standing. Frequent interrupts. 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.. . .

Missingsub-task?


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



27

Advantages of task descriptions Validation is easier Trace to development Verification is straightforward Intuitive understanding of the domain level Suitable for COTS Task specifications can specify complexity and many

variants in little space Disadvantages of task descriptions

No data specified Non-task activities Design is harder

7. Features from task descriptions

28

What is it ? Product features explained by means of task descriptions Improves understanding and validation of the features You can rarely guess user tasks from the features

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.

7. Features from task descriptions

8. Tasks & Support

30

What is it ? Structured text describing tasks, domain problems, and

possible support for them Identifies critical issues Discusses product features in a structured way Easy to understand for user as well as developer Easy specification of variants and complexity Simple to verify Domain-level requirements –also suited to COTS

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.

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

8. Tasks & Support

Advantages

• Easy to understand what customer wants

• Possible to specify advantages of our solution

• Convincing demonstration at contract time

• Equal opportunities

• Adjust ambitions

• Tracing possible: reqs business goals

Disadvantages

• Data-weak: Yes, use data descriptions too

• Non-task activities: Yes, how?

• Quality reqs: Partly related

• Unusual reply format: Yes

• More work for developer? Yes: User interface design!

• More work for customer?

8. Tasks & Support

9. Scenarios

33

What is it ? A case story illustrating one or more user tasks, or a specific

case to be tested Improves developer intuition Attractive but not requirements

In UML: A scenario (case scenario) is an instantiation of a use case

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.

9. Scenarios

10. Good tasks

35

Highlights Closed task = meaningful user goal Check that you have identified all tasks Bundle small, related tasks Don’t program the user dialog

Good tasks:• Closed: goal reached, pleasant feeling• Session: Small, related tasks in one description• Don’t program

Examples:1 Manage rooms?2 Book a guest?3 Enter guest name?4Check in a bus of tourists5Change the guest’s address etc?6 Change booking?7 Cancel entire booking?

Frequentmistake

Got them all?• All events covered?• Critical tasks covered?• At least as good as before?• CRUD check

How to dealwith that?

10. Good tasks

11. High level tasks

37

What is it ? Total business cases as seen by the clients Independent of existing user tasks Idea generating – business process re-engineering (BPR) Rarely used as requirements

Sub-tasks:

1. Select a hotel.Problem: We aren’t visible enough.

2. Booking.Problem: Language and time zones. Guest wants two neighbor rooms

3. Check in.Problem: Guests want two keys

4. Receive service

5. Check outProblem: Long queue in the morning

6. Reimburse expensesProblem: Private services on the bill

Example solution:

?

Web-booking.Choose rooms on web at a fee.

Electronic keys.

Use electronic key for self- checkout.

Split into two invoices, e.g. through room TV.

Task: 1. A stay at the hotelActor: The guestPurpose: . . .

11. High level tasks

12. Use cases

39

Highlights Widely used styles Some styles are good for designing user dialogs Most ignore the user’s part of the tasks Not suitable as requirements for COTS-based projects

A use case is a sequence of related messages exchanged among the system and outside actors, together with actions performed by the system

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

12. Use cases

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)

12. Use cases

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

12. Use cases

Human and/or computer

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

12. Use cases

12. Use cases

44

Advantages of use cases The UML use case diagrams may be used as top-level

checklists for what to specify further and what to develop.This may support validation as well as verification. Experts agree, however, that the diagrams should be supplemented with text-based versions.

Essential use cases have proven useful for designing theuser interface.

Disadvantages of use cases They say little about the data used in the tasks, and they cope

poorly with non-task activities.

13. Tasks with data

45

What is it ? Structured text describing user tasks and data need for each

sub-task Useful for screen design and tracing to development Difficult to validate

A common problem with all the previous use cases styles is that they don’t say much about the data needed to carry out the various sub-tasks.

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. Crit: kind, dates

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

1b. Guest booked Guest and stay details Stay. Crit: 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. Crit: name ...

3. Deliver key Room numbers Stay

13. Tasks with data

13. Tasks with data

47

Verification. Users can validate the data needs, but not reliably because the approach is abstract.

Trace to development. Tasks with data are excellent for deriving virtual windows or the final screens.

Verification. Checking is straightforward

14. Dataflow diagrams

48

What is it ? A bubble diagram showing functions, and data flowing

between the functions Compact specification of the needed data Good as an intermediate work product Useful as requirements for workflow applications

With dataflow diagrams, you can describe tasks in a technology-independent way what human and computer do together (the domain model). Or you can describe what the computer should do (the physical model).

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


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


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

Dataflow - product level

Current

Recordbooking

or checkin

Printconfirm

*) Find room = period + room type

room#



53

Advantages of DFD : useful for the following : Outlining user tasks in a graphical way Specifying communication between technical components Designing the new human activities in the domain Outlining the internal structure of the program Validation: Customers without an IT background can fairly

easily understand DFD, particularly those describing domain aspects.

Disadvantages of DFD : DFD are not suited to describing user tasks with many

variations They don’t support the problem-oriented or cost/benefit

oriented view covered by tasks and support.

15. Standards as requirements

54

What is it ? Text requirement : the product shall follow standard xx Transfers the problem to the supplier Sometimes leads to false sense of security An important type of the requirement

Some analysts (as well as IEEE830) call such requirements constraints

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.



56

Validation: Customers often rely on standards to ensure some unspecified goal. It is important to specify to specify the goal of the standard in each project to be able to check that the standard achieves the goal.

Verification: Some standards can be reasonably well verified before the system is put into operation.

16. Development process requirements

57

What is it ? A requirement to follow procedure xx to find the real

requirements The best way if real requirements are uncertain Management control and price formulas can limit the risks

Some analysts insist that such project specifications are not part of requirements , but part of the contract.

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?



59

Validation. Usually the customer has little understanding of how a process relates to the quality of the product. Most customers have little chance to validate that the process is adequate. However, the customer can validate the final requirements, and the purpose of the process is to support this.

Verification. Quite often developers commit to a specific process, yet go ahead and do something different. Verifying that the process is carried out is thus important. The customer should take some responsibility for this, for instance by participating in reviews or inspecting documents.

Documents

IS550: Software requirements engineering Dr. Azeddine Chikh 2. Functional requirements styles