Upload
leo-riley
View
223
Download
2
Tags:
Embed Size (px)
Citation preview
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
1. Human / computer – who does what ?
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
1. Human / computer – who does what ?
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
3. Event list & function list (EL&FL)
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.
3. Event list & function list (EL&FL)
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. . .
3. Event list & function list (EL&FL)
3. Event list & function list (EL&FL)
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
3. Event list & function list (EL&FL)
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
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.
4. Feature requirements
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.
5. Screens and prototypes
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, . . .
5. Screens and prototypes
5. Screens and prototypes
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.
5. Screens and prototypes
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?
6. Task descriptions
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: . . .
6. Task descriptions
6. Task descriptions
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
14. Dataflow diagrams
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
14. Dataflow diagrams
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
14. Dataflow diagrams
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#
14. Dataflow diagrams
14. Dataflow diagrams
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.
15. Standards as requirements
15. Standards as requirements
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?
16. Development process requirements
16. Development process 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.