5 Problems in Requirements Eliciation (1- Lack of Collaboration &…
5 Problems in Requirements Eliciation
1- Lack of Collaboration & Review of Requirements
Companies often follow the "Gather" and "Collect" requirements from stakeholders mindset instead of using proven successful elicitation techniques. This leads the team to jump to a conclusion too fast before understanding the business needs and value required by stakeholders.
Also, BAs are often only brought in the project once business needs and requirements have already been discussed. It's then BA's job to investigate the established req with stakeholders, making the same understand that this will improve project result
To avoid this situation, people who are using or signing of requirements, need to be engaged from the start making sure that all requirements are understandable, cohesive and usable. To achieve this, BAs need to ensure that all documents are presented in ways that all audiences can understand and the review engages all audiences. This is where the Visual Thinking competency comes in really handy and the better the BA can use graphic to explain concepts, the more engaged the audience will be.
5- Allocating requirements too early to the apps they will be implemented in
Very often companies decide what application/feature will be developed to deliver a certain requirement even before the requirement itself has been well investigated and vetted.
Assigning a technology to a requirement before assigning a BA defeats the purpose of BA
. It also limits the creativity on solving the same problem as it delimits the options.
Every requirement needs to be properly discussed, investigated and validated before a solution is designed to implement it. This allows the discover of the true business need and to explore different solution alternatives. it also ensures feasibility.
Great practices are focused on the USER, PROCESS, RULES, EVENTS and DATA.
2- NOT differentiating between CAPABILITIES, RULES, PJ TASKS and DESIGN
Very often requirements docs become a list of projects tasks and solution design when it should outline only the solution REQUIREMENTS and provide a broad context and capabilities needed for each requirement.
PJ tasks are to be resided in a different document and design is to be treated as whole different thing from requirements
Also requirements are to enable business rules to be followed, rules ARE NOT requirements
Requirements documentation have as it's priority to provide the solution and business requirements where each contain a broad context and be ambiguity-free. Projects tasks and design will then be based on these requirements and not the other way around.
4- Too much focus on the AS-IS current state
In some Projects too much time is spent on explaining the current state of things and where the gaps are. The Problem with this is that The future state of the gaps and flaws of the current system is NOT presented properly leaving stakeholder uncertain of what issues exactly that solution is solving.
While explaining the current state is important to understand what gaps needs to be crossed. the BA needs to ensure that the future state and crossed gaps are well documented, presented and understood by all audiences.
Projects are created to change how the company works, therefore this change needs to be well presented and understood
3- Lack of Context and Visuals
Cognitively, visuals are proven to be more effective for Human beings to learn/understand a concept than text. Unfortunately not always requirements document have enough visuals to help stakeholders understand the requirements, or when it does, very often they are too complex because the BA created them focusing on the design instead of focusing on the req explanation.
Great requirements are documented in a way that allow users to access multiple levels of details and each level will be consisted of
visuals AND text
which prevents the visuals of becoming ambiguous and gives context to the requirement.