Design / Architecture from Requirements

> Is there a good article / book with real examples of

> how to arrive at a system design / architecture from

> requirements ?

There must be thousands.

> Also, is there a defined way to organize the

> requirements captured so that it would be easy to

> translate it into design ?

There must be thousands.

> We have captured our requirements from a data and

> process perspective. I have a hard time to organize

> them and break them up and to finally translate them

> into design.

>

> Any pointers would be of great help to me.

In what form have you "captured your requirements from a data and process perspective"? To me the output of requirement analysis is in the form of formally described test scenarios. That is, I distill User Stories (Use Cases from the user's point of view) from the verbal requirements, and derive scenarios from them; these scenarios are basically descriptions of acceptance tests.

Given that, I take the first (the most simple) of these user stories and break this up into as many independent, "atomic" tasks as possible. At the point I'm describing these I usually have a pretty good idea of what interfaces and classes will be needed, and I can start writing unit tests. Often, when I feel during "task analysis" I'm just literally writing in English what my test code will be, I skip formally describing them and just write the tests straight away.

When the unit tests are ready design is done, skeleton implementations are there and the rest of the code pretty much writes itself ;-)

Next story, same deal; always adding tests & refactoring & regression testing.

story -> scenarios -> acceptence tests

tasks (-> scenarios) -> unit tests

refactoring ->additional classes -> new unit tests

That's, in a nutshell, how I do it. As you can tell, this is leaning close to the eXtreme Programming way of working; and as you can equally tell, I believe strongly in test-driven development, designing from test code, and emergent design.

So if I were to point you to any articles or books, I'd tell you to aim your google at "extreme programming" and go from there. The first two hits will be the two main XP web sites.

As I said there are many different methodologies each covering more than just A->D, and a lot has been written about them. The above is my personal preference - you'll have to evaluate if it can be suitable for your project and team.

One final pointer (I'm going on aren't I) is this: whichever way of working you use, evaluate it constantly. For example, if you decide to make a lot of UML diagrams, evaluate the time spent vs the return. If your team feels there really isn't enough actual benefit, stop doing it; if they feel it does pay off, by all means keep doing it.

Lokoa at 2007-7-14 17:18:01 >