The title may be a bit misleading as it also includes how to solution. The book advocates using use case models and use case specifications (detailed use case descriptions) do model requirements.
Does the book target develoeprs or analysts or both, or neither specifically? It (and these agile v BA discussions) made me go back and think about why we work so hard to separate requirements from the solution.
The high level reasons is that we are supposed to define the prpoblem properly before we start wrking on the solution. This stops us going off half cocked on what can be very expensive solution options that may not be the best fit. Additionally, requirements elicitaion and analysis are specialist skills, same as coding and designing. But where the develoepr is doing the analysis, or the analyst is doing the development (eg in a rules engine or in a simple web build) why break them apart?
The books, in it's own words, targets "IT Business Analysts". From reading the book, it looks like it's geared more towards "Business Systems Analysts" and "Systems Analysts" and not as much to business case and vision development.
- Adrian
Yes, Use Cases are good for Requirements. My understanding is that Use Cases are not UML artifacts, that they pre-date UML by some time. Its just that they both got popular about the same time and they were used together. My earlier comment about developers saying I should not use UML, I should clarify that they did not include Use Cases in their 'ban', so Use Cases and Data/Concept Models is what I used for Requirements and provided those to the developers for design and build activities.
A parallel issue to this is the position that some people hold that Class Diagrams and ER Data Models are equivalent; you can probably guess that I don't agree, anyone want to know why?
Dave W
I have my thoughts on this, but yes, please share with us.
brought to you by enabling practitioners & organizations to achieve their goals using: