Requirements & Specification (Chapter 10)Software Engineering MethodologyWaterfall ModelPlanningInformal Statement of ObjectivesSystem DefinitionUse Cases Correspond to User ViewsComplete Set of RequirementsRequirements DocumentUse Cases"Registration" Use Case"Enter Grade" Use CaseInput from the ClientInput from the DB DesignerFact Finding to Get Requirements, Use CasesSelecting the DBMSRequirements Document SpecificsRequirements & Specification(Chapter 10)CPSC 356 DatabaseEllen WalkerHiram 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 loopsWaterfall ModelRequirementsSpecificationDesignCodingTestingMaintenancePlanning•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 system2. Add and drop courses for the next semester3. Obtain reports on a student's status4. Maintain information about students and courses5. Enter final grades for courses that a student has completedSystem Definition•Describe scope and boundaries of database application–Limit scope to conserve resources as necessary•Describe how system will be used –Use cases–User viewsUse Cases Correspond to User ViewsComplete 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 requiredUse 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 requirementsInput from the DB Designer•Cost & difficulty of various requirements•Suggestions of "free" additions•Indications of potential inconsistencies & suggestion for resolutionFact 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•ResearchSelecting 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