The sample review deduplicates the seven supplied rows to three active confirmed IDs, showing 30% utilization and seven remaining places. Cancel C03 to see two confirmed IDs, 20% utilization and eight remaining places. Set capacity to unknown and the count stays known while the ratio disappears.
Write the reader action before the visual request
Microsoft's BI planning guidance distinguishes gathering business requirements from translating them into technical mappings and calculations. It also describes mock-ups and technical validation of the design. Apply those concepts to a platform-independent brief rather than assuming a particular reporting tool is already configured. Microsoft Learn: BI Solution Planning
Give requirement R01 this reader question: “Which session needs capacity review before inviting more people?” Its output should make a coordinator inspect current registration status and confirmed capacity. It does not authorize an invitation or decide who may attend.
Record the reader role, intended action, session scope, metric owner, data owner, and actual approval fields. Leave unknown people and decisions unfilled. “Build a utilization chart” is too little information to establish the numerator, denominator, freshness, or action it should support.
Define confirmed count with a grain and exclusions
R01 version 1 defines confirmed count as distinct active confirmed registration IDs for the selected session at the stated as-of snapshot. Exclude cancelled and waitlisted records. Count an exact duplicate report of the same registration only once.
Specify the expected current-record grain and how historical status changes become a current status before applying that definition. Two contradictory current rows are a data question, not permission to pick the convenient status. Ask the data owner to establish the rule; do not treat a proposed field name as proof the source provides it.
| Requirement component | Proposed definition or open question |
|---|---|
| Numerator | Unique active confirmed registration IDs in session/as-of scope |
| Denominator | Positive session capacity confirmed by its responsible owner |
| Utilization | Confirmed count ÷ confirmed capacity, displayed as percent |
| Remaining capacity | Confirmed capacity − confirmed count |
| Unknown capacity | Show confirmed count; utilization and remaining capacity unknown |
| Refresh/as-of | Display the actual supplied snapshot time; cadence TO CONFIRM |
| Source status mapping | Actual source values and current-record rule TO CONFIRM |
| Access and approval | Actual authorization and design decision pending |
No fixed red/green threshold is supplied. If the reader needs a threshold for review, record who defines it and test it explicitly. Do not choose one just to make a chart colorful.
Acceptance case A: Inspect the seven rows
Use a fictional S-A snapshot with supplied capacity ten and these synthetic records:
| Registration ID | example status |
|---|---|
| C01 | Active confirmed |
| C02 | Active confirmed |
| C03 | Active confirmed |
| C01 | Exact duplicate of the first row |
| X01 | Cancelled |
| W01 | Waitlisted |
| W02 | Waitlisted |
The expected confirmed count is three. Utilization is 3 ÷ 10 = 30%, and remaining capacity is 10 − 3 = 7. Seven report rows do not mean seven confirmed registrations; the expected remaining seven is a separate calculation.
This is a supplied test capacity, not verification of an actual owner's capacity record. All rows are fictional and contain no registrant names or contact information. Keep these expected values beside the implemented results when reviewing your own build.
Test a cancellation change too: if the example changes C03 to cancelled, while the same valid capacity remains ten, confirmed count becomes two, utilization 20%, and remaining capacity eight. The source/current-status rule and as-of scope must be consistent with that revised test.
Acceptance case B: Keep a known numerator with an unknown denominator
Use three unique active confirmed IDs, but no confirmed capacity. The expected count remains three. Utilization and remaining capacity are unknown.
Do not display 0%, 100%, or seven remaining. Each would invent a denominator or a relationship the case does not supply. Preserve the visible numerator and unresolved capacity question together so the reader can see what is known and what needs review.
A useful acceptance table includes case ID, requirement version, inputs, expected count/ratio/remaining, missing-data behavior, actual output, evidence, and decision. An arithmetic match does not supply stakeholder approval or establish a production source mapping.
Turn the brief into a review
Use the All rows and Confirmed only buttons to inspect the records behind the metric. The filtered rows retain the original IDs, including C01’s duplicate report; the metric still counts that registration once. Change the supplied capacity only when testing a declared scenario. Blank capacity displays unknown, while a nonpositive or malformed value requests a valid capacity.
Changing a definition needs a new requirement version. Including waitlisted people would describe demand, not confirmed utilization. Keep that proposed metric distinct, with its own test cases and owner review. Actual source mapping, freshness and approval belong in the requirements brief.
Copy this prompt
Create an interactive requirements review for R01 version 1, a fictional workshop capacity metric. Reader question: Which session needs capacity review before inviting more people? Use seven S-A rows: C01 active confirmed, C02 active confirmed, C03 active confirmed, exact duplicate C01 active confirmed, X01 cancelled, W01 waitlisted, W02 waitlisted. Initial supplied capacity is 10 places. Confirmed count means distinct active confirmed registration IDs. Exclude cancelled and waitlisted rows; an exact duplicate contributes once. The correct initial metric is count 3, utilization 30%, remaining 7.
Display the raw row table and definition together. All rows and Confirmed only filters inspect meaningful record subsets without changing the definition. A Cancel C03 scenario changes its status and recomputes count 2, utilization 20%, remaining 8. Provide a labeled capacity field and an Unknown capacity button. Blank means capacity unknown: keep the count while utilization and remaining are unknown. Invalid or nonpositive capacity cannot become a denominator. Reset restores the supplied seven-row case and capacity 10. Display R01 version and make clear that all records are synthetic; no source connection, invitations or actual owner approval occurs.
Return one complete self-contained HTML file with embedded CSS and JavaScript. Use native labeled controls with type="button" actions, readable text of at least 16px, strong contrast and visible focus. Make the layout responsive at 360px without horizontal scrolling. Keep supplied text literal. Use no remote dependencies or storage, and describe only actions the page actually performs.
Review the requirement with its owner
Put the definition, source-field questions and these acceptance cases in the team’s maintained requirements brief. Ask the owner whether confirmed capacity is the decision they need before approving a design. For the metric-definition review, NOS can render the prepared HTML with the sample rows beside the acceptance results. Begin with the duplicate C01 row so the reviewer can trace 30% to the agreed numerator and denominator.