Requirements or acceptance criteria?

Lots of questions on this lately as we examine how our product teams could scale.

Requirements are the input to your engineering function. It's what your client wants. They are idealized descriptions of what the client thinks they want the software to do. They're generated ahead of time, often as the output of brainstorming, or in the best case, prototyping.

The responsible software developer will use this as a starting point, and engage in a requirements gathering or discovery phase. The client likely won't know to include every useful piece of information that enables engineering to make the best decisions, so it's on engineering to probe a bit deeper.

This might be as simple as spending time with the client prioritizing the requirements and capturing the most immediate use cases and most prominent concerns. Discussions will also likely touch on quality attibutes such as security, performance, responsiveness.

Acceptance Criteria are then the agreed-upon measures of what will be delivered. They are drafted by engineering take into consideration the current realities at the point of delivery. The client doesn't know about the state of your software stack when they are coming up with how they want the product to work. They likely care more about getting the right thing out quickly and cheaply then the exact thing described in the original requirements.

A technical surplus might make certain approaches easy. In the same manner, accrued technical debt could make other approaches difficult, to the point where it's desirable to put it off until costs can be significantly lowered. Previous architectural choices could warrant a change to user interface behaviours.

Acceptance Criteria enable alignment on outcomes and managed expectations. It's not only what will be delivered, but what will be delivered effectively, with reduced risk, and on a smaller timeline.