Problem Analysis

Requirements come in all shapes and forms and from a variety of sources. For example, they may be presented in the form of written documents by an end user, via meetings with visionaries in the company, or via direct customer interaction and face-to-face visits.

Projects often fail because the requirements were not accurately understood. This is not too surprising in light of the fact that language, whether written or oral, is imprecise by nature and open to multiple interpretations. So, the first thing to do is to make sure the basic requirements are understood; that is, go beyond what is obvious and stated in the requirements document. It is only through such an approach that you can really identify the essential usage patterns for the software system you will be developing.

This is where use cases come in. You can apply use case modeling to develop a precise model of what is required of the system, and then utilize the use cases as the basis for driving other aspects of your enterprise system development. In effect, a use case acts as the string that binds the beads of a necklace together. Use cases bridge the gap between the end user and the requirements of the system. They can be used to establish tractability between functional requirements and the system implementation itself.

The analysis is best done in a group setting. It helps to have different people looking at the same requirements from their individual points of view. It is usually also helpful to have a domain expert take part in the discussions. Participation of the customer, or author of the requirements, is also beneficial so that you can gain firsthand knowledge of the intent. All this deliberation may save you a lot of rework later. Some techniques that can be used at this stage to get to the bottom of a problem include brainstorming sessions and fishbone diagrams.

When going through this stage, it is helpful to try to reduce duplicate requirements and distill the overall set of requirements into a smaller number. Avoid the temptation to do the design at the same time as gathering requirements. Requirement-creep (similar to feature-creep where features continue to grow way beyond the original intent) should also be avoided by exerting a vigorous attempt at traceability to the customer needs.

For a more thorough discussion of this topic, see Object-Oriented Analysis and Design with Applications, by Grady Booch, Addison-Wesley, 1994, and Use Cases-Requirements in Context, by Daryl Kulak et al., Addison-Wesley, 2000.