Digital Library Architecture

advertisement
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 14th, 2:30 - 4:00 pm, Upson 5126
=> Friday, September 15th, 10:00 - 11:30 am, Upson 5130
The Requirements Process
Feasibility
Study
Requirements
Analysis
Requirements
Definition
Feasibility
Report
System
Models
Requirements
Specification
Definition of
Requirements
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
0:n
1
Student
Project
Person
0:n
1
CS501
Student
5 to 7
Member of
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
650
700
89-16879 r93
Campus strategies for libraries and electronic information
{Bedford, Mass.} : Digital Press, c1990.
Academic libraries--United States--Automation.
Libraries and electronic publishing--United States.
Arms, Caroline R. (Caroline Ruth)
Entity-Relation Diagram for MARC
Book
0:n
Author of
0:n
1
0:n
Editor of
Describes
0:n
Catalog
record
Short title
1:n
Is about
Control numb
Creator
0:n
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 (NeXT)
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.
Download