history - ユースケースの前の要件を引き出す手法は何でしたか？

Question

同僚にユースケースの引き出しについて少しプレゼンテーションをした後、そのうちの1人が「ユースケースの前に必要な引き出し手法は何でしたか？また、ユースケースは以前の方法よりも優れていますか？」と尋ねました。わからない、誰か助けてもらえますか？

Answer 1

Wikipediaによると、ユースケースは 1986 年に初めて策定されました。

その前 (そしてかなり後) には、事前条件と事後条件、および障害シナリオが指定された 100 ページの退屈な要件定義ドキュメントがあったと推測されます。

ユースケースは明らかです。それが提供する視覚的な単純さについては、詳細なドキュメントよりも優れています:)

そして、ユーザーストーリーが登場

Answer 2

I think it is important to distinguish between the activity and notation. As said above, previously, there was no structure and threfore every requirement was a set of lines. Use cases define goals, specific actors, can include another use case or be extended by another use case and they can be even parametrized. This allows to eliminate much of the duplication in those long requirements documents in an understandable manner. But this is about notation only, use cases as such do not come with any other activity to elicitate requirements than the older technique. User stories on the other hand, without explicit written scenarios, are even shorter in notation. The interesting thing happens, when you write the scenarios for user stories, as with the Cucumber, than you have actually more to write and more brittle description as with use cases, but the important fact is, that user stories offer different activity. Rather than trying to cover the scenarios upfront, you write them on demand, incrementally and iteratively, which means you can better cope with change of requirements. However it is quite hard to remove the duplication from user stories and the Given-When-Then template for scenarios replace functional nature of use cases by finite stae machines.