A Requirements Checklist for Commissioning an Internal Web Application

Start with the business outcome and current process

Before commissioning an internal web application, define the business problem and the outcome it should support. Then describe how the process works today, including the spreadsheets, paper, email, existing systems and manual workarounds involved. This gives a supplier a basis for discussing what may help, without deciding the solution in advance.

Use this checklist to capture the starting point. For each item, note whether the answer is known, an assumption or an open question, and add an example where possible.

• Problem to solve: Which internal process is difficult to manage, and who is affected? Describe the issue in business terms, such as staff re-entering the same information or managers being unable to see progress.
• Current process: What happens from the first request or record to completion? Note who does each step and where information is entered, copied, checked or stored.
• Tools and workarounds: List the spreadsheets, forms, email inboxes and systems people use. Include manual steps that happen because a tool does not fit the process.
• Consequences: Record observable problems, such as delays, missing details, duplicated records or difficulty finding the latest version. Give a real example rather than estimating an unverified impact.
• Desired improvement: Describe what staff or managers should be able to do more easily. Possible measures include time to complete a task, repeated data entry, missing information or visibility of work in progress. Record any baseline or target only if you know it; otherwise mark it as an open question.

Keep early ideas separate from agreed needs. A supplier can help explore unanswered points, but the business should explain which outcome matters most and why.

Map the workflow, hand-offs and exceptions

Describe the process as it happens from the moment someone starts a task to the point it is complete. A simple step-by-step account is more useful at this stage than trying to design screens or decide how the application should work.

• List the steps in order. For each step, note who does it, what information they need and what starts or completes it. For example: a staff member submits a request; a manager checks it; an operations colleague arranges the next action.
• Mark hand-offs. Record when work moves between people or teams, who is responsible next and how they know it is ready. Note approvals, waiting periods and any point where work is sent back for changes.
• Describe what happens when the usual path breaks. Include incomplete submissions, rejected work, changed details, cancellations and tasks that need escalation. Note who decides what to do and whether the task continues, pauses or returns to an earlier step.
• Use a representative example. Follow one real task through the process, including its hand-offs and outcome. Remove confidential details where appropriate, but keep enough information to show what each person needed to do and what changed along the way.
• Separate established rules from open questions. If staff handle an unusual case differently each time, record that rather than assuming a fixed rule. Ask what decision needs to be made, who should make it and whether the supplier should explore options with you.

For each step or exception, write down an example or an unanswered question. This helps a supplier understand what the application needs to support, where work can stall and which cases may affect the scope. It also makes it easier to discuss whether a process should be preserved as it is or changed before it is built into software.

Identify user groups and access needs

Describe users by role or responsibility, not by name. This gives a supplier a clearer basis for understanding what people need to do and where access should differ, without requiring you to design the detailed permissions yourself.

• Name each user group. For example, record roles such as requesters, team managers, approvers or administrators where they match your process. Note any groups with different responsibilities, even if they currently use the same spreadsheet or shared inbox.
• For each group, list its tasks and information needs. Record what people need to view, add, change, approve or remove. Give a practical example, such as a manager viewing requests for their team or an administrator correcting a record.
• Identify restricted information and actions. Say which roles should or should not see particular records, or carry out actions such as approval or deletion. Explain the business reason, and flag any boundary you have not decided.
• Describe access administration. Note who asks for access, who approves it, and who makes changes when someone joins, changes role or leaves. Include any hand-off between a line manager and the person responsible for administering accounts.
• Record any external users. If suppliers, contractors or customers need access, explain what they need to do and which information they should see. If this is uncertain, mark it as an open question rather than assuming external access is required.

Keep detailed permission design and unusual cases for supplier discussion. Name the business owner who can decide them, and bring examples of the roles or records involved. That helps the supplier clarify choices without turning the brief into a technical access-control specification.

List the information the application must handle

Build a simple inventory of the records staff use, what they need to do with each one and where the information comes from. You do not need to settle every technical detail now: record examples and uncertainties so a supplier can help scope them.

• Main record types: List the things the process tracks, such as jobs, stock items, cases or members. For each, note the information staff need to identify and work with it, using a real example where possible.
• Actions on each record: Say whether staff need to create, view, change, search, import, export or retain the information. Note who needs each action, building on the user groups and access needs already identified.
• Sources and ownership: Record where each type of information originates, who maintains that source and which record should be treated as authoritative if the same details appear in more than one place. Flag any disagreements between sources as open questions.
• Existing information to move: List the spreadsheets, files or system records that may need to be brought across. Note their format where known, who can provide them and any examples of missing, inconsistent or outdated entries. If you do not yet know the data’s quality or completeness, say so rather than assuming it is ready to import.
• Personal information: Identify whether records include information about people, what information is involved and what the business uses it for. As a scoping prompt, note what personal information the application may use, how it may be used and for what purpose. Record uncertainties and responsibilities for discussion with an appropriate adviser; this inventory is for scoping, not a legal assessment.
• Open questions: Mark details that need investigation, such as who can confirm the source data or whether old records need to remain available. This helps separate known requirements from decisions to resolve with the supplier.

