IS550: Software requirements engineering 2. Data 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 It is important to specify the data to be stored in the system, no matter whether data is stored as a database or in some other way. It may also be important to specify the data that enter and leave the system. Specifying the data is not really a design issue. We will see four styles for specifying data suited Data stored in the system Data entering and leaving the system.

1. The hotel system example One cannot sit in his office and produce requirements based on intuition and logic. The non-trivial requirements are discovered from users and other stakeholders. The hotel example illustrates a basic point in all requirements engineering. It is relatively simple : we want to support the hotel reception, in particular the tasks of booking rooms, checking in, checking out, changing rooms for a customer who has already checked in, and recording services such as breakfasts on a guest’s bill. To do this, the system should record data about guests, rooms, and services.

1. The hotel system example Task list Book guest Checkin Checkout Change room Breakfast list & other services Data about Guests Rooms Services

2. Data model Block diagram describing data inside and outside the product Excellent for experts – difficult for users For COTS-based systems: focus on the non-standard data A data model (DM) specifies the data to be stored in the system and the relationships between the data. There are many variants of DM. Advantages: A data model is a very precise description of data It is insensitive to the level we work on An early analysis of the information in the domain will create a model that can survive to implementation with only minor modifications

2. Data model R2: The system shall store the following data: One-to-many (1:m) Each guest connected to zero or more stays name, address1, address2, address3, passport Guest name, price Guests Service Type Stay Service stay#, paymethod, employee date, count Room State Stays date, #persons, state (booked|occupied|repair) Room room#, #beds, type price1, price2 Each stay connected to one guest record

2. Data model (Normalization) It is often convenient to model the domain information without normalizing the data When developers plan a corresponding relational database system they will always normalize If data are to be stored as objects, normalization is not quite as important, because objects may have more complex internal structure

2. Data model (Implementation) Relational database 712 251 Stay 117 name, address1, . . . Guest Simpson stay#, paymethod, Pointer Linked objects No artificial keys guestId, name, address1, . . . Artificial primary key, doesn’t exist in the domain Guest Natural primary key, exists in the domain stay#, guestId, paymethod, . . . Stay Foreign key, a reference to the guest

2. Data model (Cardinality) 1:m variants: Each A has zero or more B’s Each B has one A A B owns Each A owns one or more B’s Each B belongs to one A A B belongs Each A has one or more B’s Each B has zero or one A A B A B 1:1 variant: Each A has one B Each B has zero or one A m:m variant Each A has several B’s Each B has several A’s

(Frequent model error) 2. Data model (Sub-classing and specialization) Guest Common attributes A guest is one or the other - never both Person Company Special attributes for persons Special attributes for companies RoleType Staff Role Correct model e.g. Waiter, Receptionist Waiter Staff Receptionist Staff with both roles? (Frequent model error)

2. Data model (Other Notations) UML notation Each A has one or more B’s Each B has one A 1:1 1: A B 0:1 1:99 Each A has one to 99 B’s Each B has zero or one A A B Stay RoomState One to many: Move attributes to RoomState date, state Room #persons Diamond notation Many to many: Make diamond a box m 1

2. Data model (Transformation rules) B C Two feet facing the same way make one long foot A C A B C Two feet facing opposite ways make many-to-many A C Stay Room Resolve many- to-many with a connection box Room state Stay Room

2. Data model (Room allocation in E/R) Building wish Contract period Activity Building Class activity Request hour Room hour Line Request Room Room wish Room property Class Class hours Property wish Property Time table User authoriz Authoriz type User

2. Data model (Room allocation in UML) 0: Building wish 1:1 Contract period Activity Building 0:1 0: 0: 1:1 1:1 0: 1: 0: 1:1 1:1 0: 0:1 Class activity 0: 1: Request hour Room hour 1: Line Request Room 0:1 1:1 1:1 1:1 0: 1:1 1:1 1: 0: 1:1 1:1 0: 1:1 0: Room wish Room property Class 0: 0: 1:1 0: 1: 1:1 0: Class hours Property wish Property 0: 1:1 1: 1:1 0:1 1:1 Time table 0:1 0: User authoriz 1:1 Authoriz type User 0: 1:1 0:

3. Data dictionary A textual description of data inside and outside the product Excellent for expert as well as user For COTS-based systems: focus on the non-standard data A data dictionary is a verbal data description structured systematically. In many projects, we don’t have to make a data model (DM). We can use instead just a data dictionary (DD). It is the developer’s task to transform the DD into a DM and possibly a DB. Even if we have a DM, it is usually necessary to use a DD for describing details, special cases, … In general, DD work best in combination with DM

3. Data dictionary D1: Class: Guest Examples Attributes The guest is the person or company who has to pay the bill. A person has one or more stay records. A company may have none. “Customer” is a synonym for guest, but in the database we only use “guest”. The persons staying in the rooms are also called guests, but are not guests in database terms. Examples a. A guest who stays one night. b. A company with employees staying now and then, each of them with his own stay record where his name is recorded. c. A guest with several rooms within the same stay. Attributes 1. name: Text, 50 chars 2. passport: Text, 16 chars Attribute missing in data model The name stated by the guest. For companies the official name since the bill is sent there. Longer names exist, but better truncate at registration time than at print out time. Recorded for guests who are obviously foreigners. Used for police reports in case the guest doesn’t pay . . .

4. Data expressions Compact formulas that describe data sequences Useful for composite data and message protocols Excellent for experts – acceptable for many users A data expression (DE) is short and can show the structure of data. DE are called Regular expressions or Backus-Naur Form (BNF) DE may be used to outline the data flowing across the user interface but only on a high level DE can be used to describe parts of the DM.

4. Data expressions Notation with plus as concatenator booking request = guest data + period + room type guest data = guest name + address + paymethod + [passport number] passport number = letter + {digit}*8 room state = { free | booked | occupied | repair } account data = transfer + {account record}* + done Notation with implicit concatenation guestData = guestName, address, paymethod [, passportNumber] ifStatement = If condition Then statement [ Else: statement End If ]

4. Data expressions Guest Guest = name + address + {stay}* Stay = paymethod + [employee] + {room + date}* + Guest ?? Stay Reference to Guest from Stay? Room

5. Virtual Windows Simplified screen pictures with graphics and realistic data, but not buttons and menus Excellent for experts as well as users Excellent for planning new user interfaces But don’t overdo it and start designing the user interface Virtual windows (VW) serve three purposes: They allow customer and developer to validate the data model They can be used to plan data screens that effectively support user tasks They allow the customer to validate the screen design at a very early stage The purpose 1 is important in all cases The purposes 2 & 3 are only interesting when a new system is to be developed, rather than bought

5. Virtual Windows Breakfast 9/8 In In R# rest room 11 2 12 1 13 1 1 Stay#: 714 Guest Name: John Simpson Address: 456 Orange Grove Victoria 3745 Payment: Visa Breakfast 9/8 In In R# rest room 11 2 12 1 13 1 1 R1: The product shall store data corresponding to the following virtual windows: Item #pers 7/8 Room 12, sgl 1 600 8/8 Breakf. rest 1 40 8/8 Room 11, dbl 2 800 9/8 Breakf. room 2 120 9/8 Room 11, dbl 2 800 R2: The final screens shall look like the virtual windows ?? Service charges Breakf. rest. 40 Breakf. room 60 . . . Rooms 7/8 8/8 9/8 10/8 11 Double Bath 800 600 O B 12 Single Toil 600 O O B B 13 Double Toil 600 500 B B B

5. Virtual Windows R1: The product shall store data corresponding to the existing screens: