Practical Approach To Elicit Requirements Successfully

Featured
Sep 16, 2018
4160 Views
0 Comments
9 Likes

Project statistics state that most project rework/failure is due to incomplete/improper/unclear requirements, hence the role the Business Analyst becomes even more critical as they shoulder a huge responsibility of eliciting and collaborating with the stakeholders to obtain clear, concise and complete requirements.

The elicitation and collaboration knowledge area focuses on drawing forth or receiving information from stakeholders and other sources by directly interacting with stakeholders, researching topics, experimenting or simply being handed information.


Does this sound familiar? I am sure most business analysts can relate to this situation. Yes, the biggest challenge in eliciting requirements is the requirements itself. This situation is real as many times the customer themselves are not sure of what they want or how the software can achieve what they want. The biggest challenge is to help the customer realize their business requirements from the software perspective.

Challenges can arise due to the customer or the analyst, if the requirements are not elicited efficiently the outcome results in challenges illustrated in the diagram:

       


There is no defined or prescribed way of performing requirement elicitation and a lot of information is available on how to elicit requirements and techniques used to elicit requirements, but this article brings to focus some of the key practical success elements to keep in mind while eliciting requirements irrespective of the techniques chosen to help overcome some of the above stated requirement elicitation challenges.

The elicitation process can be classified into the following stages:

  • Prepare
  • Engage
  • Elaborate
  • Verify

Prepare

Preparation is a critical stage before you engage your customers to elicit requirements as it defines your readiness as a person/organization to help customer resolve a business problem.

Success elements for prepare stage:

  • Read the SOW (Statement Of Work) carefully to get a high level picture of the Scope - like tools used, integrations required, migration from legacy systems, kind of support opted for...etc.
  • Make sure you are very clear of the business need so that you know all the customer pain points and the core objective of the project
  • Perform due diligence by reading up about the customer to know their focus, market position, competitors...etc.
  • Know the customer jargon – many a times we know that a business analyst cannot be an expert at all the domains, but still the business analyst should make sure they strike conversation in the customer domain context
  • In case you plan to provide a demo of your product / share a sandbox instance with your customer make sure the instance is setup with relevant industry content and appropriate role setup is done. This gives the customer a deeper understanding of what to expect and also always showcase business use cases that are relevant to the customer

Engage

Engage is the stage where you hear out what the customer needs and propose an appropriate solution that meets their needs.

Success elements for engage stage:
  • Have a clear idea of the amount and level of details required by the customer, give them a heads up on the topics you plan to discuss so that they can come prepared to share examples, sample data...etc.
  • Use techniques based on the project complexity, customer availability and customer comfort so that you have their buy in on everything right from the start
  • Questioning is key to eliciting requirements, keep your questions handy and make sure to ask relevant questions
  • Make sure you are clear about every requirement discussed, when in doubt clarify repeatedly instead of making any assumption
  • It’s not only important that you are clear about the requirements but also make sure the different stakeholder groups on  the project are clear and have a shared understanding of the requirement, when in doubt play the facilitator role to help different stakeholder groups resolve conflicts
  • All information/decisions at this stage should be communicated and documented clearly for any further reference, follow up your discussion with minutes of the meeting capturing important decisions and actions

Elaborate

Elaborate is the stage where every detail of the requirement is discussed and demonstrated to the customer through various artifacts such as FSD (Functional Specification Document), workflow diagrams, swim lanes, mock up, prototypes...etc.

Success elements for elaborate stage:

  • There should be a clear agreement on the level of detailing
  • All discussions should be documented in appropriate artifacts and only those artifacts should be used as a baseline for further reference
  • All scenarios and corner cases should be discussed and appropriate decisions should be made on how a particular set of stakeholders will interact with the system
  • Make sure view point of all the stakeholders that will interact with the system are considered, because leaving out any stakeholder group at the early stage can prove to be costly at a later point
  • Assumptions and constraints also need to be clearly called out and documented
  • Ensure consistent use of terms and definitions throughout all the documents. Also it is a good practice to include section such as glossary and appendix in the FSD (Functional Specification Document)
  • Be sure of what is customizable vs what is configurable in the system, clearly call out any customizations. Also if customization is not part of the project scope initiate that as a change requests and follow the change management process defined
  • Often overlooked but it is critical to capture the non-functional requirements, you can use standard templates asking specific questions which the customer can fill out if specific time to discuss is not dedicated. Also in larger IT focused organizations they have dedicated IT team which have certain set of service level agreements for an IT implementation. As a BA you can facilitate these discussion among cross functional teams (Tech Architects, Build and Release Teams, Platform Teams, Dev Ops Teams, Cloud Implementation Teams…etc. (This varies from organization to organization) within the organization.

Verify

Verify is the stage where review is performed, feedback is discussed and requirements are base lined.

Success elements for verify stage:

  • Incorporate enough time for this stage as this is often overlooked during project planning
  • Plan this activity well in advance and have the customer review and provide feedback, sometimes this is treated casually as the customer think that they have already spent a lot of time discussing, but make sure you enforce the review and feedback to be treated as a critical step to realizing the sign off milestone
  • Make sure that all stakeholders have reviewed the document for their requirements and shared feedback, so any missed requirements or conflict in requirement can be identified and addressed
  • Maintain a requirements issue log, to track all requirement issues identified and also capture the details regarding how it was resolved and what actions were taken
  • If customer BRD (Business Requirement Document) / HLR (High Level Requirements) document is provided make sure you create a requirement traceability matrix by mapping business requirements to functional requirements, this is a great way to uncover missed requirements and also helps in impact analysis in case of change in requirements
  • Once the review cycle is completed ensure the base lined documents are signed off by the customer as a formal agreement

Whatever be the success elements you follow as a business analyst make sure customer comes first and be driven with the passion of achieving customer satisfaction.

Attached is a sample case study where I have detailed certain scenarios to bring to light the challenges that occur during requirement elicitation and the solution we can use to overcome these challenges by following the success elements stated in the article.


Author: Roshini Nagpal, Seasoned IT Professional

Roshini Nagpal is a seasoned IT professional with over 9 years of experience working on various professional levels such as Lead Business Analyst, Senior Consultant and QA Manager.

She has extensive experience in requirement elicitation, gap analysis, workflow mapping, conceptualizing solutions, documentation, stakeholder management, prototyping, functional and user acceptance testing, training and end user support. She has worked on multiple projects from inception to implementation across different verticals. She is known for getting things done and delivering on commitments. She is passionate about business analysis and loves the diversity and challenges on each projects.

Would love to connect with fellow professionals, you can reach me on roshini.nagpal@gmail.com

Like this article:
  9 members liked this article
Featured
Sep 16, 2018
4160 Views
0 Comments
9 Likes

COMMENTS

Only registered users may post comments.




Latest Articles

Framing a New Piece of Work
Dec 16, 2018
0 Comments
Sometimes I find it difficult to explore new pieces of work in a structured way. When given a new challenge / piece of work it’s easy to jump st...

Featured Digital Library Resources 
Copyright 2006-2018 by Modern Analyst Media LLC