The first thing to do if starting with a new thing, is to specify what it should do.
Even if your fingertips already want to write Code and you want to discover the newest and latest Features of a new framework.
This will help to stay focused on the solution and also helps to find issues or gaps early. It’s driven by the question of how the “thing” you want to create interacts with others, like users or other tools.
Specification
Specification can be done in multiple ways. Either as a long block of text, or atomic features, or visualy by using use case or activity diagrams.
In general it helps to start with a short non formal description for first focus and have a base to start. Followed by standing up from the desk, shaking the body and going to a whiteboard for brainstorming.
With whom will my thingy interact, what benefit does it give, what will be the features it provides.
After roughly defining the features and functions we need to provide, the question is on workflows. What might be the chain of actions leading to something that gives a benefit to our user?
Pitfalls
Overdoing usecases, will render use cases useless, as it’s level of abstraction may jump from verry detailed to abstract or triing to visualize to many (non related) cases at once, making the graph more confusing then helping.
The size and count of objects in the graph should be limited to roughly 7-10 elements. This can be done to either stick with one user, one specific area of use cases or a level of abstraction.
