Requirements Analysis, Part I
Tom Kelliher, CS 319
Nov. 3, 2000
Read Chapter 5.
Discussion of Installation Manual.
- Introduction
- Viewpoint-oriented analysis.
- Method-based analysis.
Continuation of Requirements analysis.
Developing requirements is hard:
- Stakeholders often only know what they want in general terms.
- Stakeholders express requirements in their own language. Different
stakeholders may express the same requirement in different ways.
- Analysis takes place in an organizational, social, and business
environment.
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:
- Data source or sink.
- Representation framework: construct different models
(entity-relational, state machine) of the system, determine requirements,
compare.
- (External) Receiver of services.
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:
- Process model: Method activities. Presented as set of step, but in
actuality is an iterative process.
- System modelling notations: dataflow, entity-relational, OO, etc.
- Rules within models (entities must have names) and between models
(flows within a dataflow model must be represented with an
entity-relational model).
- Design guidelines to promote good design. ``An object should have no
more than five sub-objects.''
- Report templates defining how information collected during analysis
phase is presented.
The VORD method of requirements analysis:
Thomas P. Kelliher
Thu Nov 2 14:02:05 EST 2000
Tom Kelliher