# Example software scope: request portal

Original Culvion Technologies example · 7 November 2026

ILLUSTRATIVE ONLY. This is an original fictional project scope for discussion. It is not a quote, a contract, a completed build, legal terms or a claim of past client work. Commercial and ownership terms require a specific agreement.

## 1. Example problem

Requests arrive in an inbox. Staff copy them into a separate list and customers ask for status updates. The proposed first release gives requests one entry point, a staff review step and a customer-visible status.

Evidence to obtain before estimating: a sample request, existing tools, current volume, status rules and the person who can approve the workflow.

## 2. Users and first-release tasks

| Role | Included example tasks |
| --- | --- |
| Customer | Submit a request, receive a reference and view the permitted status of their own request |
| Authorised staff member | Review a request, ask for missing information and update the agreed status |

Access and account recovery must be designed and tested. The role labels do not prescribe a particular identity product or security certification.

## 3. First-release boundary

Included for discussion:

- The agreed request form and validation.
- Customer request list/detail views within the permitted account boundary.
- Staff review and status-update views.
- Agreed status-change notifications, subject to the selected provider.
- A record of agreed changes and review information.
- Documentation and handover identified in the proposal.

Outside this illustrative first release:

- Payments, refunds or automated eligibility decisions.
- Native mobile apps.
- Unspecified CRM or accounting integrations.
- Historical data migration without a reviewed source and mapping.
- Universal round-the-clock support or unspecified future features.

## 4. Acceptance checks to refine with the buyer

1. A valid request is recorded once and receives a usable reference.
2. Missing required information produces a clear error without losing other entered information.
3. A customer can view only the requests permitted by the agreed access design.
4. An authorised staff member can make the allowed status changes; an unauthorised user cannot.
5. A recorded status appears consistently in the relevant views.
6. A notification failure is visible to an agreed owner and can be retried or handled manually.
7. The agreed user tasks can be completed on the selected devices, including keyboard use.
8. The handover checklist and agreed documentation are complete before acceptance.

These checks are a starting point. Performance, accessibility, data handling and operational requirements must be made specific to the actual project.

## 5. Dependencies and decisions

| Question | Decision or evidence needed |
| --- | --- |
| Who approves the workflow? | Named business owner and review availability |
| Where do accounts and records live? | Selected systems, ownership and approved access |
| What is the status model? | Allowed values, transitions and exception owner |
| What information is stored? | Required fields, handling and retention requirements |
| Which messages are sent? | Provider, content, costs, failure route and permissions |
| What is migrated? | Sample data, mapping, cleanup and acceptance checks |

## 6. Commercial schedule: to be completed for a real proposal

| Component | Example scope boundary | Price / effort / timing |
| --- | --- | --- |
| Discovery and design | Agreed journeys, decisions and reviewable screens | To be assessed and agreed |
| Build and validation | Accepted first-release tasks and checks | To be assessed and agreed |
| Tools and hosting | Selected accounts and provider charges | To be identified and agreed |
| Handover and support | Documentation, account access and named support scope | To be assessed and agreed |

No sample prices, savings, launch dates or ROI figures are supplied. Changes should identify their effect on scope, effort and timing before approval.

## 7. Handover questions

- Who owns and receives access to the source repository?
- Who owns the domain, hosting and third-party accounts?
- Which documentation and administrator training are included?
- Who operates backups, monitoring and incident handling?
- Which defects or changes are included after acceptance, and for how long?
- How will future maintenance, new features or exit be handled?

Record the answers in the actual agreement. The example does not establish those terms for Culvion or the reader.