Requirements documentation

In my current project screen flows are an important part of the solution, so off course they need to be described in use-cases because that’s the RUP process. But the more I’m busy with writing this down the more I get annoyed by the way it should be written down.


For example take a overview window in which you see all the users of a system, per user there are 3 options: change mail, identification and authorization. When you write this down in a use-case you’ll get a main flow which describes the overview screen and the adding of users, besides that you’ll get 3 sub flows for editing data. The subflows contain the same logic as adding a user but since the flow is a bit different you have to write it down as a subflow.


As you can read this is a lot of work and error-prone for the analyst who writes it down. But understanding how this is going to work by a user with little experience in reading use-cases is even more problematic. In the video below a nice example of how this goes in a review process is shown by Shoutpark figures where Cartman is the analyst Glimlach