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:
  2 members liked this article

Related Articles

COMMENTS

Only registered users may post comments.

Modern Analyst Blog Latests

As we start a new year many of us will take the time to reflect on our accomplishments from 2012 and plan our goals for 2013. We can set small or large goals. goals that will be accomplished quickly or could take several years. For 2013, I think Business Analysts should look to go beyond our traditional boundaries and set audacious goals. Merriam-...
Recently, I was asked by the IIBA to present a talk at one of their chapter meetings. I am reprinting here my response to that invitation in the hope that it will begin a conversation with fellow EEPs and BAs about an area of great concern to the profession. Hi xx …. Regarding the IIBA talk, there is another issue that I am considering. It's p...
Continuing the ABC series for Business Analysts, Howard Podeswa created the next installment titled "BA ABCs: “C” is for Class Diagram" as an article rather than a blog post. You can find the article here: BA ABCs: “C” is for Class Diagram Here are the previous two posts: BA ABCs: “A” is for Activity Diagram BA ABCs: “B” is for BPMN

 



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-2024 by Modern Analyst Media LLC