Interviews tend to give the best information. However, they are more expensive than other means.
They are good if many people are inolved. Especially if they are dispersed across a company. These tend to have poor or false responses though.
These are accurate if they are done well. Like with interviews, it is expensive.
Join application design
These are typically workshops held with uses to get a consensus of the requiremets. Meeting may mean that clients are away from their workspaces.
Typical elicitation process
- Identify actors - types of users who interact with the system
- Identify scenarios - concrete examples of how the system will be used.
- Identify use cases - Description of all possible behaviour in the system.
- Refine use cases - description of all possible behaviour in the system. These are abstractions unlike scenarios which are specific examples.
- Identify relationships among use cases - factor out common functionality and find dependencies.
- Identify non-functional requirements.
A use case is a description of a set of sequences of actions, including variants, that a system performs to yield an observable result of value to an actor.
Graphically, a use case is rendered as an ellipse. Typically an actor represents a role that a human, a hardware device, or even another software system plays within a system.
eg. In order to delete an element in a graphics package, it must always be selected.
eg. When an element is selected, the option to move it is there as well.
Read <<extend>> and <<include>> relationships in the direction of the arrow: move extends select, delete includes select.
The generalisation relationship between use cases is represented by a solid line with a white arrow head. The more general concept is placed at the head of white arrow head. Generalisation can apply to use cases, actors and classes. Actors connect to use cases by means of a simple line that crosses the system boundary.