Presentation is loading. Please wait.

Presentation is loading. Please wait.

Slides for Software requirements Styles and techniques Soren Lauesen 3. Functional requirement styles August 2006 © 2002, Pearson Education retains the.

Similar presentations


Presentation on theme: "Slides for Software requirements Styles and techniques Soren Lauesen 3. Functional requirement styles August 2006 © 2002, Pearson Education retains the."— Presentation transcript:

1 Slides for Software requirements Styles and techniques Soren Lauesen 3. Functional requirement styles August 2006 © 2002, Pearson Education retains the copyright to the slides, but allows restricted copying for teaching purposes only. It is a condition that the source and copyright notice is preserved on all the material.

2 Introduction Data requirements specify the data to be stored in the system. Functional requirements specify what data is to be used for, how it is recorded, computed, transformed, etc.

3 Fig 2.1 The hotel system Task list Book guest Checkin Checkout Change room Breakfast list & other services Data about Guests Rooms Services From: Soren Lauesen: Software Requirements © Pearson / Addison-Wesley 2002

4 Human-computer - who does what? Domain model: humans and computers united Physical model: what each of them do

5 Fig 3.1 Human-computer - who does what? 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 From: Soren Lauesen: Software Requirements © Pearson / Addison-Wesley 2002

6 Context diagram A diagram of the product and its surroundings (user groups and external systems). It shows the scope of the product. It is useful to outline a context diagram early in the project and keep it updated during analysis.

7 Hotel system Guest Account system Fig 3.2 Context diagram confirmation, invoice booking, checkout, service note,... R1: The product shall have the following interfaces: Receptionist Telephone system From: Soren Lauesen: Software Requirements © Pearson / Addison-Wesley 2002 Hotel system Guest Account system Accountant Waiter R2 ??: The reception domain communicates with the surroundings in this way: Reception Recep- tionist

8 Context diagram Advantages: –Validation –Verification

9 Event list & function list An event is something that requests a system to perform some function. Usually an event arrives with some data telling the system what to do. Since an event causes the system to perform a function, we can make a similar list of the functions that the system can perform.

10 Event list & function list Domain events arrive to the domain from the surroundings ( sometimes called business events or triggers). Product events arrive at the product from the domain.

11 Fig 3.3 Event list & function list 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 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.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... From: Soren Lauesen: Software Requirements © Pearson / Addison-Wesley 2002

12 Feature requirements A feature is one or more related product functions and related data. Another definition: a service the system provides to fulfill one or more stakeholder needs

13 Fig 3.4 Feature requirements R1:….. R2:The product shall be able to show and print a suggestion for staffing during the next two weeks based on historical room occupation. The supplier shall specify the calculation details. R3: The product shall be able to run in a mode where rooms are not booked by room number, but only by room type. Actual room allocation is not done until checkin. R4:The product shall be able to print out a sheet with room allocation for each room booked under one stay. From: Soren Lauesen: Software Requirements © Pearson / Addison-Wesley 2002

14 Screens & prototypes Screen pictures and what the “buttons” do. Excellent as deign-level requirements if carefully tested. Not suited for COTS-based systems.

15 Fig 3.5A Screens & prototypes R1:The product shall use the screen pictures shown in App. xx. R2:The menu points and buttons shall work according to the process description in App. yy. Error messages shall have texts as in... R3:Novice users shall be able to perform task tt on their own in mm minutes. Certificate: The requirements engineer has usability tested this design according to the procedures in App. zz. Makes sense? From: Soren Lauesen: Software Requirements © Pearson / Addison-Wesley 2002 The customer imagines screens like those in App. xx.

16 Appendix xx. Required screens Fig 3.5B Screens & prototypes 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,... From: Soren Lauesen: Software Requirements © Pearson / Addison-Wesley 2002

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

18 Fig 3.6A Task descriptions Work area: 1. Reception Service guests - small and large issues. Often alone, e.g. during night. Users: Reception experience, IT novice. R1:The product shall support tasks 1.1 to 1.5 Work area: 1. Reception Service guests - small and large issues. Often alone, e.g. during night. Users: Reception experience, IT novice. R1:The product shall support tasks 1.1 to 1.5 Task: 1.1 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.... From: Soren Lauesen: Software Requirements © Pearson / Addison-Wesley 2002

19 Fig 3.6B 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) Makes sense? Task:Look at your new s 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:... From: Soren Lauesen: Software Requirements © Pearson / Addison-Wesley 2002

