Hello all – BobtheBA here. Sometimes we can be inspired by the littlest things like a bee, a mosquito, or a play on words. Such was the case for me last month in all three examples, where the last of which I was inspired by one of my students who accidentally substituted “illiciting” for “eliciting” during a class exercise. We all knew what was meant and in class spelling does not count (which is the beauty of it happening during training – a safe environment!). However, in that moment I was immediately drawn to the concept of illicit requirements and what that might mean. Illicit is an adjective meaning “contrary to accepted morality or convention”. Is it possible to have requirements that do not fit accepted convention, i.e. “illicit” requirements? Absolutely!
So what would make a requirement illicit? Let’s explore this short list of illicit requirements.
1. Requirements that are not in scope. It is very important when conducting our elicitation that we guard against scope creep (BABOK® section 3.2.4). Tracing requirements back to the business goals and objectives will help us validate whether the requirement(s) should be included or not. If we are eliciting and documenting requirements that are not in scope they are by their very nature illicit. I have run into this very issue three times in the last month where BAs have been eliciting and documenting requirements that are out of scope. Requirements that were not generating new ideas for business or addressing current business needs. A considerable amount of resources, project hours and budget were inappropriately used.
2. Misunderstood requirements. It is very important that we have set criteria to ensure the quality of our requirements. Our requirements should be cohesive, consistent, complete, correct, feasible, modifiable, unambiguous and testable (BABOK® section 6.5.4). If the requirement has any ambiguity it fails. Ambiguity can lead to misunderstanding. Additionally, the requirement must be communicated (BABOK® section 4.5.1) to bring our stakeholders to a common understanding. If we communicate that ambiguity the implementation of the solution could be adversely affected because our requirements are misunderstood by our stakeholders (BABOK® section 4.4.2). This can lead to rework, increased costs, increase or decrease in resources and more. Misunderstood requirements are illicit requirements.
3. Requirements that jump to the solution. After we have elicited requirements we document the results which will include stated requirements and stakeholder concerns (BABOK® section 3.3). Stated requirements describe the stakeholder’s need from the stakeholder’s perspective. We must be wary of technical design in sheep’s (requirements) clothing. If we immediately jump to the solution we may ignore the stakeholder need or simply take away from their perspective which can lead to a design that will not cover the true need. Technical design(s) disguised as requirements are illicit.
4. Gathering requirements. Okay, while technically not an illicit requirement in itself, I find this to be one of the contributing factors to why requirements end up being illicit in the long run. The idea that we “gather” requirements is contrary to “elicit”. Elicit means to draw forth or bring out (something latent or potential) or to call forth or draw out (as information or a response). Gathering requirements as a term is more synonymous with simply taking in and documenting what is heard which I would call the job of a scribe. BAs are more than just scribes. Scribing what you hear without true elicitation and active engagement of your stakeholders in defining requirements (BABOK® section 3) which could be a root cause of illicit requirements!
Well I hope that you have the opportunity to discuss these things during some business analysis elicitation training in a safe environment but if not, be aware that illicit requirements do happen. Do you have other examples of illicit requirements? Do you think there is ever a time when illicit requirements actually work? I am all for breaking the rules, taking risks to innovate and in general push boundaries as long as we truly meet the needs of the business. What do you think? Yea or nay?