Whether your firm develops garden tools or childrens’s toys or software, each product or project was undertaken for a purpose.

No one can design anything unless there are requirements that form the basis for the design. If you have good, well-analyzed requirements, you can push your project out the door to your customers on time and on-budget.

Requirements are the foundation for your design. It is so obvious to acknowledge this, that it’s almost trite to say it aloud. Yet, many projects fail because the underlying requirements were not adequately identified and analyzed. Requirements analysis seeks to solve the puzzle involving a system; its sub-systems, and the interrelationships between them.

Business Analysis v. Systems Analysis

This is fairly clear: business analysts are concerned with business needs and the solutions to business issues in an enterprise. Certainly products—hardware or software—affect the business of an enterprise. So, business requirements play a role in analyzing the system requirements of any project.

Systems analysis, on the other hand, is applied to the processes, procedures, and methods that a system does use, or will use, to accomplish a goal. The methods used by a system analyst are similar to those used by the business analyst. However, the data each uses are often much different and, in some cases, conflict.

For example, a new machine may be designed and built to better, more efficiently grade a road surface. The business goal for that machine will be to produce it at the least cost while earning the most income from sales. Business requirements, however, do not drive the analysis used to identify the system requirements of the product.

The Goal of Requirements Analysis

With software projects, we look at each requirement and ask: “Can Johnny (or Sally) code this?” Requirements analysis does not produce the detailed design specifications needed to actually write code, but…the analysis must identify code-able elements and show how those elements fit together to form the system.

Let’s use the human arm as an analogy. If our goal is to design a human appendage to do what we can use an arm to do, our requirements analysis must identify:

• What the appendage should do
• With what tolerances or parameters the appendage should comply—maximum/minimum weight lifted, maximum/minimum range of motion, etc.
• What subsystems are needed to accomplish the operational goals of the appendage (structural elements, communication system, heating, cooling, energy, lubrication, etc.)
• Systems or subsystems exterior to the appendage with which the appendage must be integrated
• Configurations for the appendage

The specific design elements fallow from each identified requirement. Imagine the production problems that will result if designers have no requirements upon which they can base a design! For instance, the requirements for an “arm” will likely identify the need for another subsystem: a “hand.”