Difference between revisions of "Analysis"
From Suhrid.net Wiki
Jump to navigationJump to search(4 intermediate revisions by the same user not shown) | |||
Line 3: | Line 3: | ||
* Requirements Analysis is building models of requirements that can be evaluated. | * Requirements Analysis is building models of requirements that can be evaluated. | ||
* It is also about identifying conflicts between requirements. | * 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. | * Formally modeling natural language requirements is hard ! also, requirements also conflict with multiple stakeholders. | ||
* Techniques used are: UML and SCR tables. | * Techniques used are: UML and SCR tables. | ||
Line 15: | Line 16: | ||
** Note: this is ''different'' from a design pattern. | ** 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. | ||
[[Category:REQE]] | [[Category:REQE]] |
Latest revision as of 12:07, 2 November 2011
Contents
Intro
- 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.