This may sound difficult, but there are some rules for good requirements.  According to the International Council on Systems Engineering (INCOSE http://www.incose.org/chicagoland/docs/Writing%20Effective%20Requirements.pdf), requirements should have the attributes below (similarly can be found at IEEE):

• Necessary –  driven by the objective of the project and business
• Verifiable – ability to objectively confirmed that the requirement is met
• Achievable – able to be met within the technical and cost constraints
• Concise – unambiguous and without conflicts with other requirements, a single non-convoluted requirement
• Unique – no redundant requirements
• Traceable – hierarchical traceable from top level requirements to the details including the business objectives and scope of the project. 

We will see words like “must, “will,” and “shall” to identify binding requirements these are contractual obligations. Since these are contractual obligations we must have confirmation or verification actions in place to objectively assess whether these are met or not.  Words like “may,” “might,” and “can” are less rigid and express a desire for certain design characteristics and are not binding.

Whether we are addressing functional, performance or environmental requirements these requirement characteristics apply.  Requirements documentation is yet another area we have witnessed as a failure point in a project.  One seemingly common failure is the inability to manage the changes to the requirements over the course of the development work. We have discussed this in earlier blogs around configuration and change management but discuss more in the future. Other requirements failures are:

• Missing requirements
• Do not trace back to project scope
• Poorly written and confusing

All of the requirements need not be developed at once.  We can take a play from the agile playbook and choose to prioritize the objectives of the project and deliver the requirements incrementally as we learn more about the product.  

Like anything the talent and commitment of the people doing the work matter. We can help by creating templates for our requirements capturing if there are common themes.  For example, an outline of the top level areas the requirements are to address such as:

• Environmental
  • Electrical stimuli
  • Vibration
  • Thermal
• Physical
  • Size
  • Materials
  • Interconnections
  • Geometric
• Functional
  • Normal operations
  • Fault operations
• Software Specific
  • Supportability
  • Maintainability
  • Extensibility

In the end poor requirements documentation leads to GIGO (Garbage In, Garbage Out) and wasted time and money.