For those of you who do define requirements for their software development projects, but are new to buying packages, a cautionary warning; they are not the same thing. Consider the following “the system shall” requirement statements.
1) The system shall determine if a person ordering pizza is a current customer.
2) The system shall determine if a person ordering pizza is a current customer, only if the person is phoning to place an order.
3) The system shall determine if a person ordering pizza by phone is a current customer using the person’s name and phone number.
Each requirement is at a certain level, increasing in detail from (1) to (2), and from (2) to (3).
- Requirement (1) is at high-level, stating that the system shall do something with certain information.
- Requirement (2) is more detailed, stating that the system shall do something with certain information, in a certain situation.
- Requirement (3) is fully detailed, stating that the system shall do something with certain information, in a certain situation, according to certain rules.
Requirement (3) is what you need to provide to designers/developers to use in new software development. However, this not what you need to provide to vendors when you send them an RFP; in fact, this level of detail can be over-kill analysis and can restrict the number of vendors who could meet your needs. By being very specific about rules and restrictions, you may eliminate a vendor who has a different and possibly better approach to meeting the business need, e.g. a better way to determine who is a current customer.
So what level of detail do you need? High level requirements like (1) can be useful at the start of a project, to describe scope and support planning; this level can also be used in a Request for Information (RFI) sent to vendors, just to get an initial view of what the marketplace looks like.
When you get to an RFP, you need more detail to differentiate vendors better, and Requirement (2) is an example of this level, which I call mid-level or standard-level of detail for requirements. At this level, you can see the difference between vendors in meeting your requirements, enough to evaluate their product and decide which one will serve you best.
So I now have two recommendations for organizations looking to buy a package:
- Don’t forget your business requirements…
- … but don’t over-analyze your needs, so you can best evaluate those packages.