Getting Requirements Right: 5 Mistakes to Avoid
/There’s no one formula for getting requirements right. Projects are different and come with various challenges, opportunities and methodologies to contend with. Having an idea of what mistakes to avoid can improve the quality and accuracy of your requirements. This post is a continuation of 5-Step Plan to Eliciting Accurate Requirements, and it points out the missteps to avoid when eliciting requirements.
1. Avoid conflicts stemming from different weltanschauung (world views)
Make an attempt to understand stakeholders’ weltanschauung as well as yours. Weltanschuung refers to the worldview held by an individual which stems from deep-seated beliefs and fundamental assumptions drawn from culture, environment and personal experiences.
Imagine you’re someone who has worked in a bureaucratic setting for years. You’re used to seeking multiple approvals and sign-offs before committing to any major decision. A consultant now suggests that the multiple levels of approval for registering customers be reduced to one and implemented via the system once pre-defined criteria have been automatically validated by the system. You kick against this because you don’t believe that such scenarios should be completely automated; you believe that it is more effective for someone to check the data manually (e.g checking customer forms, vetting information from third-party sources, etc) before approval is granted. That’s your weltanschauung.
If the analyst were aware of your weltanschauung, they would be able to present an argument that addresses your concerns, challenge your assumptions and possibly convince you to change your mind. Taking the time to understand stakeholders’ weltanschauung can help in selling the much-needed change.
On the flip side, analysts tend to enter discussions with their own weltanschuung. Using the same scenario above, the analyst may be of the opinion that automatic checks and approvals are more efficient than manual checks and paper sign-offs. Such fundamental assumptions may prevent the analyst from seeing the other side of the coin. What if manual approvals with a paper trail make process participants more attentive and accountable for their actions? What if manual data checking tasks are only reserved for pool staff and the company would like to keep these staff busy because they come in handy during peak periods?
Identifying different world views does not imply that the analyst will be able to fulfill all stakeholder requirements but it ensures that recommended solutions are acceptable to everyone concerned.
2. Avoid blind assertions and recommendations
See the system through the eyes of the stakeholder. Go the extra mile to understand why users are requesting for certain features. Spend a day in their shoes by getting involved in how they do their work (observation) or through role plays. You've probably seen the TV Program, Undercover Boss, where an employer works with employees (unknown to the employees) to get an idea of the processes, the problems they’re facing and opportunities for improvement. Role-playing may also be achieved through the active observation technique.
It’s also good practice to engage in some form of problem analysis before proffering recommendations. This will prevent the analyst from recommending solutions that don’t solve the real problem or that cause new problems. Emphasis should be placed on treating the problem and not the symptoms (See 5 Whys Technique).
3. Avoid writing requirements without technical insight
Once requirements are elicited, they should be discussed with developers and other members of the technical team. Analysts often propose requirements that work in theory but not in real life. This is why early discussions with developers provides a reality check to proposed requirements and can help manage stakeholder expectations. Going over requirements with the development team/implementation SME will ensure that the requirements to be delivered are feasible before stakeholders sign off on them.
4. Avoid using only one technique
When eliciting requirements, it’s advisable to use more than one technique. Sticking to only one technique may limit stakeholder engagement and consequently, the amount of information gathered. For example, some stakeholders do not feel comfortable discussing their assumptions and concerns in a workshop setting. Using interviews as a complementary technique in such a scenario,would ensure that such stakeholders have the opportunity to open up to the analyst without self-censoring.
Also, the document analysis technique can provide the analyst with background information on the project before event-based elicitation sessions (workshops, focus groups, interviews, etc) are held. The analyst should collect as many facts as possible before using techniques that involve contact with stakeholders. The stakeholders’ time is valuable company time and they may not be able to provide as much time as needed by the analyst; they have day jobs which must continue, despite the need for their engagement in the project.
Another advantage of using complementary techniques is that conflicting requirements that are not obvious with one technique may surface when the analyst repeats the conversation using a different technique.
5. Avoid meeting stakeholders unprepared
Being prepared is an important aspect of requirements elicitation. It’s important to understand the business language, especially the terms and definitions used by business users. Where the analyst does not have much experience with the domain, doing some background research on the language of the domain can simplify discussions with stakeholders. The analyst should gather background information on the project and business terms to avoid starting on a blank page.
Do you know of any other "common" requirements mistake? Don't forget to leave your comments below.
