Requirements Analysis, Part II

Tom Kelliher, CS 319

Nov. 6, 2000

Administrivia

Announcements

Assignment

From Last Time

Requirements analysis, part I.

Outline

1. Method-based analysis.

2. System contexts.

3. Human, social, organizational contexts.

4. Exercises.

Coming Up

???

Method-Based Analysis

Application of a structured method to analysis process. Aided via CASE tools.

``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:

Other methods: OO analysis, dataflow-based methods.

1. Viewpoint identification: Discovering viewpoints which receive system services and identifying specific services provided. Brainstorming to determine viewpoints, services, data inputs, non-functional requirements, control events, and exceptions.

2. Viewpoint structuring: Grouping related viewpoints into a hierarchy. Common services are provided at higher levels in the hierarchy. Lower level viewpoints inherit.

3. Viewpoint documentation: Refining viewpoints and services.

4. Viewpoint system mapping: translation to OOD.

System Contexts

1. What are the boundaries of the system? Interactions with what other systems? Other systems: the ``environment.''

   Usually clear-cut if the new system is replacing an existing system.

   Not always: Consider whether to continue using a legacy database.

2. Once initial boundaries have been set, perform initial analysis to determine dependencies (simple block diagram of dataflow).

3. Expand the simple model into a richer environmental model. Nail down the interfaces.

4. Social and organizational forces may shape the system boundaries.

Human, Social, and Organizational Factors

1. People are resourceful; they become frustrated by systems which impose particular ways of working.

2. These factors affect all viewpoints. There is no systematic means for deriving requirements for these factors.

Consider a system to allow senior management access to information, bypassing middle managers. Consider the social and organizational factors influencing the viewpoints.

Ethnography:

1. The study of people's work practices. Used to generate requirements.

2. Impact upon requirements analysis. Consider an imperfect system (railroad paradox): A service isn't good so users complain about and find alternative services. Analysts then examine the system, determine that it isn't being used, and decide it isn't necessary.

3. Another example: Collision alert warning in air traffic control system. Switched off due to warning's nuisance. A good idea, poorly implemented. Simple-minded analysis would have it removed from the system.

4. Ethnography and prototyping.

Exercise

Start the VORD process for an online library catalog system. Identify viewpoints, services, data inputs, non-functional requirements, control events, and exceptions.