Requirements for Defining Requirements
What are your requirements for your requirements definition process? Are they clearly defined? If not, why not? Should your requirements definition process be any different from any other business process?
We 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 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 business and stakeholder requirements are the primary deliverable of the requirements definition 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 requirements, we found the following “requirements in the wild” floating around in our heads, bouncing off our skull and otherwise trying to drive us batty, so we captured them:
- Business requirements should be captured from the folks responsible for initiating and funding the project.
- Stakeholder requirements should be elicited from relevant subject matter experts (not from the technology folks – unless the project is about the technology business).
- Business analysts (or whoever is responsible for gathering these requirements) should use appropriate business analysis techniques to help the originators recognize what their requirements are (like, let us give them a fighting chance, O.K.?)
- Business and stakeholder 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).
- Business and stakeholder 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?)
- All business and stakeholder requirements should be confirmed with the technology experts before they are approved (to ensure technological feasibility).
- Confirmed business and stakeholder 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).
- Managed business and stakeholder 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 and stakeholder requirements, etc. Hint. Hint.)
- Modifiable business and stakeholder 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, I have tried to get the ball for defining requirements rolling for you here. It is up to you to decide which direction the ball goes. I 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.
