Requirements Specification
Go to Playbook Main Page
Prev: Inception
Next: Design
Requirements Gathering and Analysis Phase#
Hold "Alt" / "Option" to enable Pan & Zoom
Key Ideas
- The Requirements Specification is the ultimate source of truth for Quality Assurance (testing) and Acceptance.
- Technical Requirements are derived from and designed to satisfy Business Requirements.
- Requirements specification includes both Functional and Non Functional requirements.
- The Solution Architect, as a maintaining party,must participate in drafting the specification to eliminate ambiguity.
- The Requirements Specification must be aligned with all acceptance parties.
- If any requirement lacks immediate clarity, a Feasibility (Gap) Analysis should be conducted.
- The Solution Design must be reviewed by the Design Authority to ensure compliance with Technical, Data, and Architectural policies and strategies.
- Any updates to the Requirements Specification must be aligned with acceptance parties at all times.
- A well-defined and properly aligned Requirements Specification leads to Higher delivery quality and Increased satisfaction among stakeholders
Roles Involved#
- Accountable: Product Owner
- Responsible: Business Analyst
- Consulted: All relevant parties in their respective areas: Data Governance Lead, Solution Architect, Data Engineer, Domain SME, Source Data Owner, Integration Architects.
1. Input#
All the materials required to understand the business and technical context.
| Category | Input |
|---|---|
| Business | - Business strategy and goals - Existing data issues (duplicates, inconsistencies) - Regulatory/compliance needs (e.g., GDPR, HIPAA) |
| Technical | - Existing source system documentation (CRM, ERP, etc.) - Data architecture diagrams - Data quality reports (if available) |
| Stakeholders | - Interviews and feedback from business users, stewards, IT, governance teams |
| Data | - Sample datasets - Data dictionaries - Legacy MDM or data integration tools (if any) |
2. Process#
Activities to refine and define what the MDM solution must deliver.
| Step | Description | Know More |
|---|---|---|
| Elicit Requirements | - Conduct workshops, interviews, and surveys with stakeholders | |
| Analyze Data | - Perform data profiling on key entities (Customer, Product, Vendor, etc.) - Identify duplication, nulls, inconsistent formats |
Data-Analysis-and-Profiling |
| Define Scope | - Confirm which domains (Customer, Product, etc.) will be in scope - Agree on MDM use cases (e.g., golden record creation, data sync, stewardship workflows) |
|
| Define Functional Requirements | - Match/merge rules - Survivorship logic - Workflow approvals - Data access & roles |
|
| Define Non-functional Requirements | - Performance expectations - Security & access controls - Audit/logging |
|
| Document Requirements | - Create the Business Requirements Document (BRD) and Functional Specs | |
| Sign-Off | - Requirements are reviewed and approved by stakeholders and governance board |
3. Output#
Deliverables that define what will be designed and built.
| Output | Description | Templates |
|---|---|---|
| Functional Specification Document(FS) or Requirements Specification Document | Includes Functional requirements, such as data quality rules, workflows, matching/survivorship rules, and Non-Functional requirememts along with Governance - captures standard definitions of attributes and KPIs, including calculation. Compliance - captures requirements for Legal and corporate policies compliance. Security - captures requirements for data security (encryption, RLS/CLS, etc) Infrastructure - capture access management requirements Data Sources* - captures integration with data sources requirements |
FS-GxP FS |
| Source to Target Mapping document | - Document how data elements from source systems are transformed and loaded into the target MDM environment and the downstream publish layer | STTM Template |
| Data Profiling Report | Summary of current data quality issues and duplication metrics | Data-profiling template |
| Conceptual and Logical MDM Model | Early-stage entity-relationship diagrams and core object definitions | Data-Modelling |
| Gap Analysis Document | Identifies current system gaps and MDM improvements | |
| Product Backlog | Prioritized list of features, rules, integrations, and user stories needed to build and govern the solution. | |
| Approved Scope & Sign-Off | Stakeholder validation that requirements are complete and correct |
What Happens Next?#
- Once the Requirements Specification is finalized, backlog shaping and Design planning can begin.
- When the Requirements Specification is defined, a Risks Assessment must be conducted to identify potential delivery challenges.