Section 2: Business Requirements and Data Analysis. Lesson 8.
Requirement gathering is the process of collecting, analysing and documenting the expectations, needs, constraints and objectives of everyone affected by a data migration. Because migration touches both technical systems and business operations, requirements must come from a wide range of stakeholders, not just IT.
Who are the stakeholders?
A stakeholder is anyone who uses, owns, depends on or is affected by the data or the systems being migrated. They split into two groups, and the split applies to any company.
Example 1: a CRM system
Internal stakeholders:
- Sales team: accounts, pipeline, deal history
- Marketing team: campaigns, segments, consent flags
- Customer service and support: tickets, contact history
- IT and administrators: integrations, access, security
- Executive leadership: reports, KPIs, cost and risk
External stakeholders:
- Customers and clients: their data must stay accurate and private
- Leads and prospective buyers
- Partners and vendors: integrations and shared data feeds
Example 2: a car wash business
- Internal: business owners, general managers, car wash technical staff
- External: customers, local authorities (permits, environmental rules), suppliers and vendors, maintenance and repair technicians, financial institutions
External stakeholders are rarely interviewed directly, but their interests still produce requirements, for example customer privacy under GDPR, or a bank needing accurate financial records.
Why requirement gathering matters
Assumptions are one of the most common causes of migration failure:
- The technical team decides a dataset is unnecessary, but a business user relies on it daily.
- The migration is a technical success (all rows moved), but reports, daily workflows or compliance needs are not supported afterwards, so the business never gets the value it wanted.
Consistent stakeholder engagement throughout planning, not only at kickoff, prevents this.
Requirement gathering techniques
- Interviews: one-on-one conversations with owners and key users. Best for depth, hidden rules and edge cases.
- Workshops: collaborative sessions with several departments. Best for resolving conflicting needs and agreeing priorities.
- Surveys: questionnaires sent to many users. Best for breadth, such as which reports and fields people actually use.
- Observation (job shadowing): watching current workflows. Best for finding workarounds and spreadsheets nobody mentions.
- Document and system analysis (added): reviewing existing reports, data dictionaries, schemas and logs. Best for checking what people say against what the data shows.
Questions worth asking
- Which data and reports do you use every day, week and month?
- What would break if this field or table disappeared?
- How much history do you need in the new system, and what can be archived?
- What downtime is acceptable, and when?
- Are there legal, audit or retention rules on this data?
- Who signs off that the migration is correct?
Types of requirements to capture
- Business requirements: goals and outcomes (for example one customer view for sales)
- Functional requirements: what must work afterwards (reports, workflows, integrations)
- Data requirements: which entities, fields and history move, and the quality rules they must meet
- Non-functional requirements: performance, availability, downtime window, security
- Compliance requirements: privacy, retention, audit trail
Documenting and managing requirements
- Record each requirement with an ID, owner, priority (for example MoSCoW: must, should, could, won't) and acceptance criteria.
- Keep a stakeholder map, such as a power-interest grid or a RACI chart, showing who decides, who is consulted and who is informed.
- Trace every requirement to a test, so validation proves it was met.
- Get written sign-off, and route later changes through change control.
Career note
The lecture closes by pointing to the demand for data migration roles, especially in the US market: data migration analyst, data migration engineer, migration consultant and ETL developer. Job listings commonly ask for SQL, ETL tools, data mapping and validation, cloud platforms, and exactly this skill of engaging stakeholders and translating business needs into migration requirements.
Key takeaways
- Requirement gathering means collecting, analysing and documenting what every affected group needs.
- Stakeholders are internal and external, in every business, from CRM platforms to car washes.
- Assumptions cause failures: confirm before excluding any data.
- Use interviews, workshops, surveys and observation together, and engage stakeholders throughout.
Next: 9. Data Volume and Complexity Analysis.