Requirements management is crucial

It is pertinent to ask how other disciplines of engineering are able to build systems with guarantees, whereas software engineering cannot guarantee anything. Is it due to 'softness' of software or are there fundamental differences?

One fundamental difference between business systems and the systems built by other engineering disciplines is that the later deals with physical world, which is well understood. There are precise models of systems, which scale up. We in software engineering equate models with pictures. But what I mean is that they have higher level of abstractions to express the detail. Be it a set of partial differential equations, or a complex formula of that kind. The key is that these are models rather than enumeration. And system requirements can be expressed in terms of these models and measures used in these models.

E.g. one can specify behaviour of physical system using properties such as Pressure, Temperature. Then one can specify requirements in those terms. The implementer knows how components behave for given input and can construct an implementation meeting the requirements. Implementer can find out what will be the value of Temperature given Pressure. So he can decide how to set pressure so as to achieve the expected temperature.

I think equivalent measures for business systems are Data and Process. Unfortunately we have no clue how they behave in isolation or what is their interrelationship. There are no partial differential equations describing behaviour of data and process. So we have to specify the requirements as enumeration over data and process.
Imagine if an engineer had to specify what will be Temperature for every value of Pressure, and then describing what Pressure range he wants the system to operate in with what max. temperature. Yet, this is what we do as requirement specification in software engineering.

And if your enumeration is not complete, you have a flaw in specification. And nobody can build correct working system, with a flawed specification. Of course we still have a problem of converting a specification to implementation, without introducing any error! The MDA approach is trying to address that. Also manual way of converting requirements into implementation is well understood now. It is a problem, but a better understood one.

Yet there are some systems built using software engineering, especially aviation related or embedded systems (like one found in washing machines), where a more formal approach is adopted. The requirements are specified formally and then validated before implementation is built. It is possible because either the requirement can be specified, as in other branches of engineering, using scalable models or the enumeration is tiny, hence without problem of scalability.

So for business information systems there are following problems,

1. Abilities to represent the abstract specification (the model) aren't mature
2. Completeness and correctness of such a model is difficult to establish
3. Scalability of such a model (model becomes bigger and more complex than the system, for large systems)
4. Converting such models into implementations (if you can address all of above, then you can use MDA approach to achieve implementation or do it manually)
   

These are not easy issues to handle, especially item 2 and 3 in the list above.

What is this got to do with Enterprise Architecture? Well, as an Enterprise Architect one is helping build information systems for enterprise while trying to reduce TCO, protect investment and avoid obsolescence. All the modern approaches, which aim to simplify the building and maintaining of information systems, (e.g. ESB, SOA) have a need for requirement specifications, with its own representation mechanisms (e.g. BPMN). If one is not aware of these fundamental issues in systems requirement specifications, then these implementations are not going to succeed. So while one can delegate the implementation part to vendor tools and project teams, EA must take charge of building, managing and governing these requirement specifications as top priority item. This is also a key to better business IT alignment.