Software Engineering CS 501 Lecture 6: Requirements Analysis and Specification, Slides of Software Engineering

Download Software Engineering CS 501 Lecture 6: Requirements Analysis and Specification and more Slides Software Engineering in PDF only on Docsity!

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 Requirements Specification

Feasibility Report (^) System Models Definition of Requirements

Specification of Requirements

Requirements Document

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

CS

Student

Major

Project

5 to 7

1

Member of

Person

Client 1

Tech contact

0:n 0: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 r 245 Campus strategies for libraries and electronic information 260 {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

Editor of^ Creator

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.