In order to identify our business and systems requirements, regardless of the technology segment, one must first understand the differences — and yes, there are differences. Typically, we think of business and systems requirements as technology. It is not our fault, as we have been conditioned this way. Much like the conditioned responses of Pavlov's dog to food, we have been conditioned to think in terms of technology when referencing business requirements and solutions.

How many times has someone asked of you, "How are you currently managing email?" and your response is, "We are planning to buy XYZ technology?" The question was not specifically about what technology you prefer, but the answer is. The fact is technology is merely a piece of the overall approach and solution. Policy, process and people are just as important and have just as much impact on what we should do in relation to our business issues. Thus, the need for us to distinguish and define our business requirements from systems requirements is essential to our approach in procuring and implementing the best possible solution.

Simply put, business requirements are the strategic goals and objectives, the legal and organizational framework by which we function, and the people and processes in place to make it all work. Systems requirements, then, are the features and functions that tools and technologies used by the business unit must provide in order to support the processes and activities of the business unit combined with the non-functional and domain aspects of our environment and solutions. Simple, right? Well, maybe. In order to be effective in developing business and systems requirements we must:

• Understand the strategic goals and tactical efforts of the business unit
• Develop criteria for a solution based upon those needs and goals
• Identify features or attributes that have a value for the business unit and user

This is extremely important if we are to ensure that our selection of technology is appropriate to the need, implementation is tuned to the audience and establishment of our environment yields the benefits we hope to attain. How is it possible to get the highest return and value for our time, effort and costs if we do not first know and understand the needs and requirements of our organization? This would be called a serendipitous approach, which seldom, if ever, works. We need to be calculating and focused in our efforts, and that is where business and systems requirements come into play.

Understand the strategic goals and tactical efforts of the business unit
If we believe that business and systems requirements capture and articulate the needs of a business unit and the stakeholders within that business unit, we must first try to understand the goals of the business unit and identify the tactical efforts on the part of the stakeholders in order to achieve those goals. While this might sound like a simple step, it is actually one of the most misunderstood and underestimated in the business and systems requirements process. This is true mainly due to the fact that not everyone will know or understand the goals and tasks.

Ask anyone in a business unit what the strategic goals or visions are for that business unit and you will likely get a variety of answers from, "I do not know" or "to make money," all the way to what might appear to be a real vision statement. When you ask how one performs his/her daily tasks to achieve these goals, there may also be a myriad of possible answers from the workers and a differing set from management. In fact, you may find there are actual documented processes for the worker to follow, but the question is do they actually follow those steps or have they been modified over time and the changes never documented. In this case, management might feel they know the processes and tasks performed when in reality what they refer to is "the book" and not the reality.

Too often, management and the workforce are not in sync with each other regarding strategic direction and tactical operations. In order for the connections to be made, we must first open the lines of communication throughout the organization and take time to share information and perceptions in a way that we can clarify, refine and agree upon our realities. As we go through this process, we must also capture and document our findings to establish the core vision and goals, identify a set of prioritized stakeholder needs to achieve those goals and do this is such a way that it aligns to the focus of the strategic objectives and is made clear and understood by the entire organization.

Develop criteria for a solution based upon those needs and goals
Assuming we are successful in the above mentioned effort of communication and documenting our realities, we must now develop criteria for a solution that meets those needs and empowers us to achieve our goals. Many think this is the point we spell out a vendor and product set. Wrong. This is where we spell out what our organization needs to perform. This is where we sort out and document criteria that will drive the purchase of our solution; real needs from stated needs. Here we prioritize the needs into categories like those things we feel are mandatory, those we feel are highly desirable and then desirable if we can get them.

We should consider looking at industry standards as part of this exercise and aligning those things in the industry standards to our needs and strategic goals (the latter being the most important). Standards that may come into play could be ISO 15480, MoReq2 and Dublin Core to help us formulate our corporate standards in dealing with information, records management and metadata. Criteria of this type could be presented in a matrix format as shown below for ease of presentment and understanding.

This approach allows us to simplify the criteria and segment them categorically in ways that are now easily understood and identified as not simply someone's dream or wish. When we approach criteria development in this way, the stakeholders can easily relate to what is being requested, it shows there is thought and effort on the compliance front when we choose industry accepted standards, and this becomes the foundation for our procurement process in vetting a solution and solution partner.

In addition, this method also helps us ensure alignment with our strategic goals by providing a means to review and tie back to what we are focused on accomplishing with this project. Along with this, we must also consider the solution itself and some of the functionality we feel is appropriate from a value perspective for our organization.

Identify features or attributes that have a value for the business unit and user We know the needs and goals of our organization, and we have developed baseline criteria as a result of applying standards, but we can also see a need to identify those features or attributes of a solution that would provide value to our organization. This is an area where we look at technology and assess what might make sense for us and why it makes sense. For example, if we want to automate the processing of our delivery services paperwork in order to streamline the process of invoicing and attain better cash flow, we might incorporate barcode recognition as a feature we desire. Perhaps, we are aware of others in our industry leveraging technology in this way, so we feel it's something we would also use and gain value.

This now gets back to our conversation in the previous section and the use of prioritizing those features we feel are mandatory, highly desirable and desirable. This too, can be presented in a matrix format and, when used in an RFP, provide feedback to us that can then be compared across the respondents. Here is an example of how this might look.

As you can see, this method identifies a feature and its importance or value to the organization while, at the same time, serving as a screen as part of the procurement process where respondents can indicate whether they can provide this feature and how it will be provided. In many cases I have seen, there is a description of the feature along with the priority for an organization and the response area for vendors and service providers to indicate yes or no. Where many fall short is in asking how this feature is actually provided. As a respondent, I could answer that "Yes, I can provide these features," but unless you ask the question of how, I will leave it at that, and you are left to learn specifics at a later point and possibly additional costs. This method also gives the respondent a chance to stand out as well as in presenting their full capabilities of delivering a quality, feature-rich product and professional services leveraging their experience and expertise that could help you in other ways for adding functionality or even interoperability throughout your organization.

The bottom line
The bottom line in all of this is that business and systems requirements are different, yet at the same time, tied together. One drives the other. Business and systems requirements are not something to take lightly nor are the effort to document them a task that should be trivialized. This is a project unto itself and one that involves a cross section of the business organization from management to worker and IT. This is a team sport.

We can and do create what we believe to be business and systems requirements, reacting much like Pavlov's dog when we hear the term and think technology. We must break our conditioning and think anew. We must look at our organizational worlds from many perspectives, understand and document those perspectives and attempt to bring focus toward a strategic end. Our goals should be aligned and our efforts tuned to meet those goals. Many businesses fail to realize the true benefit of their projects due to a lack of focus and understanding. This can be serious and is easily addressed through taking the time and effort in developing solid and realistic business and systems requirements that align to our strategic goals and address our tactical requirements.

BOB LARRIVEE [blarrivee@aiim.org] is the director of education at AIIM International, the world leader in providing education and training in ECM, ERM, BPM, IOA, EMM, E2.0 and PDF/A, and has over 25 years experience in content and process management with a focus on advanced technology application. Follow him on Twitter @BobLarrivee.