CS 501 Software Engineering Fall 2000 Lecture 6
- Slides: 21
CS 501: Software Engineering Fall 2000 Lecture 6 (a) Requirements Analysis (continued) (b) Requirements Specification
Administration • Introduction of André Allavena • Due date for Assignment 1 is Wednesday 5 p. m. • Teaching Assistant assignment to projects will be made on Thursday
Wireless 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 14 th, 2: 30 - 4: 00 pm, Upson 5126 => Friday, September 15 th, 10: 00 - 11: 30 am, Upson 5130
The Requirements Process Feasibility Study Feasibility Report Requirements Analysis Requirements Definition System Models Requirements Specification Definition of Requirements Document Specification of Requirements
Requirements 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 Model A Design Methodology for Relational Databases • A database of entities and relations • Tools for displaying and manipulating entityrelation diagrams • Tools for manipulating the database (e. g. , as input to database design) Warning: There is much confusion about definitions and notation
Entity-Relation Diagram An entity A relation between entities An entity or relation attribute An inheritance relation
Example: CS 501 Project Major Client 1 Student Project 1 CS 501 Student 5 to 7 Member of 0: n Person 0: n Tech contact
Example: MARC Catalog Record Caroline R. Arms, editor, Campus strategies for libraries and electronic information. Bedford, MA: Digital Press, 1990.
MARC Format for Monographs (Books) 001 245 260 650 700 89 -16879 r 93 Campus strategies for libraries and electronic information {Bedford, Mass. } : Digital Press, c 1990. Academic libraries--United States--Automation. Libraries and electronic publishing--United States. Arms, Caroline R. (Caroline Ruth)
Entity-Relation Diagram for MARC Book 0: n 1 0: n Describes 0: n Catalog record Short title 1: n Author of Editor of Is about Control numb 0: n Creator 0: n Subject heading
Data Dictionaries A 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 glossary As 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 Models This 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 Requirements Product requirements performance, reliability, portability, etc. . . Organizational requirements delivery, training, standards, etc. . . External requirements legal, interoperability, etc. . .
Examples of Non-Functional Requirements Privacy (Mercury digital library) Functional requirement: Usage data for management of system Non-functional requirement: Usage data must not identify individuals Minimizing records (Ne. XT) Functional requirement: Retain all required records Non-functional requirement: Discard all other records
Unspoken Requirements Example: Resistance to change at XXX
Requirements Specification What is the purpose of the Requirements Specification?
Requirements Specification: Purpose 1. 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: Purpose 2. It describes the requirements to the implementers • As precise and specific as possible • Expressed in terms that they understand • Comprehensible to new team members
Requirements Specification: Purpose 3. It records the requirements for the future • An essential part of system evolution 4. 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 specification See Sommerville, Chapter 7.
- Software engineering lecture notes
- 01:640:244 lecture notes - lecture 15: plat, idah, farad
- What is system design in software engineering
- Forward engineering and reverse engineering
- Software maintenance in software engineering ppt
- What is software implementation in software engineering
- What is software metrics in software engineering
- Software engineering crisis
- What is software measurement
- Real time software design in software engineering
- Software design fundamentals in software engineering
- Financial engineering lecture notes
- Foundation engineering lecture notes
- Engineering ethics lecture notes
- Barema onderwijs 501
- Arabské číslice
- Bds 501
- Hino horas benditas
- Eng m 501
- Ariane 5 flight 501
- Dev 501
- Cis 501