1 / 23

IS550: Software requirements engineering

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.

apillar
Download Presentation

IS550: Software requirements engineering

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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: 0201745704 - ISBN-13: 9780201745702

  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 Each stay connected to one guest record room#, #beds, type price1, price2

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

  10. 1:1 variant: Each A has one B Each B has zero or one A A B m:m variant Each A has several B’s Each B has several A’s A B 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

  11. Staff with both roles? (Frequent model error) Correct model e.g. Waiter, Receptionist Staff Waiter Receptionist Staff Role RoleType 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

  12. date, state Diamond notation Many to many: Make diamond a box m m Stay Room #persons One to many: Move attributes to RoomState m 1 Stay RoomState 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 Each A has one to 99 B’s Each B has zero or one A 0:1 1:99 A B

  13. A B C A C A B C A C 2. Data model (Transformation rules) Two feet facing the same way make one long foot Two feet facing opposite ways make many-to-many 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 Room hour Class activity Request hour Room Line Request Room property Room wish Class Class hours Property wish Property Time table User authoriz Authoriz type User

  15. 2. Data model (Room allocation in UML) 0: 1:1 Building wish Contract period Activity Building 0:1 0: 0: 1:1 1:1 0: 1: 0: 0:1 1:1 1:1 0: 1: 1: Class activity Request hour Room hour 0: Line Request Room 1:1 0:1 1:1 1:1 1:1 1:1 0: 1: 1:1 0: 1:1 0: 1:1 Room property Room wish 0: 0: Class 0: 1:1 0: 1: 1:1 0: Class hours Property wish Property 0: 1:1 1: 0:1 1:1 1:1 0: Time table User authoriz Authoriz type 0:1 1:1 User 1:1 0: 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 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 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

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

More Related