Comments on: How to Design Software With Bad Requirements

By: Sona

Sona — Thu, 08 Jan 2009 10:06:45 +0000

Hi,
I have been part of a software engineering project once but in my internship, I have been given the complete responsibility of coming up with a software. I tried to draw some use-cases but they are too general. Can someone tell me exactly what all goes through your mind when you are making your use cases?
What all information makes you feel prepared to start making them?

By: dheerendra kapariya

dheerendra kapariya — Tue, 30 Dec 2008 10:04:47 +0000

i want disine software

By: Adrian

Adrian — Sun, 24 Jun 2007 06:41:15 +0000

Hi Scott! This is a great blog entry! I work extensively with business analysts and systems analysts and I find that too often they do not question a bad requirement when they see one. Questioning suspect requirements is a must. Your tips to developers also apply business systems analysts. I added a link on my blog. - Adrian

By: derick

derick — Mon, 18 Jun 2007 09:43:15 +0000

Scott, this is an extremely interesting topic. Not only for small, but also huge organisations. I believe we all sit with the situations where the requirements that we get from our customers are very vaque. It is then the responsibility of the architects, business analysts, designers and developers (sometimes the same person in smaller organisations) to make something happen from this. I love your idea of isolating solutions, but it becomes very complex when you work in an integrated environment where “stand-alones” doesn’t really exist. Maybe we can also considers some other alternatives like:
a. Breaking the unclear requirements into small bits (chunks). These chunks must make some sense or form an independant unit. Then each of these chunks must be designed seperately and prototyped and .. We must keep in mind that all the chunks together must contribute towards the orginal unclear requirements.
b. The reason for unclear requirements is sometimes a way to get alternatives. It implies that the customers wants to explore alternatives without saying it clearly, or the customers does not really knows what he/she wants, but they know they muts do something. In these cases it is essential that only this is addressed and that alternatives are provided without fully functional sofware. You will end up rework in any event.
c. Using archirectural tools to map your designs. This proves to be a very effective way to change and to indicate change.
d. Get agreement on the areas of the requirements that are no so unclear and complete that design and development. Then move on to the unclear bits by making lots of assumptions.
Any more ideas?

By: Scott H

Scott H — Fri, 15 Jun 2007 13:19:46 +0000

Thanks for the comments!

I completely agree, these are steps that should always be followed. However, in my experience, it’s rare that use case + design + prototype work happens up front, or even at all. I think it happens even less when a developer or team thinks a requirement is a poor one. Hopefully the article shows how to use those design tasks to your benefit when those types of requirements are set.

By: Sammy Larbi

Sammy Larbi — Thu, 14 Jun 2007 23:42:47 +0000

Hi Scott, I like this advice. But, don’t you think most of it can (and is) how we should work on projects anyway?

You might not do detailed use case analysis, but certainly you’d walk through how features should work. You’d often build some sort of prototype to see you got the requirement right, and quarantine sounds like the result of keeping coupling low and cohesion high.

In any case, I think it is sound advice not just for silly requirements (or what we think are silly requirements), but also apply fairly well to the general case as well.

By: Nevil

Nevil — Thu, 14 Jun 2007 16:16:30 +0000

Good read – linked.

By: Scott H

Scott H — Wed, 13 Jun 2007 22:13:55 +0000

@ Shenpen: Point well taken. My example was just that, an example. Personally, I think that flat file polling is a crude method of inter-process communication. However, this article wasn’t written to call one thing crude and another thing elegant. There are lots of areas where “bad” (and again, that’s my own opinion) requirements can be set. For instance, I worked on one project where the client preferred a console interface over a windowed interface because “that’s what their employees were used to.” And I saw his point, it would take a lot of time to train the employees to use the new interface, and they probably wouldn’t be happy using it. So it was a bad requirement in my mind, but a justifiable one. So we wrote the application so that someday it could be plugged into a windowed front end. That’s what this article is about… not what’s good and what’s bad, but what to do when you sense a requirement with a high probability of change.

Thanks for the comments, I love talking about this stuff!

By: Shadowfiend

Shadowfiend — Wed, 13 Jun 2007 21:52:26 +0000

I’d guess the cringeworthiness of that is that the orders are better off being pushed to your application somehow (have the application act as a server, have the application integrate into the other as a library, whatever), rather than being dumped and relying on polling.

By: Shenpen

Shenpen — Wed, 13 Jun 2007 21:15:13 +0000

I wonder what world are you living in…

I’ve just written an application within the latest release of the Navision ERP system that monitors a directory and imports flat files, which weren’t created by some sort of legacy terminal app but a brand-new web-based product configurator written in .NET…

Why should it make me cringe? An XML format would make the parsing code 5 times longer and more complicated than a simple TAB-separated file, and reading the files from a directory is a lot more simple than reading a web service… this took no more than a day, where the actual interface took no more than an hour, while an XML-based web service interface would have meant extra hours, maybe even extra days meaning extra $1000’s of consulting because our rate is around $1500 a day. And all this for nothing. I don’t think being a good developer means falling in to every trend like SOA… these ideas like SOA do have their uses, especially in large organizations and large distributed systems with loads and loads of data, but when we it’s a small client, like, 200 records in 10 files a day, how would you rationalize the extra cost? Don’t be so quick in labelling it as bad.