What Are Your Requirements?

Requirements for Business Requirements

What are your business requirements for your business requirements gathering process? Are they clearly defined? If not, why not? Should your business requirements gathering process be any different than any other business process?

We at RSG don’t think so, so we thought we would give you a starting point (to get you started thinking about them just in case you haven’t clearly defined your business requirements for the deliverables of this critical business process yet. In case you have, we will give you something to compare your requirements against.). Since the business requirements are the primary deliverable of the business requirements gathering process, we focused our attention – and our requirements – on them. We do, however, insist on the obvious disclaimer that these requirements are incomplete and may have to be modified to fit your individual situation

Our Captured Requirements

Based on our baseline philosophy on business requirements, we found the following "business requirements in the wild" floating around in our heads, bouncing off our skull and otherwise trying to drive us batty, so we captured them:

1. Business requirements should be captured from the subject matter experts (not from the technology folks – unless the project is about the technology business).
2. Business analysts (or whoever is responsible for gathering the business requirements) should use appropriate techniques to help the subject matter experts recognize what their business requirements are (like, let us give them a fighting chance, O.K.?)
3. Business requirements should be clearly defined before the technological solution is developed or purchased (a novel idea, we have learned, but we are going to stick to our guns on this one).
4. Business requirements should be objectively measurable to enable someone besides the author to validate that they have been met once the solution is delivered (is “End-User Acceptance Testing” an accepted concept?)
5. All business requirements should be confirmed with the technology experts before they are approved (to ensure technological feasibility).
6. Confirmed business requirements should be prioritized before the scheduled delivery date to ensure that the prioritization is based on the business need (as opposed to the technology department’s resource crunch).
7. Managed business requirements should be modified based on changing business needs using an appropriate change management process (which should be managed as a business process itself – i.e., it also needs business requirements, etc. Hint. Hint.)
8. Modifiable business requirements should be traceable to all of the components of the solution (from design to code to test cases to etc.) that they impact to enable an effective impact analysis (which could imply a requirements management tool, yet another project that needs requirements. Reminds me of the song from the ‘60s, “Where Have all the Flowers Gone?”. Remember the refrain, “when will they ever learn?’)

You Can Take It From Here

Well, we have tried to get the ball rolling for you here. It is up to you to decide which direction the ball goes. We do have one word of caution for all of you business analysts and managers of the requirements gathering process out there: if the ball starts to gain momentum, make sure you aren’t standing in the way. You might get rolled over and that sucker can be pretty heavy.

The Virtual Workshops They Are a’Changin’

Based on the experience gained from the many virtual workshops that we have conducted in the past year, we have decided to update our virtual workshop offers. One of the primary changes has to do with the length of each offer. We have found that most people prefer to use this technology to learn a very focused set of skills in the shortest reasonable time frame and they prefer to have the most freedom for scheduling. As a result, we are separating our curriculum into virtual workshops that are only 1 or 2 ninety-minute sessions long to give you the opportunity to complete a workshop in a single day. This way, you can better choose topics that interest you without having to commit to a 3 or 4 day program that might be difficult for you to schedule.

In addition, we are also planning on offering some of the workshops on weekends for the busy but industrious business analysts who need our courses but can not find time to attend them during the normal work week. You will see some of these changes showing up in our next course schedule update. We hope that these changes make it possible for many more of you to enjoy the benefits of just-in-time training tailored to meet your specific needs and we look forward to working with you — either virtually or live — in the future.

Tom Hathaway and Dan Myers
Managing Partners

Future Feature: "How Process Models Clarify Requirements"