Record business rules, status changes and notifications

Turn process rules into clear decisions the application must apply, rather than describing a preferred technical solution. For each rule, record whether it is agreed policy, a current habit that may change, or a question for the people responsible for the process to resolve.

• Required information: Which fields must be completed before someone can submit or move a task on? Note what should happen if information is missing or does not pass a check.
• Conditions and thresholds: Record eligibility criteria, limits or approval conditions in business language. Give an example of a case that meets the rule and one that does not, if useful.
• Statuses: List the names used for each stage of a task. For each change, note what event causes it, who can make the change and what should happen if the expected next step cannot proceed.
• Approvals: State which decisions need approval, who is responsible and what should happen if an approval is declined or further information is requested. Mark unresolved ownership as an open decision.
• Notifications: Record who needs to know about each important event, what they need to be told and when. Include what should happen if the recipient cannot act, or if the information needed to continue is unavailable.
• Exceptions: Describe cases that do not follow the usual path, such as a task being returned for correction or cancelled. Say who decides what happens next and whether the standard rule still applies.

Use real examples from the process, but avoid treating an informal workaround as an agreed rule. These decisions shape the behaviour to be scoped; where policy, ownership or an exception is unclear, identify who needs to settle it with the supplier during discovery.

Specify the reports and views people need

Describe the information people need to find or monitor, and the decisions they make with it. Specify the question each view should answer rather than prescribing a particular reporting feature.

• Questions: What do staff need to find while doing the work—for example, which tasks are overdue or what is waiting for approval? What do managers need to monitor, such as available stock or work awaiting action?
• Users and timing: Who needs each view, and when do they use it: during a task, at a regular review or when a problem arises?
• Finding information: What should users be able to filter, search or sort by? Note the fields they use, such as owner, status, date or location, and any search terms they commonly know.
• Taking information elsewhere: Does someone need to export or share the results? Record who needs this, what they use the information for and any format or handling questions to resolve.
• Operational view or management summary: Separate screens that help staff complete individual tasks from summaries that show workload, delays or progress across the process.
• Definitions and examples: Explain what counts as complete, overdue or available. If the definition is disputed, mark it as an open question. Attach an existing spreadsheet or report if it shows the columns, calculations or decisions involved.

Use these notes to describe the outcome and information needed. Leave the supplier to discuss suitable ways to present it.

List connected systems and any data migration

List every system or information source the process relies on, even if staff currently bridge the gaps by copying details between them. You do not need to choose an integration method at this stage; record what needs to move and where the authoritative version lives.

• Systems and owners: What tools, shared folders, spreadsheets or supplier systems are involved? For each, note who owns the information and who can explain how it is accessed.
• Information exchanged: What needs to pass between the application and each system? Give an example, such as a customer reference, an order status or an approved request, and say which system should be treated as the source of truth.
• Timing and current handling: When does the information need to move: at a particular step, in batches or only when someone asks? Record whether a member of staff currently rekeys, emails or uploads it, and what errors or delays can result.
• Files and existing records: List relevant file types, imports, exports and records that may need to be brought across. Note what is known about missing, duplicated or inconsistent data; do not assume every old record must be migrated.
• Dependencies and open questions: Identify access that must be arranged, a system supplier or internal contact to involve, and any decision another team needs to make. If the connection or data quality is unclear, write down the question and who can help resolve it during discovery.

The number and nature of connections, and the condition of existing data, help shape what needs to be investigated and included in the scope.

Describe where and how staff will use it

Describe the conditions in which staff will use the application, not just the screens they may need. For each point, record an answer, a real example or an open question for the supplier.

• Browsers and devices: Which browsers and devices do staff use at work? Do they need the application on a phone or tablet, or only at a desk?
• Work locations: Where will people use it, and do they need access away from the workplace or while moving between tasks?
• Working conditions: Note anything that could make input or reading difficult, such as shared devices, gloves, noisy areas, poor connectivity or short periods of use. Give an example of what staff need to do in those conditions.
• Accessibility and usability: What needs are already known, and what makes the current process difficult to use? Ask staff who do the work, and record specific barriers rather than guessing at solutions. Use accessibility criteria as a reference point, not as a conclusion about which obligations apply to your application.
• Language and terminology: Do staff use particular terms, labels or languages? Note where an unfamiliar phrase or unclear instruction could lead to an error.
• Training and support: Which tasks will be unfamiliar? Record whether users need instructions, onboarding or help while completing those tasks, and who could provide that support.
• Open design questions: List any details that need testing or discussion during scoping. Leave choices about detailed interface design and any applicable obligations to be checked with the appropriate people.

Set operational expectations for discussion

Describe what the application’s day-to-day operation needs to support, and what the business would do if it were unavailable. Record current arrangements and questions for suppliers rather than assuming a particular service level or technical solution.

