Requirements & Specification(Chapter 10)

CPSC 356 Database

Ellen Walker

Hiram College

(Includes figures from Database Systems by Connolly & Begg, © Addison Wesley 2002)

Software Engineering Methodology

• Why? – Software late, over budget, incomplete,

abandoned…– Need organized process for development

• What?– Divide activities into stages– Perform activities sequentially & with feedback

loops

Waterfall Model

Requirements

Specification

Design

Coding

Testing

Maintenance

Planning

• Mission statement– Major aims of database application

• Mission objectives– Specific tasks that the database must support

• Additional information– Work to be done– Resources available

• (See Proj. Mgmt, Software Eval…)

Informal Statement of Objectives

• The database will …

(e.g) …allow users & faculty to…1. Authenticate themselves as users of the system

2. Add and drop courses for the next semester

3. Obtain reports on a student's status

4. Maintain information about students and courses

5. Enter final grades for courses that a student has completed

System Definition

• Describe scope and boundaries of database application– Limit scope to conserve resources as necessary

• Describe how system will be used – Use cases– User views

Use Cases Correspond to User Views

Complete Set of Requirements

• Requirements document, including…– Use Cases– Data Model (e.g. ER Diagram)

Requirements Document

• Describes what the system will do, not how the system will do it

• Collaboration between client and database designers (or systems analysts)

• May include priorities for requirements:– Minimal: without these, the system is not useful– Expected: what we expect for the database– Extended: desired, but not required

Use Cases

• Each describes a specific user interaction with the database– Title: name of the use case– Purpose: what does it do / why is it needed?– Actor: who is involved?– Input: (data)– Result: (data or action)– Exceptions: special cases that prevent the normal

outcome

"Registration" Use Case

• Purpose: student registers for a course• Actor: student• Input: course number & section• Result: student is registered and informed• Exceptions:

– Registration fails if class is full.– Registration fails if student doesn't have prereqs.– Registration fails if student has a finance hold.– (etc)

"Enter Grade" Use Case

• Purpose: Entering a student's grade for a course

• Actor:• Input:• Result:• Exception:

Input from the Client

• Initial objectives for the database• Explanations of "how it is done now"• Definitions and descriptions to clarify terms• Answers to "what if" questions, to clarify and

set constraints• Actual or fictionalized data, if available• Information for use cases• Prioritization of requirements

Input from the DB Designer

• Cost & difficulty of various requirements• Suggestions of "free" additions• Indications of potential inconsistencies &

suggestion for resolution

Fact Finding to Get Requirements, Use Cases

• Examining documentation– Memos, written objectives, complaints (!)– Flowcharts, existing forms & reports– Data sets

• Interviewing– Can be most effective!– Plan and prepare

• Observation, Questionnaires• Research

Selecting the DBMS

• Does the client already have a DBMS that you are required to use?

• What are the security requirements?• Will the system be limited to one machine?• Will the system be used remotely (across the

LAN? Across the WWW?)• What are the size / speed requirements?

Requirements Document Specifics

• Restate objectives• Define terms• Describe information to be contained in the

system (data model)• Describe integrity contraints• List Use Cases (with priorities)• List system issues (including DBMS choice)