Using OO Modeling for Requirements Analysis

Related Sites

[...] in my experience, object orientation and requirements often make a bad marriage. (That's often, not always.) Of course object orientation is a wonderful set of ways to structure programs and model the real world. But its very strengths in the program-and-models realm tend to cause trouble when talking about the real world directly.

For example, the idea of a class and a set of methods that operate on it is a very useful discipline for keeping programs simple and maintainable. But to do this, you have to make many decisions that apply only to the model and correspond to nothing in the real world. A very common and important design decision is: which class gets which methods? Do you give the 'bake' method to the 'cookie' class or to the 'oven' class? In reality, cookies bake when you put them in a hot oven. Neither one of them has the 'bake' operation all to itself.

What I've seen happen -- probably doesn't happen to everyone, but it happens -- is people puzzle over these model-related decisions while writing the requirements. Trying to "be object-oriented" in requirements instead of just trying to be useful often leads people to describe the problem domain in terms of concepts that are appropriate for describing data structures and flow of control in a computer program -- which is to say, not to describe the problem domain at all, but to describe a computer model instead. I've seen people give the customer a huge list of classes and message traces and the like, which might all be good program design, but come from an utterly different world than the one that the customer knows about. The customer has no idea what the developers are doing, and most of the benefit of writing requirements is lost.

My own view is that requirements are best written entirely in terms of the problem domain. That means using no concepts of program structure at all -- not concepts of structured programming, not message-passing, not classes and methods, not polymorphism, none of that. (The logical concepts of genus and species apply generally, of course. That's the relation that is sometimes good to model using inheritance -- and sometimes not.) Doing OO program design well is just a different skill from understanding the problem domain and what would be useful to make happen for the customer there.

[...]

OO for requirements seems most appropriate when the problem domain is the computer model [...]. Unfortunately, when it's the only tool in one's bag, people often end up framing every problem domain as a computer model, often without even noticing.

I have always taken the advantage of OO -- whether Analysis, Design, or Programming -- to be that the objects remain the same throughout the whole process of system production, and are those of the problem domain; unlike traditional real-time analyses such as Ward-Mellor, where after you have done your analysis, there is an out-of-the-blue creativity step, undocumented, that results in the program design, where the things (not objects!) being programmed tend to bear little resemblance to the objects originally analyzed.

Indeed, I think that you have to look at three "out-of-the-blue creativity" steps in every project. [...]

The first is inventing the requirements. I don't say 'capturing' or 'gathering' the requirements, because requirements, at least as I use the word, are effects that we've decided that we would like a computer to produce -- in the problem domain. We make those things up, and we're limited only by our imaginations and what we think we can make computers do.

The second is inventing the interface design. User-interface design is of course very creative work, but so are other kinds of interface design. In interface design, as opposed to requirements engineering, you're solving a well-defined problem: think of behavior at the I/O devices that will cause the requirements (statements about the problem domain) to become true.

And the third is inventing the program -- the complex settings of switches inside the computer that make it behave one way rather than another way. Today of course we use high-level languages instead of describing each bit in memory that the CPU executes, but the problem is still the same: think of representations, think of executable instructions, think of "inside the memory stuff" that makes the I/O devices behave as specified in the interface design.

Because these are three different domains -- three very different parts of reality, containing very different things and about which we assert very different propositions -- I think it's usually (not always) a mistake to try to make a single set of 'things' that remains the same in each. Inevitably, the vocabulary of one domain blots out the others. If we think in terms of establishing relationships between domains, we don't have that temptation.

Ben Kovitz, Practical Software Requirements: A Manual of Content & Style

Desmond D'Souza, From Domain to Code: Model vs. Design