What a good software project brief actually needs

Resolve a rule that changes the release

Consider a fictional portal where each identity may belong to only one customer account. An administrator at Cedar invites a colleague who already belongs to Harbour. No customer data or identity service was examined for this example: the names and account rule are invented. The question is whether accepting Cedar’s invitation should move that identity, create another membership, or refuse the change.

Moving the identity could remove access that Harbour still expects. Allowing another membership would contradict the stipulated account rule and introduce account switching. For this example, I recommend refusing cross-account acceptance in the first release and referring the request to a defined support process. That is a proposed product policy, not a universal rule for invitation systems. A product designed for consultants serving several customers may need multiple memberships instead.

The revised brief therefore says: an eligible recipient can accept into the inviting account; a recipient already assigned elsewhere receives no new membership and no change to the existing one. The refusal must not disclose the other account’s name to the inviting administrator. Bulk invitation and account transfer remain outside this release. Support must have an approved transfer procedure before the team advertises transfers as available.

This decision adds a refusal path and a support handoff to the estimate. It removes the need to design self-service account switching for this release; it does not make the whole project cheaper by a known amount. The technical lead still needs to confirm whether the existing identity service can enforce the rule without replacing or duplicating its source of truth.

Turn the decision into cases the team can check

The fictional acceptance review now has a concrete contrast: an eligible recipient joins Cedar, while an identity in Harbour stays in Harbour and gains no Cedar access. A Cedar administrator cannot issue invitations on Harbour’s behalf. An expired or revoked invitation grants no access. Repeating a successful acceptance must not create another membership. These are proposed acceptance criteria; no invitation implementation or security test was run for this article.

OWASP’s Authorization Cheat Sheet recommends defining permissions for users and resources, denying access by default and checking permissions on every request. It also warns against relying on client-side access checks. That supports requiring enforced account permissions and tests. It does not choose this fictional one-account policy or specify an invitation lifetime.

A hidden button would not establish the refusal behavior. I recommend asking the delivery team to test direct acceptance requests as well as the visible workflow. Include a case where the recipient’s account assignment changes after the invitation was issued. The design must resolve that stale state at acceptance, rather than relying only on a check performed when the email was sent.

An email outage is a separate case: I recommend keeping a visible invitation state that an authorized administrator can retry or revoke. Sending an email and granting membership are different events. The brief should say which outcome the recipient and administrator see after a failed delivery; the mechanism for reliable delivery belongs in the technical design.

Put an owner beside the remaining uncertainty

For this hypothetical brief, the product owner approves the refusal policy and its customer-facing wording. The identity-service owner must confirm the membership rule and a test environment. The support lead defines the escalation route. These are assigned responsibilities in an example, not people who have accepted work for a real project.

Invitation lifetime remains an owned decision: the product owner and security reviewer must agree it before implementation is accepted. I recommend recording the consequence if a decision is late. If no safe transfer process exists, transfer assistance cannot be promised in the release copy. If the identity service cannot enforce the account rule, stop and revise the design and estimate rather than quietly adding a second membership database.

I recommend distinguishing a scoped discovery estimate from a fixed delivery commitment. The identity-service capability is a condition of this example’s delivery scope. Record the proposed rule, who must validate that dependency, and what work resumes only after confirmation.

Separate the goal from the proof

I recommend defining the support-request category before promising a reduction. Count the same category before and after release, and note changes in the active customer population or support process. A lower count alone may reflect fewer customers rather than a better workflow. This example has no measured baseline or observed reduction; it makes no claim about saved support time.

Acceptance tests answer a narrower question: does the agreed behavior work? Meeting the invitation criteria would not by itself show that customers can discover or understand the feature. I recommend assigning an outcome review separately from release acceptance, with someone responsible for interpreting the result.

Keep the brief small enough to change

I recommend keeping the decision boundary in the brief and attaching detailed rules or payloads separately. Record meaningful changes and their effect on scope. If the client later needs consultants to join several accounts, reopen the one-account decision: that changes permission boundaries, account selection and acceptance cases. It is more specific than calling the request “just another invitation option.”

Before requesting a final delivery estimate, I recommend that the product owner and technical lead walk through the eligible and refused cases together. The useful result is an agreed boundary and a visible dependency, rather than a long feature list that hides the decision. The brief does not replace threat modelling, implementation tests or a commercial agreement.