Requirements Specification Chapter 10 CPSC 356 Database Ellen

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)