Antes de começar a eliciar requisitos, tenha uma definição clara e acordada do escopo do projeto. Isso significa identificar o problema que a solução visa abordar, os objetivos que a solução deve entregar, as restrições e suposições que afetam a solução e os recursos dentro e fora do escopo da solução. Ferramentas como uma carta de projeto, declaração de escopo, diagrama de contexto ou modelo de escopo podem ajudar a documentar e comunicar o escopo às partes interessadas.
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.
Dependendo da natureza e complexidade dos requisitos, talvez seja necessário usar diferentes técnicas de elicitação para reuni-los e validá-los. Algumas técnicas comuns incluem entrevistas, pesquisas, workshops, prototipagem e análise de documentos. Escolha as técnicas que melhor se adaptam ao seu propósito e às partes interessadas, e pode ajudá-lo a obter o nível certo de detalhes e qualidade. Planeje também cada sessão de elicitação e documente e acompanhe os resultados.
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.
À medida que você solicita requisitos, você pode encontrar alterações no escopo, devido a necessidades novas ou revisadas das partes interessadas ou a alterações no ambiente. Ter um processo de gerenciamento de mudanças em vigor para avaliar, aprovar e implementar quaisquer alterações que afetem o escopo e comunicá-las às partes interessadas relevantes. Também gerencie as expectativas das partes interessadas para garantir que elas entendam e concordem com o escopo da solução e os trade-offs e riscos envolvidos.
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.
Para acompanhar o escopo do seu processo de elicitação de requisitos, rastreie e priorize os requisitos que você elicitou. Rastrear significa vincular cada requisito à sua origem, lógica e requisitos relacionados, e aos objetivos da solução. Isso ajuda a verificar a validade, a relevância e o alinhamento dos requisitos e a identificar quaisquer lacunas, sobreposições ou inconsistências. Priorizar significa atribuir um nível de urgência a cada requisito com base em critérios como valor, viabilidade, risco ou preferência das partes interessadas. Isso permite que você se concentre nos requisitos mais críticos.
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.
Revise e valide os requisitos solicitados para garantir que eles atendam ao escopo da solução e sejam corretos, consistentes, testáveis, rastreáveis. Técnicas como inspeção, passo a passo, análise e teste podem ajudá-lo a revisar e validar os requisitos. Também documente os requisitos em um formato adequado, como uma especificação de requisito, história do usuário, caso de uso ou modelo, e obtenha aprovação formal das partes interessadas.
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….