20 Fig 3.7 Features from task descriptions 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. From: Soren Lauesen: Software Requirements © Pearson / Addison-Wesley 2002

21 Sub-tasks: 1.Find room. Problem: Guest wants neighbor rooms; price bargain. 2.Record guest as checked in. 3.Deliver key. Problem: Guest forgets to return the key; guest wants two keys. Variants: 1a.Guest has booked in advance. Problem: Guest identification fuzzy. Fig 3.8A Tasks & Support Task:1.2 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 From: Soren Lauesen: Software Requirements. © Pearson / Addison-Wesley 2002

22 Fig 3.8B Hospital roster planning

23 Fig 3.9 Vivid scenario Scenario: The evening duty Doug Larsson had studied all afternoon and was a bit exhausted when arriving 6 pm to start his turn in the reception. The first task was to prepare the arrival of the bus of tourists expected 7 pm. He printed out all the checkin sheets and put them on the desk with the appropriate room key on each sheet. In the middle of that a family arrived asking for rooms. They tried to bargain and Doug always felt uneasy about that. Should he give them a discount? Fortunately Jane came out from the back office and told them with her persuading smile that she could offer 10% discount on the children’s room. They accepted, and Doug was left to assign them their rooms. They wanted an adjoining room for the kids, and as usual he couldn’t remember which rooms were neighbors. Around 10 pm, everything was quiet, and he tried to do some of his homework, but immediately became sleepy. Too bad - he wasn’t allowed to sleep at work until 1 AM. Fortunately the office computer allowed him to surf the net. That kept him awake and even helped him with some of his homework. From: Soren Lauesen: Software Requirements © Pearson / Addison-Wesley 2002

24 Fig 3.12A 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 From: Soren Lauesen: Software Requirements © Pearson / Addison-Wesley 2002

25 Fig 3.12B 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) From: Soren Lauesen: Software Requirements © Pearson / Addison-Wesley 2002

26 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 From: Soren Lauesen: Software Requirements © Pearson / Addison-Wesley 2002

27 Fig 3.12C 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 From: Soren Lauesen: Software Requirements © Pearson / Addison-Wesley 2002

28 Fig 3.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 dataVirt. windows 1.Find roomFree rooms of kind x, priceRooms: kind, dates 1a. No suitable roomAll free rooms,Rooms : dates price, discount 1b.Guest booked Guest and stay detailsStay: 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 : name... 3.Deliver keyRoom numbersStay From: Soren Lauesen: Software Requirements © Pearson / Addison-Wesley 2002

29 Fig 3.14A 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 From: Soren Lauesen: Software Requirements © Pearson / Addison-Wesley 2002

30 Fig 3.14B 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 From: Soren Lauesen: Software Requirements © Pearson / Addison-Wesley 2002

31 Fig 3.14C 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 From: Soren Lauesen: Software Requirements © Pearson / Addison-Wesley 2002

32 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 Fig 3.14D Dataflow - product level Current Record booking or checkin Print confirm *) Find room = period + room type room# From: Soren Lauesen: Software Requirements © Pearson / Addison-Wesley 2002

33 Fig 3.15 Standards as requirements R1:Data transfer to the account package shall be done through a file with the format described in WonderAccount Interface Guide xx.yy. The account numbers shall be... R2:The user interface shall follow MS Windows Style Guide, xx.yy. The MS Word user interface should be used as a model where appropriate. R3:Shall run under MS-Windows release xx.yy. Supplier shall port product to new releases within ______ months. R4:Shall follow good accounting practice. The supplier shall obtain the necessary certification. R5:The supplier shall update the payroll computations in accordance with new union agreements within one month after release of the agreement. From: Soren Lauesen: Software Requirements © Pearson / Addison-Wesley 2002

34 Fig 3.16 Development process as requirement R1:System development shall use iterative development based on prototypes as described in App. xx. R2:Supplier shall deliver additional screens with a complexity like screen S3 at a price of $____ per screen. R3:All developers shall spend at least two days working with the users on their daily tasks. R4:A special review shall be conducted at the end of each development activity to verify that all requirements and system goals are duly considered. The customer’s representative shall participate in the review. R5:Customer and supplier shall meet at least two hours bi-weekly to review requests for change and decide what to do, based on cost/benefit estimates of the changes. Generates new requirements? From: Soren Lauesen: Software Requirements © Pearson / Addison-Wesley 2002


Download ppt "Slides for Software requirements Styles and techniques Soren Lauesen 3. Functional requirement styles August 2006 © 2002, Pearson Education retains the."

Similar presentations


Ads by Google