Transcript Data Modeling - Hiram College

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.
2.
3.
4.
5.
Authenticate themselves as users of the system
Add and drop courses for the next semester
Obtain reports on a student's status
Maintain information about students and courses
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)