Before you start eliciting requirements, have a clear and agreed-upon definition of the project scope. This means identifying the problem the solution aims to address, the objectives the solution should deliver on, the constraints and assumptions that affect the solution, and the in-scope and out-of-scope features of the solution. Tools such as a project charter, scope statement, context diagram, or scope model can help document and communicate the scope to the stakeholders.
I would start with a "problem scope" before a "project scope". It really depends on when you are getting involved in the project process. If the problem or opportunity scope has not yet been analyzed, then the project scope is likely not done, or not done well. Requirements elicitation is just as much about understanding the problem scope, which is input to the product scope, which is input to the project scope. So first, figure out what scope is known and unknown in order to define the elicitation scope.
Defining the problem and its context is crucial. A pain point may be an entire business process or it may be part of a larger business process that includes multiple business units or teams. Frequently, it is the latter. If you change a process or a step therein, how will that honor or affect business rules? Who or what is going to be affected by the change? Change management should always take into consideration upstream and downstream users’ needs, including technical users like a data warehouse and the reports and analytics performed by data analysts or other users outside of the business unit that owns the problem.
Developing a detailed project plan is also a great way to avoid extending the project scope. Your project plan should include all the tasks that need to be done and when they should be done. A detailed project plan helps ensure that everyone involved knows what needs to be done and when.
Depending on the nature and complexity of the requirements, you may need to use different elicitation techniques to gather and validate them. Some common techniques include interviews, surveys, workshops, prototyping, and document analysis. Choose the techniques that best suit your purpose and stakeholders, and can help you elicit the right level of detail and quality. Also plan for each elicitation session, and document and follow up on the outcomes.
In choosing the appropriate elicitation techniques, it's important to remember some challenges, bottlenecks that are inherent to this task. Business analysts never lose their guards, and always prepare to deal with difficult situations at this stage. Ability to managing difficult difficult stakeholders has always led to huge success in requirement gatherings. In addition, every technique has their own downsides, e.g cost efficiency, time constraints etc and when these constraints are not factored in and well managed, they often lead to setback in achieving milestones.
As you elicit requirements, you may encounter changes in the scope, either due to new or revised stakeholder needs, or to changes in the environment. Have a change management process in place to assess, approve, and implement any changes that affect the scope, and to communicate them to the relevant stakeholders. Also manage stakeholder expectations to ensure they understand and agree on the scope of the solution, and the trade-offs and risks involved.
This can be accomplished through change management of requirements or in a more agile way of working through adaptive and continuous prioritization of small releasable increments.
A lot of young project managers will focus on the original scope and fight for it. From experience I have found it better to just be the conduit for the organization to document and facilitate discussions of priorities and scope. Different stakeholders will have competing priorities, which are valid and its really up to senior management to prioritize based on strategy and budget.
To keep track of the scope of your requirement elicitation process, trace and prioritize the requirements you elicit. Tracing means linking each requirement to its source, rationale, and related requirements, and to the objectives of the solution. This helps you verify the validity, relevance, and alignment of the requirements, and identify any gaps, overlaps, or inconsistencies. Prioritizing means assigning a level of urgency to each requirement based on criteria such as value, feasibility, risk, or stakeholder preference. This allows you to focus on the most critical requirements.
The most practical method I’ve found for tracing and prioritizing requirements is to begin with a project topology diagram identifying every way that money or data enters and leaves the project domain (ie business). Once inputs and outputs are identified, we map the internal processes in between. Viewing requirements through the lens of inputs and outputs supports a thorough analysis. Placing focus on the flow of money and data supports prioritization of the requirements. These techniques form a solid foundation from which it’s easier to delve into more nuanced requirements.
At this point it would be good to embark on the setting up of the Requirement traceability matrix (RTM) and ensure the discipline is being followed by tagging the requirements over the lifecycle where it will be put to good use in testing them. The risk of not meeting a requirement is also evidenced in this activity. Fine grained identification of user stories will also aid in providing appropriate technical stories that will aid in providing modular design & scoping of modular testing as well as proving valuable in component testing within a CI/CD environment. All these are possible if there is a good cross referencing of requirements being maintained. I have used Rational Requirements Composer (RRC) as a great tool in this situation.
Review and validate the requirements you elicit to ensure they meet the scope of the solution and are correct, consistent, testable, and traceable. Techniques such as inspection, walkthrough, analysis, and testing can help you review and validate the requirements. Also document the requirements in a suitable format, such as a requirement specification, user story, use case, or model, and obtain formal approval from stakeholders.
Keeping a focus on what success measurements are will be key to keeping scope aligned to the right things. Too many times scope is far too fixed and deadline focused, rather than managed to deliver results. In order to deliver results we need to focus scope on what requirements will move the needle most towards the business and user objectives/measurements.
In my experience, I always try to identify the scope of the existing problems my requirements are meant to address and define possible solutions to resolve them. This will redirect my efforts towards eliciting for requirements meant to provide solutions to existing challenges, or aimed at completing the projects at hand. Select, and validate them….