Wednesday, September 17, 2008

[Arch] Requirements?!

The Waterfall Requirement

I find this really interesting: In talking with many people who actually do make Software in the last years (not only talk about it *g*) I think I detected that many have a growing problem with the term "requirement". Martin Fowler sums it up greatly in his recent blog post. He makes a strong point in saying that the understanding that many people have about "requirements" is actually still very much driven by a waterfall-like understanding of the software engineering process.

As a matter of fact, requirements seem to be problematic on so many levels: on the level of customer/programmer relationship (do they understand each other), on the level of abstraction, how to manage them, how to test if the implementation follows the requirement that we hopefully have understood correctly, just to name a few. A story often heard is "we spent months with the customer building lists and lists, pages and pages of requirements or bought expensive requirement management software, and in the end the development of the product was very decoupled from these lists; but good to know we have them in the files.".

Now my question is this: the trail from requirements to software seems still very natural to us, and it is stunning for many developers and managers that it actually oftentimes does not work. I would like to add here: sometimes it works very well, but I come to that point later. Now, what could be the replacement of requirements? (In case we agree that they do not work as intended in their traditional sense.)

Observation comes in...

Well, there are modifications of requirements engineering in agile processes like the storytelling in XP. But Martin Fowler makes an interesting other observation: Many successful web-applications actually work out the requirements as they go by providing some base-services, a platform (e.g. for exchanging photos). The very important point in this phase is to build in functionality that allows the management to observe the behaviour of the customers: which functions are they using, what are they annoyed about (forum discussions, email feedback...). Then they add experimental new features and test the acceptance (Or you can as well go the next step: let the customers develop the applications as Yahoo! Pipes shows it).

It's Alive!

The interesting point is, that this procedure was very elaborately described in the book "It's Alive: The Coming Convergence of Information, Biology and Business" written by Christopher Meyer and Stan Davis. A very recommended read. The do not describe so much the process of software engineering but rather strategies of modern enterprises and derive the core principles:
  • Seed: bring in a new feature, idea; probably only to a subset of customers, probably in variations for different customers
  • Select: select the successful variations
  • Amplify: eventually amplify the successful ideas and bring more of that sort
Meyer and Davis brought exampled from "old economy" but actually in software engineering (particularly in web-applications) we have a very good opportunity to rather easily "seed" new features, observe the behaviour and select and then amplify the good ideas. The key point here is, as also Fowler mentions, to focus more on the "observation framework" (in a technical-, but also in a management-sense!) than on trying to get all requirements right from the beginning.

... and back to the Waterfall

Having said that, I want to come back to a point I mentioned earlier: in the "agility euphoria" some evangelists forget to mention, that there is a broad variety of different software products and engineering efforts. (and I am not speaking of safety critical systems here): In many cases actually a "waterfall inspired" process works pretty well. This can be the case in such projects where a technical guy (a developer at best) has already a lot of experience in a particular domain and is either re-writing a legacy application (a case I am observing right now) or is developing a new application that is actually following a series of similar applications and similar customers he had. And this case is quite a regular one in the industry, and we should not forget this scenario. In such cases the requirements of the new application can often be nailed down quite precisely.

Why is that? Well, actually the "Seed, Select and Amplify" process happened in this technical expert. He or she worked with old applications in that domain, often with a broad range of customers that have experiences with several systems of a sort. So he has developed quite a good understanding of (1) the domain (2) the customer (3) the competitors. In such cases the problem often lies more to get the implementation phase right and not to spoil the project on the last steps e.g., with not so experienced developers (either in the technical sense, or in the domain, or in the worst case in both). Hence agile principles as suggested by Scrum for example can be very helpful for the implementation phase to keep control of the process even though the requirements are quite stable from the beginning.

4 comments:

Szabolcs Rozsnyai said...

This is a really interesting post Alex!

Requirements elicitation and requirements management is one of the major cornerstones for a successful software project. Most of the projects do not fail because of technical issues! In best case technical details should be avoided at the requirements elicitation stage (depends on the project type). For the details there is a design and specification phase. Especially at this stage you need good people who either have domain knowledge of that particular problem or they have the skills to work themselves in. However, they need excellent communication skills.

I think that an iterative and process based model is often one of the major success factors. Customers often don't really know what they want or haven't though through every detail of their problems. Therefore iteration cycles are required to reevaluate the current status of a project and also the requirements. Prototypes might be also helpful. It is also important to accept the fact that the IT is not driving the business – it is the way around. So systems should be built around business needs.

However the "Seed, Select and Amplify" or the "let’s put a beta version online” (like google is doing) is a good approach for certain projects. Especially for products or services that are aimed towards retail customers. Also it might fit for evaluation and evolutionary purposes. If you have a good idea for a new feature for an existing product that’s maybe a good way to test it (depends on the type of course!)

But bear in mind that that would not work for a nuclear power plant. I don't think it is a good idea to develop a plant control system and put it online as a beta version. You can't add the security features later on after you have seen it working live ;-)

Alexander Schatten said...

You are of course right; this is why I wrote the second part mentioning that we should not fall into an agility trap insofar as to believe agile or any other methodology works for all projects. I brought the example where a waterfall-like approach is still in 2008 working perfectly fine.

Safety critical dependable systems are definitly a type of projects that demand specific treatment.

However, I did not mention this in the first posting, but in "It's alive" the authors also make the point, that one should not be too paranoid with security issues (in software, credit card application and the like; of course not in areas where life is in danger): they also suggest here to go a more laissez fair approach, but put a focus on observation: if fraud is detected one can still react to the threat.

This might work for certain types of application.

Unknown said...

This speaks to the overall inadequacy of the Agile process for many web based, non-product oriented organizations. I have recently written my own blog speaking to this issue. I was recently in a development organization that was “market driven” the marketing business owners demanded a very detailed specification of a feature before implementation. They did not want to participate in any iterative “scrum” experience. They wanted to state their case and be confident that it was what was going to be implemented. From that point on it was the development teams job to get it done. Check out my blog on the subject.
http://kevinflood.blogspot.com/

Alexander Schatten said...

Yes, Kevin, I believe that you made this experience, however the underlying question is: does this speak against the agile process or against the customer?

I would say, of course, the latter.

I knew a company that did RUP crap documentation in bunches for the customer (a telko) but actually internally they did scrum because they said this is the only process that works for them.

But for the external customer they produced actually useless artifacts just to please them (they probably never read the crap but bunches of paper MUST mean that you worked a lot, no?).

So I believe that many customers fear agile processes because they simply do not understand that they are in much better control then; I would even go further: the "conservative" approach is actually simpler; you just have to pretend to control and do not really need to be involved and as we all know, people want to be cheated and comforted ;-)