Object-oriented requirements analysis

Developing object models during requirements analysis usually simplifies the transition to object-oriented design and programming. However, I have found that end-users of a system sometimes find object models unnatural and difficult to understand. They may prefer to adopt a more functional, data-processing view. Therefore, it is sometimes helpful to supplement object models with activity charts or data-flow models that show the end-to-end data processing in the system.

In object-oriented requirements analysis, you should model real-world entities using object classes. You should not include details of the individual objects (instantiations of the class) in the system. You may create different types of object model, showing how object classes are related to each other, how objects are aggregated to form other objects, how objects interact with other objects and so on. These each present unique information about the system that is being specified.

The analysis process for identifying objects and object classes is recognised as one of the most difficult areas of object-oriented development.  There have been a range of different approaches proposed to object identification including:

In practice, you normally use a mixture of all of these approaches to identify the objects in a system being analyzed or in the system that you are designing.

Various methods of object-oriented analysis and design were proposed in the 1990s (Coad and Yourdon, 1990) (Rumbaugh et al., 1991) (Jacobsen et al., 1993) (Booch, 1994). These methods had a great deal in common and three of the key developers (Booch, Rumbaugh and Jacobsen) decided to integrate their approaches to produce a unified method (Rumbaugh et al., 1999). The Unified Modeling Language (UML) used in this unified method has become a standard for defining object-oriented models.


Abbott R. (1983). Program Design by Informal English Descriptions. Comm. ACM, 26(11), 882—94.

Beck K. and Cunningham, W. (1989). A Laboratory for Teaching Object-Oriented Thinking. Proc. OOPSLA’89, New Orleans, ACM Press.

Booch G. (1994). Object-oriented Analysis and Design with Applications. Redwood City, Ca.: Benjamin Cummings.

Booch G., Rumbaugh, J., et al. (1999). The Unified Modeling Language User Guide. Reading, Ma.: Addison-Wesley.

Coad P. and Yourdon, E. (1990). Object-oriented Analysis. Englewood Cliffs, NJ: Prentice-Hall.

Jacobsen I., Christerson, M., et al. (1993). Object-Oriented Software Engineering. Wokingham, UK: Addison-Wesley.

Robinson P. J. (1992). Hierarchical Object-Oriented Design. Englewood Cliffs, N.J.: Prentice-Hall.

Rubin K. and Goldberg, A. (1992). Object Behaviour Analysis. Comm. ACM, 35(9), 48—62.

Rumbaugh J., Blaha, M., et al. (1991). Object-oriented Modeling and Design. Englewood Cliffs, N.J.: Prentice-Hall.

Rumbaugh J., Jacobson, I., et al. (1999). The Unified Modeling Language Reference Manual. Reading, Ma.: Addison-Wesley.

Shlaer S. and Mellor, S. (1988). Object-Oriented Systems Analysis: Modeling the World in Data. Englewood Cliffs, N.J.: Yourdon Press.

Wirfs-Brock R., Wilkerson, B., et al. (1990). Designing Object-Oriented Software. Englewood Cliffs, N.J.: Prentice-Hall.



(c) Ian Sommerville 2008