I know that use cases define the user requirements, but what 'document' is used to detail the design requirements, including the navigation through the screens and business rules? In the past, our organization wrote 'user design documents' which detailed everything from beginning to end for a particular process. Everyone in IT was familiar and happy with this type of document. We were introduced to use cases and the team that I am on was responsible for writing them (all without any formal training). Now that we're failing in our project, some of the blame is being placed on the use case writers/requirements gatherers because we didn't document correctly. I'm at my wits end right now. Thanks all. Saving Changes...
Sort By:
George JucanManaging Partner| Organizational Perfomance Enablers NetworkWoodbridge, Ontario, Canada
Regarding your stated question, you may want to take a look at http://www-306.ibm.com/software/rational/o...qanalysis.html. If you're going the use cases route, my advice is to study RUP (Rational Unified Process) and adjust it for your needs - but at least you start with a solid foundation. I attached an Q&A document from Rational that responds directly to your questions.
Now, if you also need advice to recover the project you need to provide more details: exactly in what stage are you, how far behind, what is still on the plan etc.
Hope this helps. Saving Changes...
I know you didn't mean anything in a bad way so please don't take this personally because I don't mean it personally but I'm SO sick and tired of CASE tools being offered as the silver billet. I personally have seen too many CASE tool implementations (either Rational or Caliber RM) go bad. Not because they are bad tools. They are really awesome tools! I love Rational and CaliberRM. The problem comes in when management believes that implementing the software will solve the sdlc 'problem'. Even if you don't implement the software, believing that using 'Use Cases' will solve your problems is equally wrong - You have to learn how to crawl before you can walk. The people using the CASE tool (documenting the requirements, designing the application or database or test plan) have to understand how to walk through the SDLC with a golf pencil and paper first. To understand what the requirements are used for and who reads the various types of requirements. To really understand what a DBA needs, a developer needs, a UI Designer needs, a QA engineer needs, a software architect needs, etc... The requirements analysts\engineers also need to understand how to ellicit the various requirements from the business. Who frankly, almost always try to solve the HOW instead of stating the WHAT as they should. Let IT figure out the HOW. It's understanding when and where you need to document the various different types of requirements... to not just capture the use case but also the dataflow diagram, usability requirements, performance requirements, quality requirements, security requirements, maintainabilty requirements, etc... to know when to use interviewing, questionaires, brainstorming sessions, prototyping, task demonstrations, or focus groups... to know how to validate those requirements, etc...
To specifically answer the original question - "Use cases are only "Chapter 3" of the requirements document - the behavioral requirements. They do not contain performance requirements, business rules, user interface design, data descriptions, finite state machine behavior, priority, and probably some other information." (Cockburn, 2001) Whether you alter your use case document to include the various sections I described above or maintain a seperate document is up to the team. Whatever makes the most sense for the team. However, "just be careful not to force into use cases those requirements taht don't fit the use case form. Use cases are best suited to the capture of interactions between actors. ... Only a fraction of the requirements set is suited to the use case form. It just so happens that the interaction part is central and connects many other requirements." (Cockburn, 2001) To Paul - it sounds like you actually were documenting what you needed in the "user design document" - Why did the team stop using that? You also hit the nail right on the head when you made the statement "without any formal training" - It never ceases to amaze me that management believes that writing requirements is something anyone can do. That simply isn't the case - would you let someone that can do simple math, be your accountant? Then why would you let someone without the proper education write requirements? This does a dis service not only to the company but to the analyst most of all who is only trying to do the best job they can.
Okay - sorry for the long rant. If you are at all interested in learning more, I suggest picking up Alistair Cockburn's "Writing Effective Use Cases", Soren Lauesen's "Software Requirements Styles and Techniques" and Suzanne and James Robertson's "Mastering the Requirements Process". If you are interested in having your team take some requirements classes, I recommend any in the ESI International series for Business Systems Analysts (www.esi-intl.com)
And George - I DO agree with you on the second to last statement. One would need to know where in the process Paul is at and what the major constraints are that he faces...
REFERENCES
Cockburn, A., 2001. Writing Effective Use Cases. Addison Wesley Saving Changes...
