How to write testable PIM requirements, with examples

What makes a PIM requirement testable?

A PIM requirement is testable when it names an actor, a capability and a condition, and comes with an acceptance test. Remove any of the four parts and the requirement turns into a statement every vendor can accept. This page is part of the PIM requirements guide, which explains where writing fits in the selection.

The actor is often the PIM itself. It can also be a user role, such as a data steward, or the vendor, for contract and service requirements. The condition is the part most often missing. "The PIM validates GTINs" is true for most systems. "On every entry path including supplier imports" is where vendors differ.

The acceptance test sits outside the statement. Keep the statement to one sentence and put the test in its own field, with the data, the action and the expected result.

Bad versus good PIM requirements

Bad PIM requirements describe a wish, a feature name or two capabilities at once. Good requirements describe one observable behaviour under a stated condition. The table shows typical rewrites from PIMvendors selections.

Every good requirement in the table can be answered with yes, partly or no after a short test.

How do we write the acceptance test?

Write the acceptance test as one sentence with the data, the action and the expected result. The test should be something a vendor performs in a scenario demo on your own sample data, or a document you can check.

Four evidence types cover all requirements in practice.

1. Live demo on your data: for most DM, PR and IN requirements, such as importing a file with seeded errors.
2. Configuration on request: for requirements about effort, such as building a workflow live from your process description.
3. Document review: for security, SLA and policy requirements, such as an ISO/IEC 27001 certificate or an API versioning policy.
4. Contract clause or reference call: for licence, exit and partner requirements.

Tests that need your data define what you must prepare. A test that imports "one of your supplier files" means a real supplier file must be ready, anonymised where needed, before the scenarios go out. In PIMvendors selections, preparing the sample data takes longer than writing the tests. Plan it as a separate work package. The way tests combine into demo flows is explained in scenario-based demos.

How do we trace requirements to business processes?

Trace each requirement to one process step and one owner, and record both next to the requirement ID. Traceability turns a list into a defended set, because every requirement has a person who needs it and a process that fails without it.

Use your process maps as the backbone. Typical PIM processes are new product introduction, supplier onboarding, enrichment, translation, approval, channel publication, change management and phase-out. Each requirement belongs to one of them, plus the platform processes owned by IT, security and procurement.

Add three columns to your requirement sheet: process step, requirement owner and demo scenario. The first column shows coverage per process. The second shows who defends the requirement in scoring. The third shows where the requirement is tested.

Requirements without a process step are candidates for removal. Process steps without requirements are gaps. Both become visible within an hour once the columns are filled. Priorities then follow from process value, which is covered in prioritising PIM requirements.

Which words make a requirement untestable?

Vague adjectives and open-ended verbs make a requirement untestable. Replace them with a measure, a condition or a concrete behaviour.

The EARS patterns developed at Rolls-Royce offer a useful discipline for conditions. They separate requirements that always apply from those that apply on an event (when) or in a state (while). Further patterns handle unwanted behaviour (if, then) and optional features (where). In PIM requirements, the event and unwanted-behaviour patterns are the most useful. "When a supplier file is imported" and "if a GTIN fails the check digit" make the condition explicit.

A six-step method for writing PIM requirements

Writing a requirement set works best as a short, structured sequence with one owner. The method below is how PIMvendors runs requirement workshops.

1. Map the processes: draw the target flows for introduction, onboarding, enrichment, publication and phase-out.
2. Inventory the data: build the attribute and family inventory described in designing the product data model.
3. Start from the checklist: filter the PIM requirements checklist by industry and regulation, and adopt, adapt or drop each item.
4. Write your own: add requirements for your specific processes in the same format, with your own ID prefix.
5. Add tests and traces: complete the acceptance test, process step and owner for every line.
6. Review and freeze: remove duplicates, split double requirements, set priorities and freeze the set before scenarios are sent.

The freeze matters. Requirements written after the demos tend to describe what the favourite vendor showed, which removes the comparison the selection was meant to produce.