Software project scope checklist

Direct answer

A software scope is settled when it says what is out as clearly as what is in. Use this checklist on the written scope a vendor sends you, whoever the vendor is. For each area below, the scope should give a specific answer you could test later. Where it gives a phrase such as 'standard features' or 'necessary integrations', ask for the list behind the phrase.

This is a review tool for the document, not a request document. If you are still deciding what to ask vendors for, the RFP template covers that step, and this page begins when a scope is already on the table.

1. Users and roles

Every screen and rule depends on who is using it. Confirm the scope names them.

• Each type of user, in the words your business uses
• What each role can see, create, change and delete
• Who administers users and how access is granted or removed
• Whether any users are outside your company, such as customers or partners

2. Core tasks

The scope should describe what users do, in sequence, not just a list of pages. If a task is not written down, assume it is not included.

• The main user flows from start to finish
• The states a record moves through, and what triggers each change
• Documents, emails or notifications the system produces
• Search, filtering and reporting people will rely on

3. Data and sources

Data is where hidden work lives. Confirm what the system stores and where it comes from.

• The main records and the fields on each
• Whether existing data must be imported, from where, and who cleans it
• Who is responsible for data quality before and after import
• Retention, export and deletion expectations

4. Integrations

Each connection to another system is a small project of its own. The scope should list them individually, with direction and purpose.

• Each system, and whether data flows in, out or both
• Who provides access and test accounts (see [web application access requirements](/web-application-access-requirements/))
• What happens when the other system is unavailable
• Who owns any third-party account and its billing

5. Exclusions

This is the section that separates a settled scope from a hopeful one. A good scope lists things a reasonable buyer might assume are included and states they are not, or that they are a later phase.

• Features deliberately left for a later release
• Platforms or devices not supported in the first version
• Content, data preparation or training the vendor is not doing
• Ongoing support, hosting or maintenance if they are not part of this scope

6. Acceptance criteria

Ask how you will decide the work is finished. Acceptance should be checkable: named scenarios, named roles, real data. The acceptance testing checklist shows how to run it.

• Criteria written per feature or flow, not as a general statement
• Who on your side signs off, and how defects are recorded
• What counts as a defect versus a change request
• What happens between the vendor fixing a defect and your re-test

7. Ownership

The scope should say what you own at the end and how it gets to you. Confirm the details in writing and with a lawyer; this page does not provide legal wording.

• Source code delivered to a repository in your control
• Hosting, cloud, domain and service accounts in your name
• Documentation and a handover session
• Which third-party components have their own licences

8. Change rules

Every project changes. What protects you is an agreed way to handle it, written before the first change arrives.

• How a change is requested and who approves it on each side
• How its effect on price and timeline is stated before work begins
• How you can pause, reprioritise or drop items
• What happens to unfinished work if the project stops

Using the checklist

Mark each area as clear, partly clear or missing, and send the partly clear and missing ones back to the vendor as questions. A vendor who answers precisely is telling you how they will behave once work starts. A vendor who resists putting things in writing is telling you something too.

LATYNEX agrees one scope and one price in writing before work starts, and hands over code, domain and accounts in your name. If you have a scope to review or would like us to write one, start from web application development. For internal software specifically, see internal business tools.