So far in the PMI-PBA® Certification article series, I introduced you to the Needs Assessment and Planning domains. In this week’s edition I will try to explain and provide details regarding the third business analysis domain – Elicitation and Analysis and this is the domain that implies some serious business analysis activity – elicitation, analysis, documentation, validation, verification, prioritization and approval.
First let’s explore the meaning of the term elicitation which means extraction, deriving. The idea behind using the term elicitation, rather than gathering is that if you use requirements gathering then you are assuming that requirements are already defined and waiting to be collected. In reality that almost never happens – requirements are not ready and waiting in the stakeholders’ minds or in documents within the business community waiting to be picked up, that’s why we need to elicit them. If we can express this metaphorically requirements gathering can be associated with rose picking, while elicitation can be expressed as archeology i.e. some serious digging and exploration.
Now that we know what elicitation is, let’s look at the different methods we have to “extract” our requirements. The PMI-PBA® Certification recognizes ten techniques for requirement elicitation depicted in the diagram below:
Regardless of the method you will choose don’t limit yourself to using just one. Try using a combination – for example facilitated workshop supported by prototyping and brainstorming and why not observation. And don’t forget and simplest yet best technique – ASKING. 🙂 The business analyst must be able to ask the stakeholders for the needed information in clear matter and not be afraid to challenge them.
As the information gathered during elicitation comes in different free formats and its volume grows quickly, the business analyst needs a way to structure its representation. Business analysis models such as diagrams, tables, or structured text are the tool that facilitates clear presentation and conveying of information.
In order to ensure the quality of the elicited requirements, the business analyst must perform validation and verification, activities that are often wrongly considered to be the same thing. Actually they are both correct methods, however each of them has specific meaning and application. Validation refers to ensuring the requirements meet the expectations of the stakeholders, while verifications ensures that the requirements meet quality standards and are error free. There is no specified order in which these checks must be performed, but in general it is best to validate requirements first with stakeholders and later verify only the “correct” requirements.
Very few software projects can deliver all the capabilities that all stakeholders want by the targeted initial delivery date. Since every project has some limitations (scope, budget, time), it is necessary to define the relative priorities of the requested product capabilities. Prioritization, helps reveal competing goals, resolve conflicts, plan for incremental deliveries, manage scope creep, and make the necessary decisions regarding what should be implemented and when it should be implemented. There are several techniques developed and followed by different business analysts to prioritize the requirements, some of them are discussed below:
- In or Out
- Three-level scale
- MoSCoW
- Weighted ranking
- Ranking
- 100 $
- Time-boxing
- Multivoting
- Prioritization matrix based on value, cost, and risk
The final step is the requirements approval, which may be formal or informal and its frequency and method may be predetermined in business analysis planning.
Once a set of requirements are approved, they are baselined and any change to them must be controlled, but I will reveal more details reading the change control process in next article from the PMI-PBA® Certification series, the Traceability and Monitoring domain. Besides how to organize the change control process, we will review the traceability matrix and how to effectively track requirements back to the original goal and objective of the project, identify and manage dependencies.
Find out more about:
- PMI Professional In Business Analysis (PMI-PBA)® Certification Preparation Training
- PMI-PBA Certification Exam Guidelines
PMI-PBA is a registered mark of the Project Management Institute, Inc.
