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.



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