Requirements Analysis, Part II

Tom Kelliher, CS 319

Nov. 6, 2000




From Last Time

Requirements analysis, part I.


  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.


  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.


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

Thomas P. Kelliher
Thu Nov 2 14:21:14 EST 2000
Tom Kelliher