During requirement gathering, an important aspect is to rightly classify it. Classification plays a vital role in the lifecycle of a requirement and how it gets addressed downstream. An accurate classification of requirements helps project stakeholders to use it adeptly and see it from various sides.
We recommend that you use the 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 subprocesses, 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 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
When collecting details and classifying, watch out for loops and ensure that ambiguity, if any, is validated with the right owner. Also, ensure that all potential scenarios/outcomes of the requirement are collected along with the exceptions.
Segmentation of requirements with the definition of an owner is important to assist in analyzing the requirements effectively.
Let's now explore typical areas of collecting requirements while implementing Microsoft Dynamics 365 for Finance and Operations, Enterprise edition (AX) and their representative sections, as follows:
|
Type |
Sub type |
Requirement area |
|
Generic/foundation |
Generic/foundation |
This includes collecting requirements about the companies involved, business verticals/industries involved, countries, sites, locations, solution instances, and so on |
|
Functional |
Finance and accounting |
This includes collecting requirements about general ledgers with a chart of accounts, financial reports, financial dimensions, posting rules, currencies, country-specific taxation and compliance, financial periods, month end, fiscal close, accounts payable, accounts receivable, invoicing and payments, fixed assets, bank, cash flow, electronic payments, budgeting, allocation, provisions, and so on |
|
Functional |
Supply chain and distribution |
This includes collecting requirements about products and their lifecycle, engineering change management, bill of material or formula management, stock keep units, sales order processing, purchase order processing, warehousing and transportation, returns, inventory management, inventory costing, customer service, Maintenance, Repair, and Operations (MRO), and so on |
|
Functional |
Manufacturing and planning |
This includes collecting requirements about production processing and control, scheduling, resources management, quality control and assurance, demand planning, forecasting, and so on |
|
Functional |
Projects |
This includes collecting requirements about contract management, professional services, project management, project types and their accounting, project budget, grants, and so on |
|
Functional |
Human resources |
This includes collecting requirements about talent/workforce management, leave management, skill management and training, payroll, and so on |
|
Functional |
Mobile workforce |
This includes collecting requirements about time sheet management, expense management, self-servicing, and so on. |
|
Non-functional |
Security |
This includes collecting requirements about business function and security roles, user interface-based security, data-dependent security, policy-based security, read only versus transactional security, and so on |
|
Non-functional |
Data migration |
This includes collecting requirements about configurations, master data, data volume, data validations, migration from other systems, open transactions, historical and closed transactions, and so on |
|
Non-functional |
Data warehousing and reporting |
This includes collecting requirements about single source of truth reporting across systems, day-to-day reporting, analytical reporting, dashboard, interactive information exploration, and so on |
|
Non-functional |
Integration |
Middle-ware and integration, Electronic Data Interchange (EDI), workflow, and so on |
|
Industry-specific business needs |
Specifics |
Industry-specific requirements |
The preceding table is just a representative sample of what to expect in requirement gathering. The scale, depth, and coverage varies from customer to customer and industry to industry, so you must ensure that all the requirements related to the contract/scope are well-captured and classified.
After collecting and segmenting the requirements across various areas, let's now analyze these requirements and capture the entire process in RTM, to be used throughout the initiative.