Working for a software development firm that builds enterprise applications, many of which are for the military, I’m not typically following what I would consider to be the ideal design process. Preferably, my customer would give me a problem statement or brief, and I would then work with them to understand the problem space, define goals, and write requirements. I have, on occasion, had the opportunity to do that, but more often than not, the customer already has a lengthy, very detailed requirements document and a request for proposals. We analyze the requirements and put together a bid.
Assuming we win the bid, we then have to design the solution. The best customers realize that their requirements may not be completely accurate, and we’ll have the opportunity to carry out some research and user studies. We work with the customer to refine the requirements, pruning those that don’t make sense and adding any that were missing. Customers that aren’t open to such a process typically find, once the product is delivered, that some of the features included in their requirements aren’t actually useful, and some functions that now seem obvious are missing.
The requirements are just a place to start. They provide a platform on which initial estimates of time and cost can be established, but they should not be carved in stone. Allow the design to remain fluid as long as possible, changing to match the learning that results from iterative prototyping and user feedback.