This chapter is from the book
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.