6.4 Tools

A number of tools are available for your use in the Focused iteration. Let's look at each of them in turn .

6.4.1 Surplus Functionality Filter

Reduce scope in this iteration by examining each use case in relation to the system objective. Remove use cases that are tangential to these objectives. Examine each use case in isolation and remove details or features that are not required.

6.4.2 Narrow the Focus of the System

Now it's time to examine the set of use cases for an odd one out. Look for a use case or set of use cases that does not fit well with the remainder of the system. This use case may represent a subsystem that you can identify as a separate project. Look for noncore use cases that core use cases do not use.

The Focused iteration is about pruning requirements detail, duplicates, conflicts, and scope.

graphics/06inf02.jpg

Until your team understands the use cases, avoid the temptation to reduce functionality. Present your findings to the users; it is essential to involve the user community in these decisions.

6.4.3 Identify Surplus Functionality Inside the Use Case

How do you identify surplus functionality? Each use case contains a short description; you should compare the body of the use case to this description to see where additional functionality is being introduced.

This technique is analogous to the comparison you performed between each use case and the system description.

When you suspect that functionality in the use case is excessive, the next step is to decide whether the users can do without it. If they can, it is safe to remove the functionality. If the users need it and if the functionality really is a bad fit for the use case, it is reasonable to move it elsewhere, either to a new use case or into an existing use case. In either case, it has an effect on the dependency relationships to the system. After altering the system, update the matrix. This update is especially important when people are working in teams . The matrix is a communication mechanism that prevents other team members from repeating your work.

6.4.4 Vocabulary Filter

Another important technique in the Focused iteration is to examine your use of proprietary names . For example, a list of requirements that we saw a few years ago stated that the application must provide a Soundex search capability. Soundex was invented in the late 1800s as a means of identifying lost characters in telegram transmissions. Since then, it has been made obsolete (as you might guess) by a number of cheaper, better technology solutions. Did the requirements analyst really want to specify such outdated technology? Perhaps the analyst meant a sound-alike feature or some other nonproprietary feature.



Use Cases. Requirements in Context
Use Cases: Requirements in Context (2nd Edition)
ISBN: 0321154983
EAN: 2147483647
Year: 2002
Pages: 90

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