Turn a workload brief into testable requirements

Cloud planning starts with the workload that will run, not a product list. 'We need a fast booking site' does not define concurrent use, the critical operation, data volume or tolerable downtime. A specialist should not resolve that uncertainty by choosing an oversized server. Write a requirements sheet linking every requirement to its owner, measurement unit and verification method. Separate functional outcomes, demand volume, data and access constraints, and disruption or data-loss limits. If a sponsor asks for 'excellent performance', ask which learner action matters: finding a course, placing a booking, paying, or receiving confirmation. Search pages may be fast while booking fails.

Give demand a denominator and observation window. Three hundred requests per minute averages five per second across that minute, but says nothing about bursts within a few seconds or the share reaching a database. Record the measurement window, request type, read/write mix and response time to be tested. If daily average is 40 requests a minute and a peak is 300 for 15 minutes, do not multiply the daily average by a day and treat that number as peak capacity. Use historical data when it exists, and label training numbers as assumptions. Measure successful requests and latency at a specified percentile, for example 95% of bookings within three seconds during a defined peak test. That is a hypothetical design threshold for the service owner to approve, not a universal requirement for websites.

Trace data before selecting storage: booking entry, seat-availability check, record write, confirmation number, management report. Identify essential fields, authorized readers and a retention period proposed by the data owner. The word 'secure' alone does not identify who may read a learner record or where a backup resides. Use synthetic records in training. In a real system, the data owner decides classification and obligations, while the team verifies access. Record external dependencies such as payment or mail. If either stops, does booking continue? Could retry charge a customer twice? Dependency boundaries prevent every failure being blamed on the cloud provider.

Separate availability from recovery. Multiple running front-end instances might preserve access when one instance fails, but they do not restore a record deleted in error. Ask the service owner for the maximum acceptable interruption and the maximum age of data that may be lost in a defined event. Record them as proposed RTO and RPO requirements, then check whether backup and recovery arrangements can meet them. Do not infer either from a 'daily backup' label. If a backup is taken at midnight and corruption happens at 23:00, restoring only that backup may lose about 23 hours of changes, absent an independent transaction log. This is arithmetic for the example, not a guarantee about a real system. Copying data, starting the application and verifying a real booking all belong in a restore-time test.

A sound requirements sheet distinguishes an observed fact, a planning assumption and a decision needing authority. A trace showing that a booking causes two reads and one write is an observation within a particular environment. Expecting customer volume to double next year is a business assumption. Buying reserved capacity for a year is a financial decision for an authorized owner. State the source, date and confidence for every number. If attachment sizes are unknown, schedule a sample measurement rather than enter zero. If 20,000 bookings are expected and one record averages 4 kilobytes, assumed raw records total about 80 decimal megabytes, before indexes, backups, logs and attachments. Do not present 80 MB as final capacity.

Every requirement needs acceptance evidence. 'Prevent a double booking under concurrent requests' can be tested by submitting two requests for one seat, verifying that only one record succeeds and the other user receives a clear response. 'Recover within one hour' requires a timed recovery exercise ending in a functional booking, not just a restarted server. 'Least privilege' requires a limited operator account attempting to read records beyond its role. Name the test environment, boundaries and authority; do not load-test a live system without approval. Prioritize launch conditions, improvement targets and deferred wishes. When high speed and low cost conflict in the absence of demand data, do not pretend one machine choice solves both: run a small experiment and recalculate.

End the sheet with a conditional decision: 'Move to an initial design if the service owner confirms the 300-request peak and success definition, the data owner provides retention rules, and a restore is tested.' That gives later resource comparison a usable input. Do not convert this learning program's nominal days or learner access window into workload operating hours; they describe different things. The specialist's role is to make the inputs reviewable, state limits, and escalate decisions belonging to the service or data owner.