From Wiki
Revision as of 13:07, 2 November 2011 by Suhridk (talk | contribs) (→‎Use Case Analysis)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigationJump to search


  • Requirements Analysis is building models of requirements that can be evaluated.
  • It is also about identifying conflicts between requirements.
  • Analysis will lead us to identify new requirements or to refine existing requirements.
  • Formally modeling natural language requirements is hard ! also, requirements also conflict with multiple stakeholders.
  • Techniques used are: UML and SCR tables.

Analysis using UML

  • UML modeling can be used to analyse requirements.
  • Use cases (Are these part of UML ?) - to define functional requirements.
  • Static Structure Diagrams - To model object and relationships. [TODO : Isnt this stepping into design ?]
  • Dynamic behavior diagrams - to model interaction and sequencing.
  • There are also UML analysis patterns which help reuse existing models. These are usually domain specific.
    • Note: this is different from a design pattern.

Sequence Diagrams

  • Can be used to describe how actors in a use case are interacting.
  • Human and proactive system actors (the primary actors) should be on the left most side of the diagram.
  • Reactive system actors (the supporting actors) are on the right most side of the diagram.

Activity Diagrams

  • Useful to describe workflows and parallel behaviour.
  • Provides a strong understanding of concurrency in the system.

Use Case Analysis

  • Identify actors: A starting point is by identifying nouns which indicate the actors. For e.g. the user does this or the user does that.
  • Identify actions: Each of the actors do different things with the system. These are the actions. Each action can represent a use case.
  • Refinement
    • Think if any actors are missing (e.g. supporting actors)
    • Examine any missing pre-conditions for identified use cases - these pre-conditions could turn out to be use cases themselves.
    • Check if any use case is doing too much. A use case is intended to represent an atomic action in the system. Other use cases can be identified by this.
    • Examine scenarios in detail.
    • Examine assumptions that are inherent. This can be functional as well as non-functional.