CS 501: Software EngineeringFall 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

FeasibilityStudy

RequirementsAnalysis

RequirementsDefinition

RequirementsSpecification

FeasibilityReport System

Models Definition ofRequirements

Specification ofRequirements

RequirementsDocument

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 entity-relation 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

Student

CS501 Student

Major

Project

5 to 7

1

Member of

Person

Client1

Tech contact

0:n0:n

0:n

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 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 MARC

Book

Short title

Catalog record

Describes

Control numb

Subject heading

Is about

CreatorEditor of

Author of

1:n

1

0:n

0:n

0:n

0:n

0:n

0:n

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.