Over the years, we have heard a wide variety of terms that characterize a set of documented CRM requirements. Terms include: request for proposal, high-level requirements, blueprint, functional specification, specification plan, agile requirements and more.
Labels aside, there are several levels of depth of CRM requirements. As we’ve maintained in previous posts, the deeper your team goes into defining requirements before selecting a CRM system, the more successful your CRM implementation will be.
1. Feature Requirements
A list of required system features has a format similar to the following, a format that can often be found in requests for proposal (RFPs). Feature requirements do not describe any specific behaviors.
They merely indicate whether the CRM system has some yet-to-be-specified degree of functionality in an area. Here’s an example of feature requirements.
The CRM system must support the following:
• Outlook integration
• Google Apps integration
• Account management
• Opportunity Management
• Knowledge base
• Field service
• Email marketing integration
While creating a list of required features is a good starting point, it does not give CRM vendors enough information to tailor a demonstration to your company’s business requirements. In addition, it does not give service providers enough information to provide meaningful estimates.
2. Business Requirements
A high-level business requirements document is an analysis of current pain points and possible business solutions. It does not cover CRM product features per se. This document is usually derived from stakeholder and end-user interviews. The document can include problem/solution pairings and current state/desired future state pairings.
The business requirements document should ideally have an associated slide deck that can be used in a workshop for presentation and validation of findings.
While business requirements are generally documented by someone who is a business analyst, some CRM experience can be helpful for the interview process and for the assembling of interview information.
A general knowledge of what other companies have done to solve business issues and what’s realistic to expect from a CRM solution can help with the definition of business requirements.
3. Non-Functional Requirements
I have to admit that this requirements label is new to us. I discovered this label while reading Wikipedia’s definition of “functional requirements”. According to the Wikipedia article, “a non-functional requirement is a requirement that specifies criteria that can be used to judge the operation of a system, rather than specific behaviors.”
If we apply this label and definition to CRM, non-functional requirements can include criteria/requirement pairings such as:
• Availability: 99.9% uptime
• Scalability: Easily scalable to over 5,000 users and over 1,000,000 records
• Backups: We should be able to download full database backups on a daily basis
• Disaster Recovery: Redundant data centers with less than one hour failover time
• Cost: The system must cost no more than $X per month
There is value in separating non-functional requirements such as these from functional requirements.
4. Functional Requirements
The functional requirements document takes the amount of detail to the next level.
Generally, functional requirements are expressed in the form “system must allow for doing this specific thing”.
• Why the requirement is needed (what the current problem is)
• A description of the required behavior
• Details of a use case
• Business results of addressing the requirement
We’ve developed a CRM functional requirements example document to get you jump started.
5. System Design
Once again citing a Wikipedia article, “the plan for implementing functional requirements is detailed in the system design.”
System design is therefore the process of defining and developing systems to satisfy specified requirements of the stakeholders and system users.
Also known as a blueprint or a specification, system design gets down to the actual design of how the system should work. In the CRM world, this includes details like custom field names, data types and pick list values. It includes workflow rules and data migration maps. Spreadsheets and flowcharting tools become a part of the document set.
It’s possible to combine several of the above levels. For smaller organizations, functional requirements and system design can be part of the same document.