We often times hear the saying that the requirements are the what and the design is the how. As I have written on this blog before this is not an adequate description of the differences between the types of requirements. The reason is captured in one of my favorite sayings “one level’s requirement is another level’s design.”  What I mean by this is that a stakeholder may have a requirement  to reduce the shopping cart abandonment rate of their site.  At the next level of detail someone may propose a few different methods for reducing the shopping cart abandonment rate. For example, they may want to reduce the number of steps in the checkout process, they may want to provide the capability to save the shopping cart to make purchases later or they may want to provide free shipping.  Each of these is a how to the what of “reduce the shopping cart abandonment rate.” If you then consider the next level of detail which explores the specific features of saving a cart for later or reducing the checkout process, you will certainly find more how’s which answer the what of the level above.  What really defines your levels is the people who are doing the defining, how you want to structure your organization and the specialties that your team has.

At the executive level stakeholders define the corporate strategy and define the means by which the IT organization will change the internal systems to support that strategy. For example, if the marketing organization has a push to improve the return on marketing spend by 25%, then the IT organization may need to create systems to support the capture and analysis of marketing spend dollars. The executives may understand, in a general sense, the features that are necessary to make this work and the general algorithms they want to use to determine marketing spend ROI. However they probably don’t understand all the possible types of programs and every detail for how to measure that return.

At the implementation level, the IT organization understands the technology (SAP or Java for example) that they will use to implement the systems but not necessarily the algorithms that the business needs to actually calculate the ROI of the various types of marketing programs.

Sandwiched in the middle are the people “in the business” who run the marketing programs and who understand their effectiveness. They will be using the systems on a daily basis but they could calculate the return of the marketing programs on paper if they had. The IT systems are just a bonus to improve their efficiency and accuracy.

The answer to the question of what vs. how, requirements vs. design or BRD vs SRS, hinges then on the roles in the organization and the types of requirements information that they specialize in producing.

Here is a simple model for the lead roles for the requirements portion of the effort. Keep in mind that you could have user interface designers, developers, project managers and other types of specialists.