The Community Blog for Business Analysts

David Wright
David Wright

Follow-up to “So, you’re buying a package? Don’t forget your business requirements…” Don’t over-analyze!

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. 
 
This entry was published on Feb 08, 2013 / David Wright. Posted in Elicitation (BABOK KA), Requirements Analysis (BABOK KA) . Bookmark the Permalink or E-mail it to a friend.
Like this article:
  0 members liked this article

Related Articles

COMMENTS

Only registered users may post comments.


Blog Information

» What is the Community Blog and what are the Benefits of Contributing?

» Review our Blog Posting Guidelines.

» I am looking for the original Modern Analyst blog posts.



Copyright 2006-2019 by Modern Analyst Media LLC