IS550: Software requirements engineering

IS550: Software requirements engineering • 3. Functional requirements styles Dr. Azeddine Chikh

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

0. Introduction • 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 ? • 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 ? • 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

Physical model: work split FindFreeRoom guest’s wishes period+room type User Product free rooms choice guest name chosen room# Rooms 1. Human / computer – who does what ? Domain model: parties joined guest’s wishes FindFree Room guest name + chosen room# Rooms

2. Context diagrams (CD) • 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

R2 ??: The reception domain communicates with the surroundings in this way: Recep- tionist Reception Hotel system Account system Accountant Waiter Guest 2. Context diagrams Hotel system Account system R1: The product shall have the following interfaces: booking, checkout, service note, . . . confirmation, invoice Recep- tionist Telephone system Guest

3. Event list & function list (EL&FL) • 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) • 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) • 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.

Domain-product: many-to-many 3. Event list & function list (EL&FL) Product events Domain events (business events) R2: The product shall handle the following events / The product shallprovide the following functions: User interface: R2.1 Find free room R2.2 Record guest R2.3 Find guest R2.4 Record booking R2.5 Print confirmation R2.6 Record checkin R2.7 Checkout R2.8 Record service Accounting interface: R2.9 Periodic transfer of account data . . . R1: The product shall support the following business events / user activities / tasks: R1.1 Guest books R1.2 Guest checks in R1.3 Guest checks out R1.4 Change room R1.5 Service note arrives . . .

3. Event list & function list (EL&FL) • 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) • 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) • 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

4. Feature requirements 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 • 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 • 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 • What is this ? • Screens pictures and what the “buttons” do • Excellent as design-level requirements if carefully tested • Not suited for COTS-based systems

The customer imagines screens like those in App. xx. 5. Screens and 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?

5. Screens and prototypes Appendix xx. Required screens Appendix yy. Required functions Stay window Book: . . . 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 • 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 • 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 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 • 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

6. Task descriptions Task: 1.1 Booking Purpose: Reserve room for a guest. Work area: 1. Reception Service 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.2 Checkin Purpose: Give guest a room. Mark it as occupied. Start account. Trigger/ Precondition: A guest arrives Frequency: Average 0.5 checkins/room/day Critical: Group tour with 50 guests. Sub-tasks: 1. Find room 2. Record guest as checked in 3. Deliver key Variants: 1a. Guest has booked in advance 1b. No suitable room 2a. Guest recorded at booking 2b. Regular customer Missing sub-task? Task: 1.3 Checkout Purpose: Release room, invoice guest. . . .

Task: Change booking Purpose: . . . Precondition: Guest has booked? Trigger: Guest calls . . . Sub-tasks: 1. Find booking 2. Modify guest data, e.g. address (optional) 3. Modify room data, e.g. two rooms (optional) 4. Cancel booking (optional) 6. Task descriptions Task: Look at your new e-mails Purpose: 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: . . . Triggers, options, preconditions

6. Task descriptions • 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 • 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

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 in advance for group stays.

8. Tasks & Support • 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

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 8. Tasks & Support Task: 1.2 Checkin Purpose: Give guest a room. Mark it . . . Trigger: A guest arrives Frequency: . . . 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. Past: Problems Domain level

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?

9. Scenarios • 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

9. Scenarios 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. Vivid scenario

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

10. Good tasks 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? • Check in a bus of tourists • Change the guest’s address etc? • 6 Change booking? • 7 Cancel entire booking? Frequent mistake • Got them all? • • All events covered? • • Critical tasks covered? • • At least as good as before? • CRUD check How to deal with that?

11. High level tasks • 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

11. High level tasks Task: 1. A stay at the hotel Actor: The guest Purpose: . . . 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 out Problem: Long queue in the morning 6. Reimburse expenses Problem: 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.

12. Use cases • 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

12. Use cases Human and computer separated: Task descriptions. Split postponed: Hotel system Hotel system Booking Account system Booking Transfer . . . . . . UML use case diagram: Hotel system Booking actor Checkin Receptionist Checkout Account system Transfer actor Use cases vs. tasks

12. Use cases Human and computer separated Use case: Check in a booked guest User action System action Enter booking number Show guest and booking details Edit details (optional) Store modifications Push checkin Allocate free room(s) Display room number(s) Give guest key(s) Human and/or computer

12. Use cases Computer-centric use case Use case: Check in a booked guest Trigger: Receptionist selects check in Read booking number Display guest and booking details Read and store modifications Wait for checkin command Select free room(s) Mark them as occupied Add them to guest details Display room number(s) End use case Human and/or computer

12. Use cases Select checkin Read booking number Retrieve booking Display error message [not found] Activity diagram for first part of checkin [found] Display guest and booking details Read and store modifications Detailed product activities

12. Use cases • 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 the user 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 • 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.

13. Tasks with data Task: 1.2 Checkin Purpose: Give guest a room. Mark it as occupied. Start account. Trigger: Guest arrives Frequency: Average 0.5 checkins/room/day Critical: 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: dates price, discount 1b. Guest booked Guest and stay details Stay. Crit: name ... 2. Record guest Guest detail, chosen room Stay, Rooms as checked in 2a. Guest recorded Guest and stay details Stay at booking 2b. Regular customer Guest detail, chosen room Rooms, Stay. Crit: name ... 3. Deliver key Room numbers Stay

13. Tasks with data • Validation. 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 • 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).

Checkin request, booked Checkin request, non-booked Checkin, booked Checkin, non-booked Transfer Account system 14. Dataflow diagrams R1: The product shall support these activities? Booking request Booking guest data Data expression: Booking request = guest data + period + room type guest data = guest name + address + pay method Guests period+room# Rooms Confirmation Dataflow - domain model

Checkin request, booked Checkin request, non-booked Find Guest FindFree Room Record Guest Record Checkin 14. Dataflow diagrams Booking request FindFree Room Booking request + room# Guests Record Guest room list Send Confirm Record Booking Rooms Data description: Booking request = guest data + period + room type Domain model, second level

IS550: Software requirements engineering