• Importance to the process: Which activities depend on the application, and what work would stop, be delayed or move back to spreadsheets, paper or email during an interruption? Note who would decide how to proceed.
• Availability and support: What availability does the process require, and when would staff need help? Ask suppliers what support arrangements are available, how issues are reported and who responds under each option.
• Backups and recovery: Ask how information is backed up and what would happen if records were lost or the application could not be used. Record any recovery expectations as requirements to discuss, not assumed capabilities.
• Maintenance and security: Who is responsible for routine maintenance, security-related decisions and communicating relevant changes? Note any internal policies or existing arrangements that suppliers should take into account.
• Business ownership: Name the role that will manage routine decisions after launch, administer staff access and report issues. Identify a deputy or an open question if ownership is not yet agreed.
• Dependencies: Record any existing supplier arrangements or internal teams that the application’s operation may depend on, such as those responsible for connected systems or staff accounts. Note who can confirm each dependency.
• Concerns to assess: For security or data protection concerns, write down the issue and the person responsible for assessing it. Leave formal assessment and technical options for the appropriate people and supplier discussion.

Mark each point as agreed, undecided or a question. This helps a supplier explain the operational choices and responsibilities relevant to your process.

Capture constraints, priorities and acceptance

Before a supplier estimates the work, make the conditions around the project explicit. Separate confirmed requirements from assumptions, and record who can resolve each open point.

• Dependencies and risks: Note other work, existing systems, internal approvals or decisions that could affect the application. For each, record who owns it, when it needs attention and what remains uncertain.
• Availability and operating constraints: Record when staff can take part in workshops, provide examples or review work. Flag busy periods or operational activities that need consideration, without treating them as a promised delivery date.
• Priorities: Mark each requirement as essential or useful. Add the business reason: for example, whether it is needed to complete a core process or would simply make a task easier. This helps the supplier discuss scope and trade-offs.
• Acceptance: Describe observable outcomes rather than broad labels such as “easy to use”. For example: “A team lead can find a submitted request, check its details and record an approval.” Add realistic examples or sample records where they clarify the expected result.
• Decision-makers: Name the people who can confirm the requirements and the person or group authorised to decide whether the agreed outcomes have been met. Check that they can review the relevant work when needed.
• Open decisions: Label anything still to be agreed, such as who owns a dependency, which need takes priority or what evidence will count as acceptance. Include the question to resolve and who should answer it, rather than presenting a working assumption as settled.

These notes give a supplier a clearer basis for discussing scope, risks and how completion will be judged, while keeping unresolved choices visible.

Bring the checklist together into a supplier brief

Turn the notes from the checklist into a short document that a prospective supplier can use to understand the need and prepare a useful discussion. Keep it practical: for each topic, provide an answer, a concrete example or an open question, and label it as confirmed, assumed or unresolved.

• Business outcome: What needs to improve, and how would staff recognise that it has improved?
• Current process: How is the work handled now? Include the main tools and any avoidable delays or rework.
• Users and permissions: Which groups will use the application, what will each do, and what information or actions should be restricted?
• Workflow and exceptions: Set out the usual sequence, owners and hand-offs, plus examples of cases that do not follow the usual route.
• Information and data sources: List the records and fields needed, where they come from, and any information that may need to be moved into the application.
• Rules and notifications: Note agreed decisions, status changes, approvals and messages, separating established rules from habits or questions.
• Reports and views: Name who needs each view and what they need to find out or do with it.
• Connections and migration: Identify the systems, files or spreadsheets involved, what information should move between them, and what is not yet known.
• Working conditions: Record where staff will use the application, on which devices, and any accessibility or support needs.
• Operational expectations: Describe how important the process is, what staff would do during disruption, and who will own the application internally.
• Constraints, priorities and acceptance: Include dependencies, what matters most, who will make decisions, and observable outcomes for deciding whether the agreed work is complete.

Attach helpful material, such as a process map, sample form or spreadsheet, when it clarifies the requirement and can be shared appropriately. Explain what it shows and flag any sensitive information that should not be circulated.

This brief is a starting point for supplier discussion, not a technical specification. You do not need to resolve every detail before speaking to a supplier; use the open questions to identify what needs further scoping. If the operational need is clear enough to explore a custom web application, request a project quote.

Check whether custom software is the right route

Before committing to custom development, use the checklist to compare the operational need with configurable products, low-code tools and the option of changing the process. Record what each route would need to cover, and where it would leave a gap.

• Essential: Which workflow steps, information, permissions or reports must work for the application to solve the problem? Note a concrete example for each.
• Flexible: Which steps could change to fit an existing product? Check whether a different hand-off, approval or way of recording information would be acceptable to the people doing the work.
• Workarounds: What would staff still have to manage in spreadsheets, email or another system? Decide whether those gaps are minor or would undermine the intended improvement.
• Process change: Is the difficulty caused by unclear ownership, inconsistent steps or approvals that may not be needed? Agree who can review those practices before treating software as the answer.
• Open questions: What remains unknown about options, fit or ongoing operation? Mark these for supplier discussion rather than assuming custom software will resolve them.

A configurable product may be the better fit if it covers the important needs without burdensome workarounds. Explore custom software when specific requirements remain unmet, and include maintenance and operational responsibilities in that comparison.