Regarding growing of Behavior-Driven Development imposing acceptance testing, are use cases diagram useful or do they lead to an "over-documentation"?

Indeed, acceptance tests representing specifications by example, as use cases promote despite of a more generic manner (since cases, not scenarios), aren't they too similar to treat them both at the time of a newly created project?

From this link, one opinion is:

Another realization I had is that if you do UseCases and automated AcceptanceTests you are essentially doubling your work. There is duplication between the UseCases and the AcceptanceTests. I think there is a good case to be made that UserStories + AcceptanceTests are more efficient way to work when compared to UseCases + AcceptanceTests.

What to think about?


2 Answers 2


In my opinion and in an Agile perspective:

Use cases, Class diagrams, Sequences Diagrams and other UML stuff are excellent conversation tools. They are really neat when you need to sketch or explain ideas on a white board for example to make sure we get a common understanding of what need to be achieved at the moment of the conversation.

After the conversation happened they should be discarded/erased/not kept.

So to answer your question, yes they are over documentation if you attend to put them in a document. But as I explained, their most interesting feature is not to be stored in pages of design documents but to be used as tools to help conversation within the team.


I think it depends on the maturity/life-cycle phase of the particular feature as to how useful the diagrams are to the process.

For new features and documenting outside in intent of features that are otherwise uncovered by automated acceptance tests, diagrams are useful. After adequate tests are in place, a bit less useful.

Nevertheless, they have value regardless of what and when. If you go to the trouble of creating them, hang onto them. Perhaps treat them differently than traditionally prescribed. Contrary to the RUP, don't treat them as living documents that get updated -- simply as a one time effort most useful and applicable to only a certain instant in time. The drawings may not be "the" basis, but they were a basis for the decisions and design of the feature.

  • Excellent point, software is a living changing thing, diagrams are just a snapshot at a specific point in time.
    – maple_shaft
    Dec 14, 2012 at 3:26
  • documenting outside in intent of <x> sorry, what does this mean?
    – n611x007
    Aug 26, 2015 at 12:33
  • by RUP I guess you mean Rational Unified Process
    – n611x007
    Aug 26, 2015 at 12:36

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.