What does a software developer need to begin design?

Too many projects begin without even a hint of a written understanding about what is to be built. Unfortunately many of us have been there and lived through the pain of redesign and project slippage. At the other end of the spectrum some write suffocatingly detailed Requirements Documents. Masterpieces of literature that developers and managers don’t actually understand if they read it all! As in the case of no written requirements, the project usually ends up in the same predicament --- redesign, rework and missed opportunity.

In my experience developing embedded systems or software applications the big picture requirements must be spelled out. They should contain at a minimum the following: performance goals, safety factors, Human-Machine Interaction, testability, external interfaces, deployment, and target cost for hardware designs.

Defining the products requirements does not have to take a very long time. I find that in most cases this phase should take on average 2 - 4 weeks working collaboratively with the major stake holders.

The important point to keep in mind is that the requirements document must be be in a form that is easily understood by the technical team as well as non-technical management. Keep it as jargon free as possible. Define all terms.

INCLUDE PICTURES!

For example, an excellent way to define the user interface level independent of the actual technology used are pictures. It is more effective to draw a screen or touch panel then to try to describe it. Even more effective, use a rapid prototype application to create a demonstration of application. This is the most effective way to create a common vision between developer and manager of the look and feel of the resultant product. Be sure to include one or more block diagrams to illustrate the system and interfaces.

The next time you start a project please don’t settle for 10 bullets on a napkin!