A portal specification is more useful when it describes what a person must accomplish than when it lists screens. Start with a representative request and the roles that handle it.
Describe records and transitions
Identify the main record and the fields that are required at each stage. A draft may allow missing information that a submitted record cannot. State who may move the record between stages and what must be recorded when they do.
Include corrections and withdrawals. A requirement that only describes successful submission leaves important behaviour undecided.
Specify visibility separately from editing
Define which roles can read a record, change its fields and make a decision. These permissions are different. External users may need status visibility without access to internal comments.
Use sample accounts to review the intended access. Avoid assuming that a menu hidden in the interface is an access-control rule.
Write examples that can be checked
Replace “the portal handles approvals” with a concrete case: a reviewer can request changes, the submitter can provide a revision, and the original review remains distinguishable from the new one.
Document the output needed after completion, including exports or notifications. The HATT services page explains how discovery, design and engineering can develop this definition into a working product.