Gord FogelSenior Director Project Management and Professional Services| GF2 Inc.Toronto, Ontario, Canada
I've had great success with RUP. Our development and testing teams love it. From the project management side, I'm happy with the iterative approach. I can honestly say I've gotten way better software quality from RUP than any other approach I've used.
My query: Users who need to sign off on requirements. These are business folks. They don't know UML. Diagramming techniques for Use Cases are foreign to them. They want good old textual materials they can read by the fireside. Business function, screens, reports.
I am looking for comments and ideas on how to produce traditional requirements specifications from Use Cases. Saving Changes...
Sort By:
Andre LeclercExecutive Architect for BI| UnisysRockwall, Tx, United States
Dear Gord,
I understand what you are saying. Users like pictures but would rather read mini-books along with the pictures.
Users expect requirements to be textual in nature. UML diagrams for use case are minimal and do not provide enough details. To do the job with just diagrams you would have to include sequence diagrams and robustness diagrams (a la Jacobsen) or activity diagrams for the use case details.
RUP is weak in this area. In fact UML has nothing to say about requirements. Requirement definition is a separate function. Requirements can be defined using some of the UML views and diagrams. RUP proposes a way of doing this but there is no depth.
I found the textual approach proposed by Cockburn for writing use cases very useful for requirements definition. See his book on Writing effective use cases.
The pure requirements approach promoted by Leffingwell in his recent book "Managing Software Requirements" to be of use. He represents the UML/RUP party line about requirements and use cases.
Let me know if you want to discuss this any further. It is a topic of interest to me.
Regards Andre Leclerc gantthead SME Saving Changes...
I, too, agree. I've found that documenting use cases in textual form is a good requirements gathering tool. I find almost no use for use case diagrams.
In a project we've recently started, we identified three major needs for documentation: interface design, business rules, and data structure. So we are taking a three-pronged approach to documentation: prototypes, textual use cases, and a data dictionary tool that both creates physical data files and allows for diagramming. We are trying to take a minimalist approach (in the agile way) until we think we need more documentation.
This is an in-house project, though, and the need for excessive sign-offs just isn't there. Using a highly iterative approach with lots of interaction with the users and a quick feedback loop with prototypes and designs has eliminated the fear of them not getting what they want. Saving Changes...
