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

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

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

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

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

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

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

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

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

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

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

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

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

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

20. 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 like those in App. xx. 5. Screens and prototypes

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

22. 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. 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 possibilities. If screen design is not suitable for one reason or another, we recommend that task descriptions to be used as requirements

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

25. 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 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.1 Booking Purpose:Reserve room for a guest. Task: 1.1 Booking Purpose:Reserve room for a guest. 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 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 Task: 1.3 Checkout Purpose:Release room, invoice guest.... Task: 1.3 Checkout Purpose:Release room, invoice guest.... Missing sub-task? 6. Task descriptions

26. Triggers, options, preconditions 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) 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:... 6. Task descriptions

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

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

29. Work area: 1. Reception The product is normally operated standing, and there are many interruptions. R1.1Product shall allow mouse-free operation. R1.2Product 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.3Product shall find free rooms of various types. R1.4Product shall record checkin and rooms occupied by that stay. R1.5Product shall collect pay information for the stay. R1.6Product 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.7Product shall print registration forms in advance for group stays. 7. Features from task descriptions

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

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

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

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

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

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

36. Good tasks: Closed: goal reached, pleasant feeling Session: Small, related tasks in one description Don’t program Examples: 1Manage rooms? 2Book a guest? 3Enter guest name? 4Check in a bus of tourists 5Change the guest’s address etc? 6Change booking? 7Cancel 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? 10. Good tasks

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

38. 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. Task:1. A stay at the hotel Actor:The guest Purpose:... 11. High level tasks

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

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

41. Human and/or computer Human and computer separated Use case: Check in a booked guest User actionSystem 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) 12. Use cases

42. 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 12. Use cases Human and/or computer

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

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

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

46. 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 dataVirt. windows 1.Find roomFree rooms of kind x, priceRooms. Crit: kind, dates 1a. No suitable roomAll free rooms,Rooms. Crit: dates price, discount 1b.Guest booked Guest and stay detailsStay. Crit: name... 2.Record guest Guest detail, chosen roomStay, Rooms as checked in 2a.Guest recorded Guest and stay detailsStay at booking 2b.RegularcustomerGuest detail, chosen roomRooms, Stay. Crit: name... 3.Deliver keyRoom numbersStay 13. Tasks with data

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

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

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

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

51. Dividing the work Booking request Rooms Guests Booking request UserProduct choice period+room type FindFreeRoom free rooms Current room# UserProd. UserProd. Guest data + chosen room Record Booking Record Guest 14. Dataflow diagrams

52. The product shall handle the events as follows: Find room *) FindFree Room Record Booking OrCheckin Print Confirm Record guest Find guest Record Guest Find Guest GuestsRooms Dataflow - product level Current Record booking or checkin Print confirm *) Find room = period + room type room# 14. Dataflow diagrams

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

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

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

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

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

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

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