Use Case Brief

A use case is a description of something that a system does in response of any request from any other automated system or actor.

How to write:

1. We should write the use cases in business terms, not technical ones.
2. Any business person should be able to understand the use cases without the help of any technical personal.
3. Technical design assumptions should not be made at this stage.
4. Use cases can also serve as a contract between business and development sides of any organisation.
5. Use case text should begin with "The system (or application) will". If a use case can not be started like this, it means it is either not a valid use case or is a part of another use case.
6. Explicitly list all the affected actors in the use case.

Points to consider:

1. There is no rule how long the use case should be
2. Avoid use case diagrams (for architects only)
3. Writing use cases requires a lot of participation from business side.
4. Facilitate use case analysis by starting with a small group.
5. Consider recording use cases in database.
6. Enlist someone to act as a 'scribe' for the use case discussions to avoid any point to be missed.
7. Write use cases so that they can be amended as more information is available with time.
8. Use case analysis is finished when the team members feel that they can estimate the time for efforts for implementing a particular use case.
9. Be sure to include requirements for security, scalability and availability.
10. Don’t slow down if the group has trouble articulating requirements.

Common Mistakes:

1. Imposing the technical design assumption under the guise of requirements. Like System will manage the load using batch stream No.
2. Including physical design assumptions in use cases. Like the system will insert a row in database.
3. Not keeping analysis session productive.
4. Failing to document use cases even if the project is small.
5. Repeatedly defining the terms in every use case.

Prototyping:

At this stage, the team should be able to decide the technology which will be used for developing the UI (mostly HTML). Try to develop the non-functional UI. It will gaurd against accidentally promising the delivery of something which is not technically possible.

1. Consider involving the layout designer for prototyping.
2. Remember that prototype is not functional by definition.

Uses:

1. Use cases are used to write the test cases for the system.
2. Use cases help in validating the architecture and system during development and ensure that we are going in right direction.
3. Use cases help the business people/Project Manager/Project Sponser to define the scope of the project.
4. Use cases help the project management to define the release boundaries and the functionalities need to be implemented in release.
5. Use cases help the management or technical people to articulate the efforts; and so helps in deciding the cost/benefit ration.

People who read this post also read :