Objective 1: Get a More Detailed Understanding of the Requirements

Objective 1: Get a More Detailed Understanding of the Requirements

By the end of Inception, you should have produced a good Vision as well as a detailed description of the 20 percent or so most essential use cases, at least of the architecturally significant portions of these use cases. You also have a brief description (maybe two to three paragraphs) of the remaining use cases.

By the end of Elaboration, you will want to complete the description of a majority of use cases. Some use cases may be so simple, or so similar to other use cases but operating on other data, that you can comfortably postpone them until Construction, or even never formally describe them. Detailing them will not address any major risks. You should also produce a user-interface prototype for major use cases, if necessary, to make stakeholders understand what functionality the use case provides. Walk through and test each use case with a user , using the user-interface prototype to clarify what the user experience will be and what information is displayed and entered.

As you detail use cases, you are likely to find additional use cases, which then are added and prioritized.

You should also continuously update the glossary. In some cases, you may want to express graphically how different glossary items relate to each other. You do this by expressing the most important glossary items as "domain objects" in a small domain model (see Workflow Detail: Develop a Domain Model, in the RUP, for more information).

As we described in the section Detail Key Actors and Use Cases in Chapter 6, you typically want to "time-box" the activities dealing with use cases to avoid getting bogged down in too much detail. Also note that especially for small projects, you often have the same person take on the role of analyst and developer, meaning that the same person who describes a use case will also implement it. If this is the case, you may want to spend less time on documenting the detailed requirements and come back to them as you implement and validate the use case.

At the end of Elaboration, you will have detailed a vast majority of the requirements (probably about 80 percent). As more and more use cases are implemented during Construction, you will refine each use case as necessary. You may find additional use cases during Construction, but that should be more of an exception than the rule.

For each of our three example projects, you do the following:

  • Project Ganymede, a small green-field project: graphics/g_icon.gif The team finds another use case and another actor. They spend another two hours per use case describing 9 out of the 12 use cases not yet detailed (see the section Detail Actors and Use Cases, in Chapter 15).

  • Project Mars, a large green-field project: graphics/m_icon.gif In the first iteration, the team refined the Vision and found 3 more use cases, making the total number of use cases 43. They described in detail another 12 use cases, adding to the 9 they already created (see the section Detail Actors and Use Cases, in Chapter 15). In the second iteration, they found 1 more use case, but decided to make 2 of the current use cases "out of scope." They also described in detail another 13 use cases, adding to the 21 they already had done.

  • Project Jupiter, a second generation of a large project: graphics/j_icon.gif They updated the Vision, added a use case, and described in detail most of the use cases not yet detailed (see the section Detail Actors and Use Cases, in Chapter 15). They analyzed in detail fixes to major defects that must be corrected and analyzed the impact on the architecture.



The Rational Unified Process Made Easy(c) A Practitioner's Guide to Rational Unified Process
Programming Microsoft Visual C++
ISBN: N/A
EAN: 2147483647
Year: 2005
Pages: 173

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net