This chapter is from the book

This chapter is from the book

Use Case Migration Problems

I have worked with large groups of traditional software developers to
introduce them to the use case technique for documenting system requirements. I
have encountered some very strong and unexpected resistance to the use case
approach from these developers as represented by the following comments:

Our users don't know what they want, so our users cannot develop use
cases. Unfortunately, many experienced developers have encountered potential
information system users who do not seem to know what they want from an
information system. These traditional developers still believe that it is their
job to try to understand the users' business and then to write the use
cases for the users.

I believe what is really happening here is that the traditional developers
and their clients don't really understand a user-centered approach to
documentation. The use case is the externally visible behaviors (e.g., screens
and reports) of the interactions the user can have with a system. If the users
truly have no concept of what they want out of a system, it is unlikely that the
successful implementation of any system is possible, regardless of what
techniques or technology are used.

I have found it effective to introduce the use case technique to the users
by showing them generic use cases for common business processes, by showing them
use cases from similar systems or even from competitor's systems, by
starting the use case development process by mocking up screens and reports
before trying to develop the use cases, and by using existing training manuals
to create use cases of the users' existing systems. If, after exhausting
all of these approaches to introduce the users to the use case technique, the
users still say that they don't know what they want from their new systems,
I recommend that the project be cancelled.

We need more details. Traditional developers become distressed when
they read user-centered documentation. They see only externally visible
behavior. While they can create the "look and feel" of the reports and
screens that contain the inputs and outputs of the series of user stimuli and
system responses described in a use case, they are upset that they do not have
any information on the processes and algorithms necessary to code the system.
This is another common misunderstanding about the use case technique. Use cases
will never be sufficient documentation from which to begin coding. After the use
cases are written, there has to be the collection of the nonfunctional
requirements of the system. These nonfunctional requirements include features
like response time, availability, transaction volumes, integration with legacy
systems, security, and persistence strategies. The nonfunctional requirements
are the basis for establishing the system's architecture. After the
architecture has been established, the process of identifying and designing the
components of the system begins. The components of the system will contain the
processes and algorithms necessary to provide the functional and nonfunctional
requirements of the system. The analysis and design of these components is done
using a systems development methodology. The use case approach is not a complete
development methodology; it is just a technique to document the externally
visible behavior of the system. The use case tells what the users want from the
new system, it does not tell how to design or construct the new system.

We want to be end-to-end developers, not specialists. Many
traditional developers expect that they will be fully involved in all phases of
a new system development. They will gather the requirements, plan the
architecture, design the new system, do the coding, conduct the testing, train
the users, and write the documentation. The full benefits of the use case
technique, however, come from the specialization of duties. One team of expert
user interface designers will be working with the users to develop the look and
feel of the system's screens and reports. Another team of business systems
analysts will be working with the users to develop the sequences of behavior of
the new system. The third team, consisting of systems development specialists,
will be involved in the design and implementation of the components necessary to
provide the functional and nonfunctional requirements of the system. It is only
this third team that may be involved in the writing of any code. Hopefully,
however, this third team will be using CASE tools to generate the code, reusing
existing code and design patterns, or even using software component factories to
implement the required system.

The expectation of end-to-end development may be leading to the
developers' rush to details. The sooner they collect the algorithms, the
sooner they can start to code. In the three-team approach there is no
inappropriate rush to code. The specification of algorithms is deliberately
postponed until after the user interfaces have been designed and approved, after
the use cases have been written and accepted, and after the system architecture
has been created. The business systems analysts team is done with its part of
the project when it has assisted the users with the development of the use
cases. The user interface team is done with the project when it has assisted the
users in the development of the look and feel of the screens and reports. The
implementation team that will actually develop, generate, or assemble and reuse
the components of the system only becomes involved with the project after the
architecture has been established.

Iterative development will result in the project's scope and
budget going out of control. Traditional developers become upset that the
interactive specification of requirements by the users will result in the
uncontrolled increase scope of the system. The use cases are revisited at least
four times over the course of the systems development life cycle. For example,
the Rational Unified Process specifies that during the inception phase, use
cases are employed to set the scope of the project and to assist in the
development of the business reasons for the development of the new system.
During the elaboration phase, more detailed use cases are created to help with
the setting of the system architecture and to help develop the plans for
constructing the system. During the construction phase, use cases become the
starting point for design and for the development of testing plans. Finally,
during the transition phase, use cases are used as the basis for the development
of user manuals and user training. One of the most difficult lessons for
traditional developers to learn is that the iterative process often actually
decreases the number of components in the system. More use cases do not mean
more code. Common behaviors may be abstracted from multiple components and
refactored into just a single component. Additional use cases may be just new
sequences of services from the existing components.