Requirement landscape with Croquet

Requirement Engineering is something which I'm looking at for many years now. And I always was and be interested in this. But one thing I am still waiting for: the visualisation of requirements.
So one might ask: visualisation ? Requirements are texutal, semantic-rich objects, nothing which would come close to that what is needed to making charts or some interesting 3D pictures. Well, this may be right. But requirements have structure: they are related to other requirements, they build groups. In addition, they have an inner structure, if they are built using methods available for professional Requirement Engineering. Visualizing requirements related to such structure aspects would be the same as visualize the network or graph of requirements. Clusters or too sparse regions of the requirement network should be visible at once.
But I think, there could be done more. The set of requirements should describe as complete as possible the system to build or to engineer. This set as a whole should be able to induce the picture of software. By reading the requirements, one after one, this picture becomes existent in the mind of the reader, and its shape and details become more and more complete with every requirement read.

But: wouldn't it be nice to visualize exactly that process ?

In the result, this visualization would show which requirements covers to which extent which aspect of a system. For example, the system would be a landscape, or a city street plan, and the size and position of the requirements show there contribution to the whole (system).
Since a while, I asked myself if Croquet would be a optimal tool for such visualizations. The space metapher and even more the collaboration possibilities of Croquet seems promising for such visualization experiments. Unfortunatly, I have no time, so I really hope that some other will do some experiments in this direction.
This is I would do:

• defining a meta-model of requirements, to adress the aspect of their inner structure, just like EMOF for conventional models. I mean not a semantic model, only a structural model (Conditions, quantors, action, object, subject, test criteria ...)
  
• defining a meta-model for describing always needed aspects (=questions) for a software project, let's call it system meta model. You could imagine this as a checklist of questions need to be answered in most projects.
  
• defining a semantic meta model, to describe the relations between semantic in general, requirement parts, and the system meta model.
  

That are only raw ideas. Too bad, I had no time.....

Decisions of a Software Architect

In the past, it was not so clear for me what are the things which are constitutive for the work of a Software Architect. This is especially true if the question comes up how to distinguish a Software Architect from a Software Engineer. At the moment, my work for the company is made up of UML, pure architecture design and requirement engineering. From this, I remarked some things which may be surprisingly important aspects of the work of a Software Architect. I will call them "surprising", not because I never thought about them, but because their real effect and importance for the practice hit me strong in these days.

If a new system has to be made, it all starts with requirements. Everyone know that. Some people regard requirement engineering as collecting a bunch of text or a big set of items in a database in order to describe some properties of the system to build. For me, requirement engineering is much more: it is the search for and identification of the model describing the customer universe at best. Such a model must describe the processes and informations which constitute this universe and in which the new system will be embedded. We will see why this is important.

From theory I know about the value of Use Cases and UML Activity Diagrams in the context of requirement engineering, but I was surprised how useful they are to perform that requirement engineering as desired above. By bounding requirements to Activity Diagrams and Use Cases, it is possible to get an output of a requirement engineering phase which - beside the description of the properties of the new system - give an answer to the question, which actions are performed by who, which are the needed informations, which are the resulting informations and how the system to build will fit in this universe.

This all is the input for the Software Architect, and he must use it to find answers to this question:

Which are the parts of the system to build, and how must they interact ?

Well, this seems trivial, and it is even more easy if processes and information flow in the customer univers is known. But now comes a surprising aspect:

Which of this parts of the system are described at best by the data they use and compute, and which parts are described at best by the processes they perform ?

The answer to this depends not only on the properties of the future system, it depends strongly on the nature of the processes and information flow in the customer universe. The outcome of the architectural decision has very long-range consequences because it determines the complete design- and implementation process: a data-driven architecture has other characteristics than a process-driven architecture. Shure, data and processes are not independend. But for the technical design process it is different if one think first in terms of data or if one think in terms of a sequence of actions.

In the data driven world, the next decisions are related to questions like who, how often and in which way the data access will happen. In the process related world, the Software Architect has to decide about events, sequences and has to work with the time.

Beeing at this stage, the next suprising aspect, the next decision point has to be regarded, which as hughe impact to the design:

What are the points of possible change ?

Here, the Software Architect must invest phantasy and experience to identifiy the "weak" parts in the required system. He must look for the things which may be not so fix as the requirements suggest, and as a result, he must decide what things of the system (roles, data, actions) must be designed in a way that a change would be easy. This is only possible if the requirements describe more than the system itself. I think that the best sources to find such points of possible changes are the relations of the system to the universe of the customer.

And here, we are at the heart of the work of an Software Architect, as I belive it: find a design, which make change in the forseeable way easy. This gives the material to make further design decisions, it helps to reduce the set of possible solutions for a design task, to make the system that what is every time told to us: make it simple, but not simpler. Design for change, but only for that, which will be needed. The power of design for change is that what me really surpised ....

Now the detail work can start. But one thing remain, which I often discussed with colleagues: what about technical constraints ? Must an Software Architect know about the possibilities and properties of certain technical solutions ? Well, at this stage, my assumption is that he must not. In the opposite: the Software Architect must find a design, which can adapt certain techniqal constraints. So the decision point would be:

How can the design made robust against the technical constraints and implementation ?

If writing an required amount of data on hard disk is not possible by simply writing to one single file, an architecture is needed which handles multiple files. The Software Architect can not know all detailed constraints which comes from the many-years experience of a software developer, or from a data base specialist, a web specialist etc. In addition, such constraints are change points "from the bottom". Yes, the architect must have a rough knowledge of what is possible with today techniques, but only in order to be not too unrealistic. Therefore, a Software Architect must keep contact with specialists . By the way, here I also see the border to the role Software Engineer: this one must have detailed technical knowledge, and therefore may be responsible for the "lower" or detailed parts of an architecture. He has to bother with detailed technical details.

So, as a summery this decisions help to come to architectural decisions:

- What are the roles, and the parts of an system, and how interact they ?
- Which parts are data driven, which are process driven ?
- What are the points of possible change in the customers universe?
- What are the points of possible change from the technical implementations ?


Of course, it will not be all of the Software Architect, but it really helps ;-)