Pharos Production / Review brief
Software Development Brief: Compare the Exclusions
A proposal can name every feature and still leave the release boundary unclear. Use this brief to compare the work a supplier will deliver with the work your team must provide.
Original editorial worksheet · Updated
- Use it for
- Prepare comparable proposals for a web application, mobile product or custom business system.
- Output
- A blank, editable record with evidence fields and ownership.
- Tool behavior
- The CSV is a static download. No project details are requested or submitted.
Set the boundary before comparing
Start with the user task and the current workflow. Specify the supported devices, accessibility needs and interfaces before choosing a framework. For a mobile application, include the release and store-review responsibilities. For an internal web product, name the identity system and the teams that own connected data.
A new build needs a product boundary. A staff augmentation engagement needs a responsibility boundary. Compare those arrangements separately: adding engineers to your team does not automatically transfer architecture, product management or release ownership to the supplier.
The evidence record
Use one row per review area. The role is a starting point; assign a named owner in your project. Attach a sanitized reference and retain unresolved questions until a reviewer has a supported answer.
| Review area | Evidence to attach | Suggested role |
|---|---|---|
| Product boundary | User journeys, included screens and explicit exclusions | Product owner |
| Interfaces | Versioned API or data contract and dependency owner | Integration lead |
| Quality | Acceptance examples, supported devices and defect decision rule | QA lead |
| Design | Editable design files, assets and accessibility review | Design owner |
| Release | Environment access, deployment steps and rollback record | Release owner |
| Handover | Repository rights, documentation and maintenance boundary | Receiving team |
The CSV adds assigned owner, evidence reference, status, unresolved question and review date columns. Every row starts as draft.
A fictional example
For a fictional patient portal, "appointment booking" is too broad to compare. One proposal might include a calendar interface while another includes the scheduling-system adapter and failure handling. Put the adapter, its test environment and its receiving owner on separate lines before comparing prices.
Use the record in a review
- List the workflows that will change and the existing systems they depend on.
- Ask each supplier to mark every row included, excluded or dependent on another party.
- Attach an acceptance example and a receiving owner to each included deliverable.
- Compare the same boundary across proposals. Record unresolved assumptions before selecting a delivery model.
Download the blank CSV and keep the completed version with your project records.
Source and limits
This is an editorial procurement worksheet. It does not estimate a project price, assess a supplier or certify software quality. Use actual scope and contract terms for those decisions.
OWASP Application Security Verification Standard. A reference for defining application security verification requirements; select the applicable requirements for the actual product.
Source reviewed 9 November 2026. The suggested fields are this site's editorial method, not an external certification standard.