All too often we start shopping for software solutions before we know what we want or, worse yet, we create fully defined specifications (whether written or in our minds) before we start shopping. In either situation either our activities are not efficient and possibly ineffective at finding the best possible technology solution to a real business problem. There is a definite inflection point when you’ve gathered enough information about a problem that it’s time to start shopping, but it’s often difficult to nail down when you are in the midst of the project.
The recently released BABOK 2.0 (Business Analysis Body of Knowledge from the IIBA) defines the requirements-related deliverables created by a team selecting a software package as follows (whether you are looking for a software package, an enterprise tool, or hoping to leverage the cloud and find some service-based software, the set of activities will remain essentially the same):
- Request for Proposal (possibly)
- Business Requirements
- Technology Requirements
- Limited Functional Requirements
- Vendor Specifications (possibly)
So, as a business analyst on a team selecting software, what does this mean to you? This means that you need to understand the business problem you are trying to solve…not specifically what the system will do (i.e. functional requirements) but what the business wants to achieve through a system. Moreover, the technical requirements the software must meet should be deeply understood. Does your team want to be able to take the source code and run with it? If so, what coding language(s) must it be written in? How much hardware space is needed? What kind of database should it run on…etc. etc. (As a side note, one of the attractions of the SaaS model is the relative unimportance of technical requirements, provided your organization is prepared to give up control of the system.) As this relationship is with a third-party, you do not want to overlook how you want that relationship to work. Hence, the vendor specifications speak to what level of support the vendor provides, whether you just want a 24-7 number to call, an email address with a 4-hour response time, or you want a full-fledged services agreement where the vendor helps you with your implementation.
Given this, when do you get to start shopping? You’ll do yourselves a disservice if you start shopping too early, i.e. before you define your business problem. Readily apparent solutions have a way of redefining and refocusing your problems in counter-productive ways…problems that are easy to solve are compelling. Avoid missing the opportunity to define real problems because of readily apparent solutions. But on the flip side, do not go too deep into your solution before starting to shop around and see what’s available. Separate the shopping activity from the selection activity. Give yourselves the opportunity to learn about what’s available before your finalize your selection criteria. Allowing shopping and solving to be an iterative process means that the solutions you find filter up new problems or opportunities. Do not necessarily expect to have uncovered each and every business requirement before you start shopping. The act of shopping itself can help surface unstated needs.
On the flip side be very wary about how deep you dive. If you are not building a product, having a detailed specification of functionality will only make your search more difficult as you are likely to find many tools that solve your problem but don’t meet your functional requirements. The line between business requirements and functional requirements is a bit gray, but use it as a guide stick in your project. Are we talking about what the business needs to be successful or about a specific piece of functionality the system must have? If you can envision multiple functional compositions for solving the requirement, it’s probably a business requirement. If the requirement demands a specific feature with few alternatives, it might be too far into the realm of functionality to be useful.
Of course, every project is different, which is why there are no hard and fast rules. The best thing you can do is be self-aware of what you know and what you hope to discover with each action you take, whether it’s defining the business requirements, shopping for the solution, or evaluating a specific tool.
|
By Laura Brandenburg. Laura Brandenburg is an independent business analyst consultant. She is passionate about the BA profession and is committed to contributing by supporting this blog as a forum for business analysts to build on each other's experiences. View more blog posts by Laura Brandenburg |
Related posts:
Loading ...
{ 2 comments… read them below or add one }
“The line between business requirements and functional requirements is a bit gray, but use it as a guide stick in your project.”
————–
I have posted several articles about the difference between business use cases and system (or application) use cases. The same principals can be applied to any business vs system requirement types.
Think of business requirements as system independent. I like to think that a business requirement is written such that it can be implemented using nothing more than pencil and paper.
A system requirement describes a functional interaction with an application.
Another way to think of the difference is project vs product.
A business requirement is part of a project and may impact several applications. A system requirement is specific to an application and is derived from a business requirement on a project.
Leslie.
You can find information on my website; http://www.umllmu.com
Leave problematic/difficult stories vague as the programmers, or more often, the domain experts will often come up with a solution that is better than what was originally planned/conceived. This is the benefit of talking to them prior to or during a FEATURE BLITZ. (Programmers read about the latest and greatest and often can plug in something immediately and not have to re-invent the wheel.)