Monday, March 3, 2008

Software Requirements come first or Software Architecture?

Traditionally, requirements engineering paradigm has promoted the idea of separation of problem space from solution space when thinking about the requirements and design solutions. In this way, analysts do not bother to think of how, when they are focusing on what, and later on they look at the list of requirements and come up with an architecture design for the mess of requirements. It has been counted as good thing. However, for a reason I don’t know, always someone comes that says, oh no, you have all been so wrong. Twin Peak, which is an iterative process model, inspired from Boheme Spiral process model, suggests architecture and requirements should be developed in parallel and iteratively.

I like this idea, and I’d like to find a way to prove it. I have convinced myself with reasons, like: if we gather a list of requirements without thinking of their feasibility, we have just developed a wish list, not more, not less. They are not software requirements that in the next phase a designer develop them. In addition, when we close eyes to solution space, we may guess that some requirements are in conflict, usually happens for privacy and security. However, the impact and interactions of requirements on each other, do not come from the nature of requirements, but come from the nature of solution that implements the requirements.

1 comment:

Paul said...

I liked your post. What you are missing is seeing IT architecture for more than a project level. Detailed design and IT architecture are two seperate things. Detailed design can be done by experienced developers. IT architecture is simple. It is is technology strategy. Basically it is the ways we use technology to make or save the company money (or other shareholder value).

To get to where you want to go you need to look at architecture as a primary function that happens before, during and after projects. Architecture isn't temporal in nature the way that an IT project is. It includes portfolio management and other common vehicles for understanding not what and how you build something but why.

You can find out more details on this at