1. Requirements & Specification (Chapter 10) CPSC 356 Database Ellen Walker Hiram College (Includes figures from Database Systems by Connolly & Begg, © Addison Wesley 2002)

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

3. Waterfall Model Requirements Specification Design Coding Testing Maintenance

4. 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…)

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

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

7. Use Cases Correspond to User Views

8. Complete Set of Requirements Requirements document, including… –Use Cases –Data Model (e.g. ER Diagram)

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

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

11. "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)

12. "Enter Grade" Use Case Purpose: Entering a student's grade for a course Actor: Input: Result: Exception:

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

14. Input from the DB Designer Cost & difficulty of various requirements Suggestions of "free" additions Indications of potential inconsistencies & suggestion for resolution

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

16. 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?

17. 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)