The Community Blog for Business Analysts

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. 

posted @ Friday, February 8, 2013 9:49 PM by David Wright

Previous Page | Next Page



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.

Modern Analyst Blog Latests

Three Audacious Goals for Business Analysts in 2013
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 traditi... Read More...

Hey IIBA, What’s Up With That?
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, th... Read More...

BA ABCs: “C” is for Class Diagram BA ABCs: “C” is for Class Diagram
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 Ac... Read More...

Featured Digital Library Resources 

brought to you by enabling practitioners & organizations to achieve their goals using:

Copyright 2006-2015 by Modern Analyst Media LLC