1. CS 501: Software Engineering Fall 1999 Lecture 5 (a) Requirements Analysis (continued) (b) Requirements Specification

2. Administration Assignment 2: See "Course Notices" on web site. Recitation sessions on next two Mondays. Teaching Assistant office hours: See "Administration" on web site.

3. The Requirements Process Feasibility Study Requirements Analysis Requirements Definition Requirements Specification Feasibility Report System Models Definition of Requirements Specification of Requirements Document

4. Requirements Analysis Methods for data modeling and design  Data flow diagrams  Entity-relation diagrams  Data dictionaries  Schema Many of these methods blur the distinction between analysis and design.

5. Entity-Relation Model  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 notation

6. Entity-Relation Diagram An entity A relation between entities An entity or relation attribute An inheritance relation

7. Example: CS 501 Project Student CS501 Student Major Project 5 to 7 1 Member of Person Client 1 Tech contact 0:n

8. Example: MARC Catalog Record Caroline R. Arms, editor, Campus strategies for libraries and electronic information. Bedford, MA: Digital Press, 1990.

9. MARC Format for Monographs (Books) &001 89-16879 r93 &245 Campus strategies for libraries and electronic information/Caroline Arms, editor. &260 {Bedford, Mass.} : Digital Press, c1990. &300 xi, 404 p. : ill. ; 24 cm. &440 EDUCOM strategies series on information technology &504 Includes bibliographical references (p.{373}381). &020 ISBN 1-55558-036-X : $34.95 &650 Academic libraries--United States--Automation. &650 Libraries and electronic publishing--United States. &700 Arms, Caroline R. (Caroline Ruth)

10. Entity-Relation Diagram for MARC Book Short title Catalog record Describes Control numb Subject heading Is about Creator Editor of Author of 1:n 1 0:n

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

12. Non-Functional Requirements Product requirements performance, reliability, portability, etc... Organizational requirements delivery, training, standards, etc... External requirements legal, interoperability, etc...

13. Non-Functional Requirements Examples: Privacy: Andrew system Minimizing records: NeXT Audit trails and long-term archiving Sales and marketing: New England Digital

14. Unspoken Requirements Example: Resistance to change at XXX

15. Requirements Specification What is the purpose of the Requirements Specification?

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

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

18. Requirements Specification: Approaches  Natural language  Structured natural language  Design description language  Requirements specification language  Graphical notation  Formal specification See Sommerville, Chapter 7.

19. Reading Before next class, read and be ready to discuss: Sommerville: Chapters 9 and 10 pages 157 to 170.