1. IS550: Software requirements engineering
2. Data requirements styles
Dr. Azeddine Chikh

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

22. 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 O B
12 Single Toil 600 O O B B
13 Double Toil B B B

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