Which other terms form a part of this semantic field? 

-          OOSD (object oriented software development)

-          Business process modeling

-          Subject-specific models

-          Use case analysis

How is OOA defined?

Heide Blazert:
“Elicitation and documentation of the requirements of a software system using object-oriented concepts and notations. The result is an OOA-model”.

Grady Booch: "Object-oriented analysis is a method of analysis that examines requirements from the perspective of the classes and objects found in the vocabulary of the problem domain."

What for do I need OOA and when do I employ it in what way?

 OOA is necessary to document the business logic of a complex system concisely, clearly and in a simple fashion. Object-orientation helps document a complex system with adequate means, without getting lost in texts which depict arbitrary exceptions. The semiformal notation used in OOA furthermore makes it easier to find the gaps in requirements quickly and effectively. Moreover, the object-oriented approach perfectly supplements iterative processes, since the system can be illustrated in a well-arranged fashion and a smooth transition from the analysis phase to the design phase is possible. OOA is one of the techniques used in system analysis. When visions, goals and requirements concerning a new system have been elicited, the analyst will model the business requirements as part of OOA. This analysis model is then refined, until it is suitable as a basis for design and architecture of the system (depends on the process model chosen).

What may happen if I don’t use OOA?

If no OOA is practiced during the analysis of a large, complex system, this will lead to an incomprehensible and confusing description of the system. In the worst case, the project members will fail to understand their system, resulting in a defective implementation. In such cases, the OOA is then done at a later stage or en passant. One of the main reasons why architectural, design and testing-activities taker longer than planned.

Do I absolutely need a tool in order to do OOA?

OOA models can be created using pen and paper. But using a tool which helps you create models has many advantages. In midsized and large projects, where several analysts are involved, a tool is absolutely necessary. Because views can be generated and consistency checks performed, the overall model complexity becomes manageable.

What does OOA cost, what advantages are to be gained?

In order to carry through an OOA, some effort has to be made to represent the business requirements using models and to make sure the models are comprehensive. Since this effort would be necessary just the same, if no OOA were performed, the costs involved are quickly amortized, since they don’t arise during other project activities. Because every single activity becomes a little less complex, the overall costs are even reduced.

Who usually employs OOA?

OOA is usually employed in projects with a duration of more than one year and where large numbers of requirements (>1000 letter-sized page specifications) need to managed.

Another good reason for using OOA is the lack of knowledge the software developers usually have concerning the area of expertise for which the system is to be designed. OOA will help systematically depict and understand the area of expertise in question (this doesn’t vary with the size of the project).

What kind of formation must I have undergone to be able to use OOA?

In order to carry through an OOA, an intimate acquaintance with object-oriented methodology is a prerequisite. Knowledge about such elements of OO as classes, generalization, composition and concepts such as encapsulation, interfacing and cohesion are vital to an analyst performing an OOA.

The tools of the trade furthermore include the most commonly used form of notation, the unified modeling language (UML). The types of diagrams available and under which circumstances they are put to use comprise the basics of what an OO-analyst should know.

From which websites and books can I obtain more information?

www.cetus-links.com

http://hillside.net/patterns/

Balzert H.: Lehrbuch der Objektmodellierung, Spektrum Akademischer Verlag 1999

Larman C.: Applying UML and Patterns, Prentice Hall 2001

Jeckle M.: Rupp C.; Hahn J.; Zengler B.: UML 2 glasklar, Hanser Verlag 2008

Oesterreich B.: Objektorientierte Softwareentwicklung, Oldenbourg Verlag 2001