OSCAR stands for objectives (business & project), scope (deliverables of the project), constraints (budget, timescales & standards), authority (business owner of project) and resources (people & equipment available). This model can be used as a terms of reference, to keep requirements relevant to the objective of the project and business. Before we start any requirements elicitation, we need to first extract the OSCAR statement.
During the requirements elicitation phase, we will find two types of knowledge that we need to extract. There is explicit knowledge and tacit knowledge.
Explicit knowledge is stuff that we know and can articulate. These will be things like job descriptions; task definitions; targets; volumes; facts and figures and processes. These things are easy for the stakeholders to articulate to us as requirements.
We then have tacit knowledge. These are the bits that the user can’t articulate. Think of it like driving a go kart. When you jump in, you know to hit the accelerator, you instinctively know when you want to brake and you know how far to turn the wheel. But if someone were to ask you exactly how you did it, you probably wouldn’t know your exact braking point, the exact angle at which you turned the steering wheel and the point at which you accelerated out of the corner. This is an example of tacit knowledge. For this, we’ll want to use a protocol analysis to understand exactly what’s happening.
Tacit knowledge can be instinctive (as above) but it can also be things that the user omits because they consider them to be very obvious & things that they just don’t need to tell you. As a business analyst, you probably don’t know the area as well as them, so what’s obvious to them may need explaining to you.
We also have the issue where in some teams or business units there may be a unique culture or language of the users. To fully understand the culture and avoid confusion we should conduct an ethnographic study.
Finally, people often use their experience to make a judgement call & deviate from the standard processes. For this, we need to map out a decision tree to help understand their thought process.
Now we need to convert those tacit bits of knowledge into explicit knowledge. As above, this could be done via the use of decision trees but could also use prototyping or scenario analysis.
Once we have a view of the full requirements we need to start the requirements analysis phase. This is where we clarify the captured requirements, starting to build out a little more detail. We can categorise the requirements as belonging to a specific department or as a specific requirement type (functional or non-functional).
During this phase we also remove duplicated requirement and manage conflicting requirements. Throughout all of the requirements analysis phase, we need to assess whether the requirements are delivering against the business objective and ensure that they are feasible. Only clear, unambiguous requirements should be entered into the requirements list.
The final stage is requirements validation. This is where we ensure that all our stakeholders agree to the finalized requirements list.
Note: the requirements list should be very high level and should include description, source (who raised it) & comments. These can all be gathered from an initial workshop or discussion. We develop the detail over time.
All requirements should be:
- Consistent (does not contradict other requirements),
- Relevant (in project scope),
- Correct (actually required to meet project objective),
- Traceable (who raised it),
- SMART (Specific, Measurable, Achievable, Relevant & Time Framed).
Unrealistic and ambiguous requirements still need to be logged as part of your audit trail. If they’re considered to be out of project scope, they should be documented as such.
Once a requirements document is signed off, it’s subject to change control.
Content based on study of the BCS Business Analysis course – Business Analysis 3rd Edition (Debra Paul, James Cadle and Donald Yeates).