Recently I was asked to take a look at some Software Use Case (SUC) specifications. What I found was actually a description of a screen flow crowbarred into a SUC specification template.
There are two questions you might be asking.
- What’s wrong with that?
- How does it come about?
What’s wrong with that?
The purpose of the SUC is to understand the Actor/System interaction at a logical level and to tease out and make clear the primary path and all alternate and exception paths. A well crafted SUC also makes it clear where business rules are needed. SUCs don’t care about button clicks because they distract from the logic of the scenario.
Screen flows are not about the underlying logic, they are about showing all the possible routes through the screens, depending on which buttons you click.
It’s a problem when you focus on the button clicks, because you risk missing out on some of that underlying logic. You risk missing out on alternate and exception flows and you risk overlooking business rules. Iterative development is supposed to mitigate risk, not increase it.
What is more, a screen flow is more easily read if it is visual, so cramming it into a SUC specification template does not make it easy to follow at all. In fact, I encourage people to write lean SUC specifications, on the basis that they are hard for the customer to read, but that’s for another post.
If you document screen flows and call them SUCs, you may get approval from all parties (except the Software Architect, who, I imagine, would not be happy), but I am pretty certain not all parties will have the same understanding of the requirements. As a result, misunderstandings will not become apparent until User Acceptance Testing.
How does it come about?
Lack of experience. Analysts need to be strong-willed as well as flexible. While it is important to produce analysis artefacts that meet the needs of the intended readers, the analyst cannot simply be at the whim of those readers. If the intended consumers of the SUC are not themselves familiar with how to document a SUC, they will try to influence how it is documented and they will get it wrong. The analyst must be firm, explaining how things should be done, while being sensitive to the needs of the consumer.
Caveat
While screen flows should follow SUCs, don’t spend so much time producing “perfect” SUCs that you leave yourself with no time to produce screen flows.
Takeways:
- SUCs and screen flows are not the same thing
- Do SUCs first, then screen flows
- Model both visually
Related posts:
Leave a Reply