Using Requirements Traceability Matrix (RTM) fr your Microsoft Dynamics 365 Finance and Operations one version D365FO implementation

Using Requirements Traceability Matrix (RTM) fr your Microsoft Dynamics 365 Finance and Operations one version D365FO implementation

As there are many business processes involved containing several scenarios and potentially many requirements per scenario. Also, there exists some relationship/connection among the requirements. In order to closely manage these many-to-many requirements relationships, formulating the comprehensive network of requirements for a process is a must for project success.

One easy way of remembering could be this definition: RTM is a single repository/document that collects all the requirements, their relationship with other requirements, their role in business processes, all pertinent information related to solution, development, and Go Live.

It is one live matrix that should be kept up to date throughout the life cycle of project and is often used by the project manager to re-baseline the project plan as needed.

Solution acceptance becomes easier when an RTM is used. Also, stakeholders can validate and confirm whether each identified requirement meets the solution being delivered, leveraging the RTM and solution artifacts.

Use following techniques for classifying requirements and tailor-fit them based on the size, complexity, and business situation of your Dynamics 365 project:

• Ask the question WHAT:
  • What kind of requirement is this? For example, functional process oriented, non-functional security, decision making, and so on.
  • Impact on business (must-have or good to have).
• Ask the question WHY:
  • This classification is oriented to weigh the importance of a requirement
  • Recommended usage values: must-have, good to have.
• Ask the question WHEN:
  • This classification is oriented to know when the requirement is needed so that it can be taken for solution and deployment planning in the CRP.
• Ask the question WHERE:
  • This classification is oriented to gather and learn all the dependencies a requirement in focus has over other requirements.
• Ask the question WHO:
  • This classification is oriented to always ensure that there is an owner of the requirement
  • Usually, ownership is by sub-processes, and all the requirements within the process should inherit it
  • There should be at least four owner types for every requirement, as follows:
  • Business owner/SME
  • Project core team owner from customer
  • Project core team owner from advisor/partner
  • Technical owner
• Ask the question WHICH:
  • This classification is oriented to gather all resources which are needed for a requirement.
• Ask the question HOW:
  • This classification is solution-oriented, and if a solution that was already committed or agreed upon is available, then it should get captured as well.