The customer can seldom articulate the technical details of the product.  The customer may define the product or need in terms of function and performance, but building the product from these documents will be extremely difficult or perhaps impossible.  We will need some type of document to begin describing in technical terms the product that acts as a bridge from customer language to technical language.

One of the companies at which I have worked had a document that described the subsystem interactions.  This was called a cross-functional specification.  The cross-function refers to the interactions of the many electronic control units on the vehicle that were networked together.  The document described how the system would achieve the goals of the project, identifying specific signals, particular communications requirements and performance expectations from the numerous components on the vehicle network.  This essentially apportioned the function (distributing specific responsibility) across the numerous components of the network.  However, this homegrown document filled a very necessary role in the development of the systems on the vehicle.  Specifically, this description of how the system would achieve the expectations of the project was a mash-up of technical and non-technical content, with enough technical structure to allow those that owned the detailed specification work to be able to write requirements that supported this system.

We do not need to build this systems description through homegrown requirements.  One such structured approach is the IEEE STD1233, 1998, A Guide for Developing Systems Requirements Specifications.  This document can either serve as our template or help us generate our own specific approach based on our application.

Defining the system in both non-technical and technical ways facilitates effective reviews of the intended design by both technical and non-technical personnel, meaning, the engineers and the customers.  We can and should review this document with the customer but also with those that are to create the detailed specifications (essentially a walk through).  In the case of the automotive manufacturer, those responsible for the detailed development of the individual electronic control units should be there to understand how the system is to work and their particular role in the performance.

This systems requirements document is the very headwaters of our decomposition of the requirements, all of which start from the objective and the scope statement for the project.  A systems requirement document can effectively synchronize the understanding and coordinate the work that follows.