The right things, the right ways,
for the right reasons.

  Contact Us 

Home Resources
Resources
Enterprise Approaches
Business Analysis, Stakeholder Analysis
Business Modeling
Requirements Analysis
Requirements Management
Risk Management
Iterative Development
Testing
Business Change Management
Software Architecture
Implementing RUP
Bibliography
The right things, the right ways,
for the right reasons.

Requirements Analysis

Use-cases are an excellent way to model software requirements on nearly any project.

Use-cases describe the behaviour of the system from the point of view of the users and other external systems. The term "Actor" is used to refer to a role filled by a user or external system. Use-cases specify the contract that the actors expect the system to fulfill. Use-cases are focused on the value the system provides to the actor. A use-case describes a complete interaction that delivers tangible value to the actor(s) involved.

In the case of human actors, use-cases do not specify user interface look-and-feel, but rather the way the user interacts with the system, and what the system is expected to do in response. User interface design is considered part of the system design, not the requirements. This is the case even if the use-cases describe a system that is to be custom-built. In the case of a COTS system this is very useful, because we have little control over the look-an-feel and little knowledge of it if we have not yet chosen the COTS package that we are going to implement.

This is fine in theory, but in practice the way the actors interact with the system is still dependent on the target system, and will vary between candidate packages. So for the purposes of evaluating candidate systems, the use-cases are only developed to what is called a use-case outline level. Basically this is a high-level description of the interaction without the level of detail that would be required for building a custom development. Even with custom developments, use-cases are initially specified at the outline level initially, and the detailed specifications are not developed until required (just-in-time). The use-case outlines are then used as part of the evaluation of candidate COTS packages.

Once our use-case outlines or specifications are complete, what use are they? The answer is "lots". The use-cases now can be used for:

In the case of COTS software, once the package is chosen and available, it is possible to make any minor revisions to the use-case outlines necessary to bring them in line with the chosen package. However, to fulfill all of the above uses, the use-case outlines probably need a little more detail added. The level of detail to add is just enough to serve the desired purpose.

Additional Resources

Online

Other