Introduction
Clear. Concise. Comprehensive. Consistent. Adaptable. Reusable.
These are just a few of the attributes of well-written requirements. For service organizations like Edge, well-written libraries of requirements increase the speed, quality and volume of procurements essential to member success.
This article provides basic guidance for writing excellent requirements that support the successful
- planning
- procurement
- evaluation
- implementation and
- utilization
of technology solutions and services.
For the purpose of this article, we use the term "requirements" to mean to all questions, requests or detailed requirements presented to bidders, typically via an RFP (or RFI).
Three Basic Types of Requirements
In most procurements, there are three basic types of requirements:
- Information and Document Requests
- General Requirements
- Detailed Technical and/or Functional Requirements
Each type is explained below.
Information and Document Requests
A basic but important element in an RFP is to gather factual information from the bidders about themselves and their proposal. This information can be provided as answers entered by the bidders or as documents provided by the bidder (and, sometimes, both).
Examples of the type of information and documents typically requested include:
- Basic company information such as name, address, state of incorporation, years in business, annual revenue, et cetera
- Copies of organization charts, insurance certificates and financial statements
- Samples of master contracts, service level agreements, privacy and security policy documents, disaster recovery and business continuity plans, compliance documents, et cetera
- Cover letter, non-collusion affidavit, and pricing document(s)
Requests for such information should be straightforward, concise and polite, using a consist grammatical structure, such as:
- Please state the name and address of your firm, including main phone number, email address, and web site.
- Please provide a brief overview of your firm. Include in your overview the year your firm was founded, any relevant merger and/or acquisition events, state of incorporation, total annual revenue, and annual revenue from the higher education/K-12/local government/healthcare sector.
- Please attach the most recent two years of audited financial statements.
- Please attach current copies of your relevant master license/subscription/services agreement(s).
- Please download, complete, and attach our pricing worksheet. You may include explanatory notes where helpful.
General Requirements
General requirements are organized and presented with a focus on understanding the bidder's proposed solution, typically through the use of open-ended questions and solution-specific document requests.
Examples include:
- Present your understanding of the major objectives of this RFP and your approach to fulfilling the RFP requirements.
- Describe your customer service and quality control programs.
- Please describe how customers are involved in the product roadmap. Does the company have a customer steering committee, user group, or other means of gathering direct feedback on new and planned features?
- What percentage of your organization's revenue do you invest in Research and Development?
- Provide a detailed explanation of your plan to transfer knowledge to the Project Team and IT staff members during different phases of the implementation project.
- Provide a detailed plan for user training prior to system implementation.
- Provide a detailed plan describing post-implementation support model of each implemented module.
- Provide a listing of all assumptions used to create this response.
Detailed Requirements
Many procurements, such as for software applications and other technology solutions, will involve a well-organized listing of detailed functional and/or technical requirements.
Traditional Methods of Authoring Requirements
In general practice, there are many ways that organizations craft their detailed requirements. Examples include:
- Does your system allow users to review discount amounts based upon vendor terms?
- Can your system provide standard reports for recurring expenditures for consistency with budgeting?
- The solution should support check and other payment type reconciliation by producing outstanding checklist with ability to look up status.
- The system must provide automatic generation of general ledger transactions.
These are fine, of course, and bidders certainly know how to answer them, either with a narrative response or, better, with a prescribed codified response, such as "Yes", "No", "Partial", or similar.
Note the mix of requirements formed as questions and others formed as statements. Also note that requirements written this way are focused on the bidder's solution, even to the point of including additional words that create that context, e.g. "Can your system...".
A Better Way to Write Requirements
However, a more versatile approach to writing detailed requirements would be to revise the beginning of each requirement and restructure each requirement as a definitive statement, such as:
- Ability to review discount amounts based upon vendor terms.
- Provides standard reports for recurring expenditures for consistency with budgeting.
- Supports check and other payment type reconciliation by producing outstanding checklist with ability to look up status.
- Provides automatic generation of general ledger transactions.
Note that the requirements begin with a either a verb ("Provides", "Supports") or a noun phrase ("Ability to").
- Verbs are used to describe desired system capabilities or characteristics.
- The noun phrase "Ability to" is best used to describe desired functionality that an end user would employ.
Writing requirements in this way provides a number of important advantages.
Brevity and Flexibility
By eliminating the phrasing that establishes context ("Does your system"), the requirements become less wordy. Further, they can be used in a variety of settings where the context is defined by the nature of the activity, e.g. an RFP creates the context of focus on the bidder's solution while a requirements gathering activity creates the context of stakeholder needs and desires. More on this below.
Greater Precision in Response and Response Analysis
Detailed requirements that are written as definitive statements lend themselves to more advanced response formats and, therefore, more detailed response analysis. In any RFP, the greater the percentage of detailed requirements written in this manner, the more informative and impactful the response analysis can be.
Detailed Requirement Response Format
Versatility for Use Throughout Solution Lifecycle
In addition to supporting the RFP, detailed requirements that are written as definitive statements AND without the bidder's solution as the focus can be used in the:
- Early assessment stage to evaluate the scope and strength of a legacy system (an internal fit/gap analysis) as part of building the case for change
- Procurement planning stage to facilitate requirements gathering from project stakeholders
- Due diligence and evaluation phase of the procurement
- Post-implementation stage to validate the functional scope of the installed solution and end-user awareness of the newly available features and capabilities
An example of using requirement statements in requirements gathering is shown below.
Requirements Gathering from Stakeholders
For More Information
Dan Miller, AVP EdgeMarket and Solution Strategy, dan.miller@njedge.net, 480.258.9665