DAM requirements checklist: 260 requirements by domain

What the checklist is for

The DAM requirements checklist is a reference list that buyers use to cross-check their own requirements for gaps before vendors see them.

The checklist belongs to Checkpoint 2 of the Selection Route. In the PIMvendors method, requirements start with the people who do the work. Teams collect needs in workshops, write them as user stories and validate them with the people who raised them. The checklist then shows what the workshops missed.

DAMSelection assessment: a checklist copied straight into an RFP produces identical answers from every vendor. Every vendor marks 260 lines as supported. The value of the checklist lies in the cross-check and in the priorities.

Three uses make the checklist worth the time:

• Gap check: catch capabilities nobody raised, such as rights expiry, export or audit logs.
• Priority check: force a decision on every line, including what the DAM will not do.
• Scenario check: confirm that every must-have appears in at least one scripted scenario.

The five domains

The DAMSelection DAM requirements checklist splits 260 requirements into five domains of 52 lines each, and each domain has a natural validator inside the organisation.

Requirement IDs in the Requirements Builder start with a domain letter. A stands for asset management, M for metadata and search, W for workflow and rights, D for distribution and integration and S for security and platform. Keep the IDs when you add your own lines, so vendor answers map back to the list.

How to use the checklist

DAM teams use the checklist in eight steps, starting from their own validated needs and ending with a scenario map.

1. Collect needs per user group in workshops and write them as user stories.
2. Map each user story to one or more checklist lines, by ID.
3. Walk through every domain and flag lines that no story covers.
4. Ask the validator of each domain to accept, change or reject each flagged line.
5. Add organisation-specific lines: industry rules, named integrations, languages and volumes from the content audit.
6. Set a MoSCoW priority on every line, including the default lines you keep.
7. Link every must-have to the scripted scenario or document that proves it.
8. Export the final list for the RFP and the scoring matrix.

Step 3 usually adds 10 to 30 lines to a workshop list, as a DAMSelection rule of thumb. Rights, export and administration lines are the most common gaps.

Prioritise with MoSCoW

MoSCoW prioritisation sorts each DAM requirement into must, should, could or won't, and the must category should hold only lines whose absence would stop the project.

Fact: DSDM, the project framework that defined MoSCoW, recommends typically no more than 60% Must Have effort in a project. A selection list needs a tighter rule, because each must-have becomes a gate that can remove a vendor. The DAMSelection default marks 45 of 260 lines as must, about 17%.

DAMSelection rule of thumb: keep musts under one third of the final list. Write every must-have so that a vendor can fail it. A must-have that every vendor passes on paper carries no selection value.

Test each candidate must-have with three checks:

• Absence stops go-live for the main use case.
• No workaround exists for the first year.
• A demo, proof of concept or document can prove the line.

A line that fails any check becomes a should.

Won't-haves name the anti-patterns

DAM won't-haves record what the organisation explicitly excludes, and the DAMSelection checklist uses one won't line per domain for a common anti-pattern.

Stating won'ts in the RFP saves demo time. Vendors stop presenting features the buyer has ruled out.

From requirement to scenario

DAM must-haves become testable when the team groups them into scenarios, each following one real task from start to finish.

DAMSelection assessment: nobody can demonstrate 260 separate lines in two hours. A scenario covers five to ten related lines in one flow, so the panel sees how the lines work together.

Worked example: the licence expiry scenario covers six checklist lines.

Build a coverage matrix with requirement IDs as rows and scenarios as columns. Every must-have needs at least one mark. Must-haves without a mark either need a new scenario or a document as proof. The demo script guide shows how to write each scenario.

Add industry lines

DAM requirements checklists need industry lines on top of the five generic domains, because regulation and product structure differ by sector.

The lines come from the industry extensions of the Metadata Model Builder. The industry fit pages explain each sector's scenarios.

Match each line to its evidence

Each DAM requirement needs one type of evidence, and the evidence type decides when and how the team checks it.

Security and platform lines rarely show in a demo. The security requirements guide lists the documents to request. Functional lines need measurable conditions, explained in the functional requirements guide.

Use the Requirements Builder

The Requirements Builder holds all 260 DAMSelection requirements with their default priorities, and it exports your edited list as a CSV file.

1. Filter by domain to review one domain with its validator.
2. Filter by priority to review all must-haves together.
3. Change the priority per line to match your scope.
4. Export the list, which carries ID, domain, requirement and your priority.

Add four columns in the spreadsheet after export: source user story, validator, scenario or evidence type, and vendor response. The same sheet then feeds the RFP and the scoring matrix.