During requirement-gathering, an important aspect is to rightly classify them. Classification plays a vital role in the lifecycle of a requirement and how it's addressed downstream. Accurately classifying requirements helps project stakeholders use them adeptly and see them 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 the 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 that a given requirement 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 made by subprocesses, and all the requirements within the process should inherit from them.
- 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 the resources that 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 be 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 if you want to assist in analyzing the requirements effectively.
Now, let's explore the typical areas of collecting requirements while implementing Microsoft D365FO and their representative sections, as follows:
|
Type |
Subtype |
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 lifecycles, engineering change management, bill of material or formula management, stock-keeping 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 timesheet management, expense management, self-servicing, and so on. |
|
Non-functional |
Security |
This includes collecting requirements about the 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 |
Middleware 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 when requirement-gathering. The scale, depth, and coverage vary 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, we need to analyze these requirements and capture the entire process in RTM so that it can be used throughout the initiative.