This template might serve as an approach to document use cases in a more systematic and coherent way.
Recommended format:
As a <Reader | who will benefit from the use case> I would like to <what is the use case> so that <how I will benefit from the use case>
Explanation:
The expressions in angle brackets are meant to be placeholders for the specific content of a use case. The description should be technology-agnostic as it serves to define the users' needs and will not be a guide for a specific implementation.
<Reader | who will benefit from the use case>:
Here you should try to define the role of the user as precisely as possible. For example, instead of "as a publisher" you might say "as a publisher of scientifc textbooks" etc. Please keep in mind that a Reading System could also be a kind of user.
<what is the use case>:
Try to describe your user's need as precisely as possible on a micro-level that could be implemented later on. Instead of a general statement such as "achieve a more user-friendly layout", you should prefer to speak of "achieve a more flexible table layout for huge and complex tables".
<how I will benefit from the use case>:
Describe the ultimate goal of the user's requirement. For example, if you requested "a more flexible table layout for huge and complex tables", you might want to adapt for mobile use - "so that you may consume them on a mobile".
Detail
What is the current problem.
More specific is better to help people understand.
If the use case has a specific audience or circumstance, then who, when and how will people benefit from solving this problem.
Proposal (if any)
A use case does not need to come with a proposal or a recommendation. But if there is any, we can have it documented.
Introduction
Brief introduction to the "use case template".
This template might serve as an approach to document use cases in a more systematic and coherent way.
Recommended format:
As a <Reader | who will benefit from the use case> I would like to <what is the use case> so that <how I will benefit from the use case>
Explanation:
The expressions in angle brackets are meant to be placeholders for the specific content of a use case. The description should be technology-agnostic as it serves to define the users' needs and will not be a guide for a specific implementation.
<Reader | who will benefit from the use case>:
Here you should try to define the role of the user as precisely as possible. For example, instead of "as a publisher" you might say "as a publisher of scientifc textbooks" etc. Please keep in mind that a Reading System could also be a kind of user.
<what is the use case>:
Try to describe your user's need as precisely as possible on a micro-level that could be implemented later on. Instead of a general statement such as "achieve a more user-friendly layout", you should prefer to speak of "achieve a more flexible table layout for huge and complex tables".
<how I will benefit from the use case>:
Describe the ultimate goal of the user's requirement. For example, if you requested "a more flexible table layout for huge and complex tables", you might want to adapt for mobile use - "so that you may consume them on a mobile".
Detail
More specific is better to help people understand.
Proposal (if any)
A use case does not need to come with a proposal or a recommendation. But if there is any, we can have it documented.