2

I have to write a software requirements specification for a software system that consists of two front-ends, an Android app as well as a web-application. The Android app and the web-application have similar use cases, but the web application offers more options: Contrary to the Android app for instance the web application has the option of CSV export when the user enters the "Edit catalog item" use case.

How can I avoid duplicating the same use case diagram and use case specification without omitting the additional features the web-application offers?

2

The answer is quite simple: you are building two different applications, so you will have distinct use cases for every application (system).

Just postfix your use case names with "for Web" and "on Android" so you see clearly that you are describing different things. It is clear that you feel a need to optimize by not duplicating requirements, but you must duplicate requirements at system level, because they are specific to the system you describe.

Just a practical advice from my experience with such situations: just start with a copy of the use case from one system, then go into the details. That is cheap. You will find very early, that the use cases do not remain the same since they are the place where you document the differences. Do not try to add something like delta descriptions ("I am like this base use case plus one difference regarding that point...") to your requirement spoecification. This kills all the benefits of use cases in a minute.

0

As far as use case diagrams go, I tend to agree with Martin Fowler's thoughts on the subject:

Use cases appear in the UML in the form of use case diagrams, but these diagrams are of little value - the key value of use cases lies in the text which is not standardized in UML. So when you do use cases put your energy into the text.

If you consider other methods of capturing use cases, such as a tabular format, you can annotate them. If you search for formats for capturing use cases, you can find plenty of examples of textual and tabular formats. In one of these formats, it would be much easier to annotate the fact that a particular use case or even a particular alternative flow or alternate course through a use case only exists in one platform or version of the application.

All of that said, there may be value in using a diagram as a "map" to your use cases. If you do decide to include a UML Use Case diagram, you can focus on linking actors to use cases which have a more detailed description in your textual or tabular formats. In the diagram, simply link the actor(s) to their use cases and in the use case symbol, indicate the name or identifier of the use case and use the tabular or textual format. In this particular example, an actor would link to an "edit catalog item" use case and the reader would be expected to read elsewhere if they wanted a deeper understanding of what it means to edit catalog items.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.