| Object-oriented programming has, in recent years , radically reduced the amount of time and effort required to build systems. A technology derived from real-time systems, it has been successfully applied to interactive, windows -based user interfaces and the systems they support. One of its appeals is that it is highly modular, allowing pieces to be built and repaired easily without major surgery on an entire system. Moreover, modules can be reused. In recent years the object-oriented community has ventured into the world of requirements analysis. Numerous books on "object-oriented analysis" have appeared, and the UML has come on the scene as a technique for supporting this. There are three attendant problems: First, object-oriented programmers, like all programmers, tend to focus on the technology of producing programs, and they find it less interesting to go out and analyze the nature of a business. The skills required to do that are different, so they may be less likely to have them. The idea seems to have arisen that object-oriented designers are natural systems analysts, although this does not necessarily follow. A second problem is that some authors consider requirements analysis an object-oriented phenomenon . Ideas developed from information engineering and other sources are ignored as though they were irrelevant to the object-oriented world. This has meant , among other things, that disciplines which have been important and valuable to the field for several decades have been simply ignored. In 1991, for example, James Rumbaugh, Michael Blaha, William Premerlani, Frederick Eddy, and William Lorensen published Object-Oriented Modeling and Design . This book presented an object-modeling notation along with a methodology called the "Object Modeling Technique", or OMT. The notation consisted of symbols for the same concepts that Clive Finkelstein and James Martin had presented ten years earlier in their work on information engineering. OMT is concerned with object classes (entity types), associations (relationships), and attributes. The methodology, while it purported to be a significant departure from "traditional software development approaches" [Rumbaugh et al. 1991, p. 146], was very similar to information engineering. Like information engineering, it was based on the principles of "shifting of development effort into analysis", "emphasis on data structure before function", and a "seamless development process". These are precisely the principles that had already been articulated by Messrs. Finkelstein and Martin. One significant difference is that OMT is much more oriented toward an iterative approach. Deep in Chapter 12 the book does give credit to Peter Chen as the inventor of entity/relationship modeling, and it recognizes that object-modeling's techniques are descended directly from entity/relationship modeling [Rumbaugh et al. 1991, p. 271]. But this is not obvious from the language in the rest of the book. Modern requirements analysis is in fact the combined work of many people who have been contributing to the industry for over 30 years. The role of requirements analysis in the system-development life cycle is more important than ever, even with the advent of object-oriented technologies. Contrary to what some say, it has not changed fundamentally with the advent of these techniques. Object orientation has indeed contributed to requirements analysis, but it has less to do with it than some perceive. The requirements analysis process is intended to identify business requirements for information technology, not to determine the technology used to solve those requirements. A properly done requirements specification should be able to guide designers using any technology. The third problem comes from authors who insist on including "object-oriented features" in the requirements process. "Control objects" and "interface objects" are artifacts from object-oriented design , but they are often (inappropriately) described as part of the requirements analysis process. The fact of the matter is that the process of identifying requirements is fundamentally different from the process of applying technology to address those requirements. It should be possible to identify requirements without necessarily knowing (except in the most general terms) what technology will be applied to address them. The same set of requirements might be satisfied by an object-oriented application, by an application implemented with Oracle Corporation's relational tools, or by a set of COBOL programs. | 
