Requirements Analysis, Part I

Tom Kelliher, CS 319

Oct. 19, 1998

Announcements

From Last Time

Outline

Assignment

Requirements Analysis

Developing requirements is hard:

1. Stakeholders often only know what they want in general terms.

2. Stakeholders express requirements in their own language. Different stakeholders may express the same requirement in different ways.

3. Analysis takes place in an organizational, social, and business environment.

Requirements Analysis Process

Viewpoint-Oriented Analysis

Consider the specification of a new ATM system. Who are the stakeholders? Current bank customers, representatives from cooperating banks, branch managers, branch tellers, database administrators, security managers, communications engineers, marketing department, maintenance engineers (hw and sw), and personnel department (policy changes due to automation).

What do you want from a word processing system?

Why isn't top-down analysis feasible?

Views of viewpoint:

1. Data source or sink.

2. Representation framework: construct different models (entity-relational, state machine) of the system, determine requirements, compare.

3. (External) Receiver of services.

Method-Based Analysis

Application of a structured method to analysis process.

``Set of steps,'' but no one method is applicable to all classes of systems.

Structured method components:

1. Process model: Method activities. Presented as set of step, but in actuality is an iterative process.

2. System modelling notations: dataflow, entity-relational, OO, etc.

3. Rules within models (entities must have names) and between models (flows within a dataflow model must be represented with an entity-relational model).

4. Design guidelines to promote good design. ``An object should have no more than five sub-objects.''

5. Report templates defining how information collected during analysis phase is presented.

The VORD method of requirements analysis: