We have several blog posts about software requirements.
Here is one on What vs. How – BRD vs. User Requirements vs. Functional Requirements
By Anthony Chen
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.
|
Lead Roles
|
Description
|
Documents/Information
|
|
Executive Stakeholder/Business Champion
|
Understands the organizational strategy and determines the general product concepts and features of programs in the portfolio that map to the strategy.
|
Project Portfolio
Corporate Strategy
Profit and Loss Commitments
|
|
Business Program Manager
|
Understands the day to day business operations concept (marketing, sales, legal, finance, HR, operations) and the business benefit of the product concept. Determines the specific business problems to be solved, determines the business benefit and redesigns the business processes to achieve the business value.
|
Product Concept
Business Case
Business Readiness
Business Process Redesign
|
|
IT Product Manager
|
Understands the business benefit. Understands the business processes and IT systems. Manages between what IT is capable of providing and what the business would like to be able to do. Determines what features will solve the business problems and how the system will work from a user point of view based on discussions with the business program manager.
|
BRD
SRS
|
|
IT Lead
|
Understands the technical solution and the systems architecture. Determines the best technical solution and how long it will take to implement the features based on a description provided by the product manager.
|
Functional specification
Technical specification
|
If you liked this post please check out our other posts on software requirements:
http://requirements.seilevel.com/blog/