Chaos report - Most project requirements are not requirements at all but rather merely vague objectives, unrealistic wishes and fuzzy hopes. by John Jan Popovic

Debugging Official Requirements
Problems in requirement analysis and specifications are extremely difficult. Defining precisely what is needed and what should be provided by software is more difficult than produce working software in hopes that it will be satisfactory in trials by users.

Even when the specifications are provided they are informal and with gaps and omissions of details. What are legal and valid inputs is often not formally clear, and what are valid production data outputs and procedures is often ambiguous.

Reliability certification if software is meeting its specification can pass, but it is not good for end users, because the specification does not meet their needs and is ambiguous, even if it was contractually approved by them.

ADVICES: Start small. Gradual delivery. Involve customers and end users in each stage of the project development. Do NOT expect grand finale delivery.
.............................
The CHAOS Report
.............................
The CHAOS Report that had been commissioned by the U.S. Department of Defence, which indicated that, for large companies, less than 9% of projects are completed on time and to budget and even for those that are, ‘many are no more than a mere shadow of their original specification requirements’.

The consequence of poor requirements quality is exemplified by the DOD Chaos Report and truly horrifying statistic published on behalf of the U.S. Department of Defence. Poorly produced specifications are estimated to have cost the US economy alone in the order of $90 billion to $120 billion per annum – with knock-on consequences in the trillions. It is a very safe assumption that other economies suffer proportional losses - and there are no markers indicating that this situation is getting better.

Requirements are like water. It is easier to create accurate and complete specifications when the requirements are frozen. The client needs a software solution which has well defined set of features and interfaces.

The requirements are what the software program should do, while the specifications are how you plan to achieve it.
The requirements are about WHAT the software program should do, while the specifications are more about HOW to do it.

The requirements represent the application from the perspective of the end-user, or the business as a whole.
The specification represents the application from the perspective of the technical team and developers. Specifications and requirements roughly communicate the same information, but to two completely different audiences.

The good thing is that estimates are mostly made by the actual developers who get to do the required features. The bad thing is that the specifications are usually either too simple (it turns out you're left with a lot of question marks over your head because a lot of information seems to be missing) or too complex(up to the point that you can't even visualize where everything would "fit" in the app). More often than not, the business part of the specs are either incomplete or unaware of what can and can't be done (given the previously implemented business logic).

Dev team is given about a day per new spec to give an estimate and we do try to clear uncertainties, usually by meeting up with whoever did the spec. Most of the times it turns out that spec writers haven't really thought everything through, and it's usually only when we start designing and developing that we end up in trouble, as a lot of the spec seems to have holes.
How do you deal with this? Are you generous on estimates in advance?

I went through the spec and wrote down everything that seemed illogical or that I didn't quite understand, even if it was the slightest detail. I sat down with the spec writer and went through all the details. We even broke down the development into phases, so I think it went rather well.


If you're finding problems during the design stage, do you really have a problem?
Make sure those creating the specs don't feel like they have to do everything up front. They can't think of everything and neither can we. They also need to know that they can't just do an all-nighter on some spec document and then be done with the project. This practice also leads to them adding every little thing they can possibly think of because they 'may' need it and if they don't ask now, they'll ever get it. They have to be available to review, test and approve their requirements over and over again.
Don't try to design or build the whole app at once. Any project/app can be broken down into some sort of phases, parts, modules or whatever they want to call it. You don't have to be agile if that's not your thing. Start with the User Security piece and go from there.
Make time to sit down with these people and find out what they really want. I would love to have someone hand me specs that allowed me to create the entire project all at once, but what would I do for the next year and a half?
A major reason estimates and requirements are often wrong is related to common misunderstanding of what scope is. Most project scope statements are not scope at all but rather merely objectives or even wishes or hopes.

---------------------------------------
Preventing contractual dispute
---------------------------------------
In order not to arrive to the situation where the client can claim that we did not deliver what he has asked, the deliverables after each milestone should be payed, re-controlled and inspected by the client or his representative. Do not make grand-finale payment contracts, it is too risky.

The client after each milestone should review the functionalities promised in the contract and cross-examine it against and sign a formal approval and provide a list of remarks or reclamations, which should be addressed in the next development cycle.

Failure reduction is an essential step towards excellence. And each defect, glitch or bug will be addressed in Test driven development.

-------------------------------------------
Why Have Official Requirements?
------------------------------------------
An explicit set of requirements is important for several reasons.
Explicit requirements help to ensure that the user rather than the programmer drives the system's functionality. If the requirements are explicit, the user can review them and agree to them. If they're not, the programmer, developer or designer usually ends up making requirements decisions during coding. Explicit requirements keep you from guessing what the user, i.e client wants.
Explicit requirements also help to avoid arguments. If you have a disagreement with another programmer, designer or customer, about what the web system, program or applications is supposed to do, you can resolve it by looking at the written requirements, specifications and design guidelines.