CS 501: Software Engineering Fall 2000AdministrationWireless LaptopsThe Requirements ProcessRequirements AnalysisEntity-Relation ModelEntity-Relation DiagramExample: CS 501 ProjectExample: MARC Catalog RecordMARC Format for Monographs (Books)Entity-Relation Diagram for MARCData DictionariesA Note on Object ModelsNon-Functional RequirementsExamples of Non-Functional RequirementsUnspoken RequirementsRequirements SpecificationRequirements Specification: PurposeSlide 19Slide 20Requirements Specification: ApproachesCS 501: Software EngineeringFall 2000Lecture 6(a) Requirements Analysis (continued)(b) Requirements SpecificationAdministration• Introduction of André Allavena • Due date for Assignment 1 is Wednesday 5 p.m.• Teaching Assistant assignment to projects will be made on ThursdayWireless Laptops• Read http://www.nomad.cornell.edu/• As part of Assignment 1, each project should: => list the people who will be issued with laptops, up to 3 people per project + one alternate => list people who will be issued with wireless cards, up to 2 per project• Distribution times and places are: => Thursday, September 14th, 2:30 - 4:00 pm, Upson 5126 => Friday, September 15th, 10:00 - 11:30 am, Upson 5130The Requirements ProcessFeasibilityStudyRequirementsAnalysisRequirementsDefinitionRequirementsSpecificationFeasibilityReportSystemModelsDefinition ofRequirementsSpecification ofRequirementsRequirementsDocumentRequirements Analysis Methods for data modeling and design• Data flow diagrams• Entity-relation diagrams• Data dictionaries• Object models Many of these methods blur the distinction between analysis and design.Entity-Relation ModelA Design Methodology for Relational Databases• A database of entities and relations• Tools for displaying and manipulating entity-relation diagrams• Tools for manipulating the database (e.g., as input to database design)Warning: There is much confusion about definitions and notationEntity-Relation DiagramAn entityA relation between entitiesAn entity or relation attributeAn inheritance relationExample: CS 501 ProjectStudent CS501 StudentMajorProject5 to 71Member ofPersonClient1Tech contact0:n0:n0:nExample: MARC Catalog RecordCaroline R. Arms, editor, Campus strategies for libraries and electronic information. Bedford, MA: Digital Press, 1990.MARC Format for Monographs (Books)001 89-16879 r93245 Campus strategies for libraries and electronic information260 {Bedford, Mass.} : Digital Press, c1990.650 Academic libraries--United States--Automation.650 Libraries and electronic publishing--United States.700 Arms, Caroline R. (Caroline Ruth)Entity-Relation Diagram for MARCBookShort titleCatalog recordDescribesControl numbSubject headingIs aboutCreatorEditor ofAuthor of1:n10:n0:n0:n0:n0:n0:nData DictionariesA data dictionary is a list of names used by the system• Brief definition (e.g., what is "date")• What is it (e.g., number, relation)• Where is it used (e.g., source, used by, etc.)• May be combined with a glossaryAs the system is implemented, the data dictionary in the requirements is input to the system data dictionary, which is a formal part of the system specification.A Note on Object ModelsThis course teaches object models as a tool for design.Some people recommend object models for requirements analysis, but it is difficult to use them without constraining the system design.Non-Functional RequirementsProduct requirementsperformance, reliability, portability, etc...Organizational requirementsdelivery, training, standards, etc...External requirementslegal, interoperability, etc...Examples of Non-Functional RequirementsPrivacy (Mercury digital library) Functional requirement: Usage data for management of systemNon-functional requirement: Usage data must not identify individualsMinimizing records (NeXT)Functional requirement: Retain all required records Non-functional requirement: Discard all other recordsUnspoken RequirementsExample:Resistance to change at XXXRequirements SpecificationWhat is the purpose of the Requirements Specification?Requirements Specification: Purpose1. It describes the requirements to the stakeholders• Expressed in the terms that the stakeholders understand• Comprehensible from many viewpoints• Reviewed by stakeholders so that they understand implications• Must be clear about assumptions (things left out)Requirements Specification: Purpose2. It describes the requirements to the implementers• As precise and specific as possible• Expressed in terms that they understand• Comprehensible to new team membersRequirements Specification: Purpose3. It records the requirements for the future• An essential part of system evolution4. If may be a contractual document• See you in court!Requirements Specification: Approaches• Natural language• Structured natural language• Design description language• Requirements specification language• Graphical notation• Formal specificationSee Sommerville, Chapter
View Full Document
Unlocking...