HKSM

A technology-neutral register that lists and defines the business data needed by the project, including entities, attributes, and relationships. It clarifies meaning and use of data across teams without committing to a physical database design.

Key Points

• Technology-neutral view of business data; it is not a physical database schema.
• Captures entities, key attributes, relationships, and CRUD interactions across processes.
• Supports requirements, integration, data migration, testing, and data quality planning.
• Improves shared understanding and reduces ambiguity in terminology and data usage.
• Owned by a business analyst or data architect with input from domain SMEs and the product owner.
• Version-controlled and updated as requirements evolve and interfaces change.

Purpose

• Establish a common language for data used by the project.
• Guide solution design while remaining independent of specific technologies.
• Enable impact analysis for changes to requirements, processes, or integrations.
• Inform data quality rules, access controls, and compliance considerations.
• Support test case design, data migration planning, and interface specifications.

Field Definitions

• Entity name: The business object (for example, Customer, Order).
• Business definition: Clear description of what the entity means within the project scope.
• Key attributes: Critical data elements for the entity (name, code, status, dates).
• Primary identifier: Attribute(s) that uniquely identify a record.
• Relationships: Cardinalities and associations to other entities (one-to-many, many-to-many).
• CRUD by process: Which project processes or use cases Create, Read, Update, or Delete the entity.
• Source/owner/steward: System of origin and business role accountable for data quality.
• Classification: Sensitivity level or confidentiality tags (public, internal, confidential).
• Validation rules: Business rules and constraints (formats, ranges, mandatory fields).
• Retention/archival: How long data is kept and disposition approach.
• Notes/assumptions: Clarifications, open questions, or dependencies.

How to Create

1. Elicit data needs from scope, user stories, processes, and interface requirements.
2. List candidate entities and agree on consistent business names and definitions.
3. Identify key attributes for each entity and define the primary identifier.
4. Map relationships between entities and document cardinality and optionality.
5. Link entities to processes or use cases and capture CRUD interactions.
6. Assign stewardship, define data quality rules, and set classification levels.
7. Review with stakeholders, resolve terminology conflicts, and baseline the register.
8. Place the artifact under version control and integrate it with requirements traceability.

How to Use

• Validate that requirements and user stories reference agreed data terms and attributes.
• Guide solution design and interface contracts without prescribing a physical schema.
• Support test data planning and data validation criteria for acceptance tests.
• Perform impact analysis when changes affect entities, attributes, or relationships.
• Align data migration scope and mapping between legacy and target entities.
• Inform security, classification, and retention controls for compliance.

Ownership & Update Cadence

• Primary owner: Business analyst or data architect; accountable steward: product owner or data steward.
• Contributors: Domain SMEs, system analysts, QA, security/compliance, and integration leads.
• Update cadence: At each requirements increment, interface change, or design review; baseline before build.
• Governance: Version-controlled with change requests and review by affected stakeholders.

Example Rows

• Entity: Customer | Definition: A party that purchases or receives services | Key attributes: CustomerID (PK), Name, Segment, Status | Relationships: Customer 1..* Order | CRUD by process: Onboard-C, View-R, Update details-U, Close-D | Classification: Confidential.
• Entity: Order | Definition: A confirmed request for goods or services | Key attributes: OrderID (PK), OrderDate, TotalAmount, Status | Relationships: Customer 1..* Order, Order 1..* Payment | CRUD by process: Create order-C, Track-R, Amend-U, Cancel-D | Classification: Internal.
• Entity: Payment | Definition: A monetary transaction applied to an order | Key attributes: PaymentID (PK), Method, Amount, Date, AuthorizationCode | Relationships: Order 1..* Payment | CRUD by process: Capture-C, Reconcile-R, Refund-U, Void-D | Classification: Confidential.

PMP Example Question

During planning, stakeholders disagree on what a "client" versus a "customer" means across multiple systems. Which artifact should the project manager request to clarify data elements and relationships without committing to a specific database design?

1. Logical data.
2. Requirements traceability matrix.
3. Physical data schema.
4. Test plan.

Correct Answer: A — Logical data

Explanation: Logical data provides a technology-neutral register of entities, attributes, and relationships, resolving terminology conflicts. A physical schema or test plan would not address conceptual meaning across systems.