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

Requirements - getting it right
Requirements are like water. It is easier 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.

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.

The first step toward developing accurate and complete specifications is to establish correct requirements. As easy as this sounds, establishing correct requirements is extremely difficult and is more of an art than a science.

Do you have the answers to these two CRUCIAL questions:
1. What assumptions and preconditions have not been yet fulfilled -- so we can NOT start to make any estimate of the volume of work and start planning development?

2. Have the end user/ client CONFIRMED the future solution mockup (interface layout, desired software walk-through, operating procedures document or prototype), before the coding has started!?

-------------------------------------------
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.

--------------------------------
simulation - the 5th artifact
--------------------------------
Historically there are four types of requirement artifacts in functional specification:
-1 the requirements in plan text
-2 the use cases, and business process with domain glossary
-3 the process-flow diagram
-4 the screen-shots with GUI elements and mockup content
-5 the simulation is actually new type of requirement, the 5th type of specification artifact, which has entered recently among the product specification artifacts. Only simulation can give the business customer (end user) real awareness that product specification correctly defines all his needs.

--------------
Road Map
--------------
During road-map planning it is important to balance “bottom-up” ideas which arrive from coders on the frontline with the “top-down” needs of marketing and management who have to make sure the product matches the marketing strategy and overall operativity.

It’s a bottom-up plan that is built and locked in a systematic way, where, everyone gets input on the roadmap plan, but once the plan is set, it’s FEATURE FREEZE

---------------------------------------
Preventing contractual dispute
---------------------------------------
In order not to arrive to the situation where the client or marketing department can claim that we did not deliver what was 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.