What a scope document does, and why the owner should write the first draft
A scope document is a plain description of what your software must do: who uses it, what they enter, which rules it follows, what it reports and how you will know it works. It becomes the basis of the quote, the contract and the final testing. Without one, the developer builds from memory of a meeting and you discover the gaps after paying.
You do not need technical knowledge to write a useful first draft. You need to know your own work, which you already do. The developer will turn your draft into technical specifications, ask questions and point out what is missing. This guide gives you an eight-step method and a sample outline you can copy. Allow time for it: a scope written in one evening usually misses the exceptions that cause trouble later.
Step 1: Map the process as it actually runs
Start by writing down how the work flows today, from the moment it begins to the moment it ends. Use plain sentences and number them. Follow one real job from start to finish rather than describing the ideal.
Take an illustrative appliance repair centre. A customer calls or walks in. The front desk writes a job sheet. A technician inspects the item and estimates the charge. The customer approves on the phone. Parts are issued from the store. The repair is done and tested. The customer is told the item is ready, pays and collects it. That is eight steps, and each one will become a screen, a status or a message in the software.
Then note the exceptions, because these are where software projects usually go wrong. What happens when the customer rejects the estimate? When a part is out of stock? When an item comes back under warranty? Write each exception as its own short paragraph.
Ask the person who does the work daily, not only the manager. The counter clerk knows the exceptions; the manager often knows the ideal.
Step 2: List every role and what each may do
Next, list who will use the system and what each person is allowed to see and change. This decides the logins, menus and permissions, and it is also your first security decision.
| Role | Can do | Cannot do |
|---|---|---|
| Front desk | Create job sheets, record customer approval, take payment | Change charges after approval, delete jobs |
| Technician | View assigned jobs, record findings and parts used, mark a repair complete | See the cash report or other technicians' jobs |
| Store keeper | Issue parts against a job, record purchases | Edit job charges |
| Manager | Approve discounts, reassign jobs, view branch reports | See other branches |
| Owner | View all branches and all reports | Usually not involved in daily entry |
Steps 3 to 5: Screens, reports and business rules
Step 3: Screens and fields
Collect every paper form, register page and spreadsheet your staff use now. Each one shows the fields the software must hold. Mark which fields are compulsory, which are picked from a list (such as item category) and which are calculated (such as total charge). Photographs of real filled-in forms, with personal details hidden, are more useful to a developer than a typed list.
Step 4: Reports and who reads them
For each report, write its name, who reads it, how often, which filters they need (date range, branch, technician) and whether it must be printed, exported to Excel or sent as a message. A report nobody can name a reader for is a candidate for a later phase.
Step 5: Business rules
Rules are the "if this, then that" of your work. Write each one as a single sentence. For example: a discount above the limit set by the owner needs manager approval; a job not collected within the owner's chosen number of days is flagged for follow-up; a part cannot be issued if stock is zero. Use your real limits in your own document; the point here is the format, not the numbers.
Steps 6 and 7: Data and integrations
Step 6: Data that comes in, is created and goes out
List the records that must be loaded before launch, such as customers, items, rates, opening stock or outstanding balances, and where they are now: an old program, Excel files or paper. Say who will clean them and by when. Then list what the software will create (job sheets, invoices) and what must leave it (exports for your accountant, backups). Data migration is often underestimated, so give it its own line in the scope.
Step 7: Integrations
Name every outside system the software must talk to and what passes between them. Typical examples are SMS or WhatsApp messages to customers, a payment gateway or UPI collection, biometric attendance devices, accounting software, an existing website or an online store. For each, state the direction of data and the trigger, such as "send a WhatsApp message when a job is marked ready". If you already hold accounts with these providers, note them, because the developer will need access.
Step 8: Acceptance criteria you can test on the day
Acceptance criteria are short, testable statements that tell both sides when a piece of work is finished. They turn vague hopes like "easy billing" into checks you can run. Write at least one for each important screen, rule and report.
- A front desk user can create a job sheet with customer name, mobile number, item and fault, and print it on the shop's existing printer.
- When the manager approves a discount above the owner's limit, the approval and the manager's name are recorded against the job.
- The daily collection report for a branch matches the total of that day's receipts for the same branch.
- A user from one branch cannot open job sheets belonging to another branch.
Agree that payments linked to testing milestones depend on these criteria being met, and run them yourself with real examples before signing off.
A sample scope outline you can copy
The table below is an outline for a typical scope document. How much you write under each heading depends on the project; a small system may fit on a few pages, a larger one will need more.
| Section | What to write |
|---|---|
| 1. Background | Who you are, what the software is for, how many branches and users |
| 2. Goals | Three to five outcomes, for example "know the status of every job without phoning the technician" |
| 3. Process map | Numbered steps for the main flow, plus each exception |
| 4. Roles and permissions | The role table from Step 2 |
| 5. Screens and fields | List of screens with sample forms attached |
| 6. Reports | Name, reader, frequency, filters and format |
| 7. Business rules | One sentence per rule |
| 8. Data | What is migrated, from where, and who cleans it |
| 9. Integrations | Each outside system, direction of data and trigger |
| 10. Acceptance criteria | Testable statements grouped by module |
| 11. Phases | What goes in phase one and what waits |
| 12. Out of scope | Anything discussed but deliberately excluded |
The out-of-scope section is easy to skip, but it prevents arguments later. If a mobile app or customer portal was discussed and postponed, saying so in writing protects both sides.
Deciding what goes in phase one
Most first drafts are too large. Sort each item into three groups: must have for launch, should have soon after, and can wait. Phase one should contain only what your staff need to stop using the old method for the core work. Reports that are nice to see, extra apps and rare exceptions can usually follow once people are using the system and you can see what they actually ask for.
A smaller first phase also gives you a firmer price and an earlier date, which helps when you are comparing quotes. Our guide to what drives software development cost explains how each part of the scope shows up in a quotation.
How MATROP works from your scope
At MATROP PRIVATE LIMITED, a custom software project begins with requirement analysis. We go through your draft, forms and registers to understand the workflow, the pain points and the goals, and we suggest phases and a roadmap. Screen design comes next, and development is shown in module-wise demos so you can test against your acceptance criteria as the work progresses.
You may not need a full scope if your work matches a ready product. A pharmacy or a school, for instance, can usually start by comparing a product such as our pharmacy management software against its own registers and listing only the gaps. If you have a draft scope, or just a set of photographed forms, you can share it with us for a first conversation.
Questions people ask
How long should a software scope document be?
Long enough that someone who has never seen your office could understand the process, roles, reports and rules. For a small system that may be a few pages plus sample forms; covering the exceptions matters more than page count.
Can we write the scope in Hindi, or mix Hindi and English?
Yes. Clarity matters more than language. Write in the language your staff use for the work, and agree with the developer which language the final signed version will be in.
What if our process changes after the scope is agreed?
Record the change in writing, ask the developer how it affects cost and dates, and approve it before work on it starts. Small changes are normal; unrecorded ones cause disputes.
Should the developer charge for helping write the scope?
Some companies include requirement analysis in the project and some charge for it separately. Either is reasonable if it is stated upfront and you receive the written result.
