You do not have to go it alone when it comes to developing requirements. There are many templates and well-defined approaches to help in this regard.  If you are developing a complex system, it is good to break the requirements up, starting at the highest level of abstraction.  We will call that systems specification.  The Institute of Electrical and Electronic Engineers (IEEE) standard 1233, Guide for Developing Systems Requirements Specifications, provides a good starting point for the documentation structure from which we can adapt to our specific needs.  Many organizations work from internal templates which provide the structure of the topics that must be considered when developing the requirements.

 System Development and Requirements

For a sufficiently complex system, we may have a number of specifications involved.  We will choose to work from the greatest level of abstraction of the product, in other words, take a system’s orientation, to develop and define the attributes of the system required to meet the customer or project objective.  This may sound easy, but it is not.  There are likely many incarnations the system can take, and our job is to find the most probable to success.  This often requires some brainstorming solutions, and simulation and modeling to understand the performance possible with the various proposed systems incarnations. Ultimately we will select the concepts and approach that most probably will produce the results we seek and will begin documenting.

The systems level documentation is the tip of the iceberg. However, without a keen understanding at this level of abstraction of the product, we will be ill-prepared to articulate the details of the system.  So, once we know the scope and have developed our systems concept, we will then write detailed requirements specifications for the components of the system.

System Decomposition and Detailed Requirements

An example of specification hierarchy is provided below:

• Systems specification
  • component 1
    • embedded hardware specification
    • mechanical hardware specification
    • software requirements specification (IEEE 830-1998)
    • software design descriptions (IEEE 1016-1998)
    • functional specification
  • component 2
    • hardware specification
    • functional specification

Why is this important?

So why is any of this important to the project manager?  The requirements point to the customer needs and the objectives of the project. You can think of this as layers or the foundation of our project.  If we build this weakly, then the above layers will be at risk.  The level of rigor or validity of the approach to the requirements will have an impact on the end result. A project manager that knows the organization’s approach to the requirements is able to identify key metrics and take appropriate controlling actions thereby reducing the risk.  Even if the company has no real sanctioned approach, the astute project manager can work with the team to implement specific actions for that specific project that will reduce the risk.  This adaptation in the midst of missing structure or processes will improve the probability of project success.