IS550: Software requirements engineering

Dr. Azeddine Chikh

2. Data requirements styles

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

                 

Text

0. Introduction

3

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

4

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.

Task list

Book guestCheckinCheckoutChange roomBreakfast list &other services

Data about

GuestsRoomsServices

1. The hotel system example

5

2. Data model

6

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

R2: The system shall store the following data:

Stay

RoomState

Room

ServiceService

Type

date, #persons,state (booked|occupied|repair)

name, address1, address2, address3, passport

room#,#beds, typeprice1, price2

name, price

date, count

Guest

stay#,paymethod,employee

Stays

Guests

One-to-many (1:m)

Each guest connected to zero or more stays

Each stayconnected to one guest record

2. Data model

7

2. Data model (Normalization)

8

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

Stay

guestId,

name,

address1,

. . .

Guest

stay#,

guestId,

paymethod,

. . .

Artificial primary key,doesn’t exist in the domain

Natural primary key,exists in the domain

Foreign key, a reference to the guest

Relational database

712251

Stay117

name, address1, . . .

GuestSimpson

stay#,paymethod,. . .

Pointer

Linked objects

No artificial keys

9

2. Data model (Implementation)

A B

A B

1:m variants:Each A has zero or more B’sEach B has one A

Each A has one or more B’sEach B has zero or one A

A B Each A owns one or more B’sEach B belongs to one A

owns

belongs

A B 1:1 variant:Each A has one BEach B has zero or one A

A B m:m variantEach A has several B’sEach B has several A’s

10

2. Data model (Cardinality)

Person

Guest

Company

Common attributes

Special attributesfor persons

Special attributesfor companies

A guest is one or the other - never both

Waiter

Staff

Receptionist

Staff with both roles?(Frequent model error)

RoleTypeStaff Role

Correct modele.g. Waiter,Receptionist

11

2. Data model (Sub-classing and specialization)

A B 1:1 1:

UML notationEach A has one or more B’sEach B has one A

A B 0:1 1:99 Each A has one to 99 B’s

Each B has zero or one A

Stay RoomState One to many: Moveattributes to RoomState

date, state

Stay Room

#persons

Diamond notationMany to many: Make diamond a box

m

m

m

1

12

2. Data model (Other Notations)

A B C

A C

A B C

A C

Two feet facing the same waymake one long foot

Two feet facing oppositeways make many-to-many

Stay Room

Stay Roomstate

Room

Resolve many-to-many with a connection box

13

2. Data model (Transformation rules)

Line Classactivity

RequestRequest

hourRoomhour

Room

Contractperiod

Activity

Class

Classhours

Timetable

UserUser

authorizAuthoriz

type

Roomproperty

PropertyPropertywish

Roomwish

Buildingwish

Building

14

2. Data model (Room allocation in E/R)

Line Classactivity

RequestRequest

hourRoomhour

Room

Contractperiod

Activity

Class

Classhours

Timetable

UserUser

authorizAuthoriz

type

Roomproperty

PropertyPropertywish

Roomwish

Buildingwish

Building

1:1

0:

1:

1:1

0: 0:1

1: 1:1

1:1

0: 1:1

1:

1:

1:1

0: 0:1

1:1

0:

0:

1:1

1:11:

1:11:1

0:

0:

0: 1:1

1:10:

0:1

0:

1:10:

1:1

1:1

0:1

1:1

1:1

1:1

1:1

0:10:

0: 0:

1: 0:

0:

0:

0:

15

2. Data model (Room allocation in UML)

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

D1: Class: Guest

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.

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

Attributes1. name: Text, 50 chars

2. passport: Text, 16 chars

Attribute missingin data model

Recorded for guests who are obviously foreigners. Used for police reports in case the guest doesn’t pay . . .

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.

17

3. Data dictionary

4. Data expressions

18

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.

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 ]

19

4. Data expressions

Guest = name + address + {stay}*

Stay = paymethod + [employee]+ {room + date}*+ Guest ??

Stay

Room

Guest

Reference to Guest from Stay?

20

4. Data expressions

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

21

R1: The product shall store data corresponding to the following virtual windows:

Rooms 7/8 8/8 9/8 10/811 Double Bath 800 600 O B12 Single Toil 600 O O B B13 Double Toil 600 500 B B B

Service charges

Breakf. rest. 40Breakf. room 60. . .

Stay#: 714GuestName: John SimpsonAddress: 456 Orange Grove

Victoria 3745Payment: Visa

Item #pers7/8 Room 12, sgl 1 6008/8 Breakf. rest 1 408/8 Room 11, dbl 2 8009/8 Breakf. room 2 120

9/8 Room 11, dbl 2 800

Breakfast 9/8

In InR# rest room11 212 113 1 1

R2: The final screens shall look like the virtual windows ??

22

5. Virtual Windows

R1: The product shall store data corresponding to the existing screens:

23

5. Virtual Windows