I am not technical. Do I really have to write the requirements document myself?

What you are writing is not a technical specification. It is a set of business rules, and that part only you can write. A development team can translate "members upgrade once they pass a spending threshold" into database structure and program logic, but it cannot decide for you how the threshold is calculated, what happens on a downgrade, or whether a return claws the progress back. So the sensible division of labor is this: you describe how things work today, how you want them to work, and what must never be allowed to happen; the development side turns that into a workable design. Text, tables, hand-drawn flows, or annotated screenshots are all fine. No technical format is required.

How detailed does a requirements document need to be?

The test is whether two people reading it would come away understanding the same scenario differently. If you write "orders can be canceled," the development team may read that as cancelable in any state, while you meant only before dispatch — that is not detailed enough. The sufficient version states the states and conditions: cancelable by the customer before payment, handled by support before dispatch, and routed through the returns process after dispatch. Conversely, where a button sits and what color it is usually does not belong in a requirements document. That belongs to the design phase.

If we change our minds halfway through development, does that always cost more time and money?

Not necessarily, but it depends what is changing and when. The same change raised during the requirements phase might mean editing a few lines of text; raised during design it means redrawing layouts; raised late in development it can ripple through the data structure and features already completed. The costs are very different. The workable approach is to agree a change process up front: every change is first assessed for its impact and its effect on the schedule, and work starts only once both sides have confirmed it. Nothing is added verbally. If you are working in two-week sprints, new requirements can also be scheduled into a later cycle rather than interrupting work already in progress.

How to Write Software Requirements: A Template

“I explained my idea to the vendor, so why is what they built not what I wanted?” The answer to that question is usually not on their side. It is that the two of you understood the same sentence differently, and nobody noticed.

A requirements document is not a technical specification written for engineers. Its job is to align the picture in each side’s head. You do not need technical knowledge to write one, because the part you genuinely have to supply is the business rules, and only you know those.

What a requirements document should contain

One: goals and success conditions

Start with why you are doing this, not with which features you want.

Weak version: I want a membership system. Strong version: I want to know which customers have not come back in over three months, and to be able to message only those people. Right now that means digging through shipping records by hand, and even doing it once a month is a strain.

The benefit of stating the goal clearly is that the development side gets the chance to propose a simpler approach you had not thought of. Describe only the feature and all they can do is build exactly that.

Success conditions are the basis for acceptance — once it is live, what counts as having achieved the goal? This section is worth extra time, because it doubles as your acceptance criteria; for how that works, see the Guide to Software Acceptance Testing and UAT.

Two: users and roles

List every kind of person who will use the system, and what each of them can and cannot do.

Role	Main responsibilities	Should not be able to
Customer	Place orders, view their own records	See anyone else’s data
Store staff	Create orders, look up members	Change amounts, export lists
Manager	Approve, view reports	—
System administrator	Manage accounts and permissions	—

This table tends to raise questions the moment you start filling it in. Does a store manager count as a manager here? Can a part-time employee look up a member’s phone number? The sooner those disputes surface, the better.

Three: core flows

Describe what happens from start to finish in the simplest possible way, one step per line:

The customer selects a product on the website and adds it to the cart
At checkout they choose a payment method
Once payment succeeds, the system sends an order confirmation email
Store staff see the new order in the admin system and confirm stock
After dispatch they enter the tracking number and the system notifies the customer

With the flow written out, go back through each step and ask what happens if it fails. That is the next section.

Four: screens and fields

These do not have to look good. What matters is the rule attached to each field:

Is this field required or optional?
Is there a format constraint (mobile number, unified business number — the tax identifier issued to companies in Taiwan — date)?
Are there length limits or minimum and maximum values?
What message appears when it is filled in incorrectly?
Can it still be edited after submission?

Unclear field rules are the single most common source of disputes after launch. A hand-drawn sketch with annotations, or a screenshot of an existing system marked up with what should change, communicates far better than prose alone.

Five: business rules

This is the most valuable section of the whole document, and the one nobody outside your business can write for you. Anything of the form “under these conditions, calculate it this way” belongs here:

Can discounts and promotions be combined? In what order?
Under what conditions does an automatic upgrade happen? How are downgrades handled?
Whose orders require approval? Above what amount does a manager have to sign off (you define the threshold)?
When stock is insufficient, is the order blocked or is a pre-order allowed?

The trick to writing rules is this: every rule must be resolvable as true or false. “Important customers get priority” cannot be executed. “Customers tagged VIP have their orders sorted to the top of the list” can.

Six: edge cases

Everyone can picture the happy path. What separates a good system from a bad one is what happens when something goes wrong. Think through at least:

Payment fails; payment succeeds but no notification arrives
Two people edit the same record at the same time
The network drops; a third-party service does not respond
Duplicate data (the same person signs up twice by different methods)
Needing to step back, or to reverse an action that has already completed

Seven: non-functional requirements

Not features, but conditions that seriously affect both cost and experience:

Performance. How many people will use it at once? When are the peaks?
Compatibility. Which devices and browsers must be supported? Are there legacy environments you cannot drop?
Security and permissions. Which data counts as personal data? Who may export it? Should actions be logged?
Availability. How much downtime is acceptable? How often are backups taken, and how is a restore performed?
Language. Do you need multiple languages? Might you add them later?

Multilingual support and permissions are the textbook examples of things that cost far more to add later than to build in from the start. Settle both during the requirements phase.

The five things most often left out

One: where the data comes from. When the new system goes live, does the old data move across? In what format? Who cleans it up? Data migration is frequently the most time-consuming part of an entire project and the least often written into requirements.

Two: who maintains the content. After launch, who edits the copy, who lists new products, who adjusts the rules? Without an admin interface, every change means going back to the vendor.

Three: who receives notifications. For emails and messages triggered by system events, list the recipients, the content, and the timing — including the cases where nothing should be sent.

Four: what the reports need to show. If reporting requirements are not raised early, the database may never have stored the relevant fields, and retrofitting them means redoing the work.

Five: what you receive at handover. Source code, design files, deployment and maintenance documentation, account credentials. NETVANA transfers all of those in full once the project fees are settled, but in any engagement this should be written down in black and white; for the checkpoints involved, see How to Choose a Software Development Company.

A table of contents you can copy directly

If you do not know where to begin, work down this structure and fill in what you can. Where you cannot, mark it “to be confirmed” — the marker is itself useful information:

Who we are and how we operate today
What problem this project solves, and what success looks like
User roles and permissions at a glance
Core flows (one step per line, with the role responsible for each)
Screen inventory and the rules for every field
Business rules (each one resolvable as true or false)
Edge cases and error handling
External systems and services requiring integration
Scope of legacy data migration
Non-functional requirements (performance, compatibility, security, backups, language)
Open questions and known risks

Item eight deserves particular attention. Anything that exchanges data with an existing system depends on how open that system is, which is usually outside your control, so the earlier it is clarified the better; for the risks involved, see the Guide to System Integration and API Development.

Small habits that make the document immediately more useful

Replace adjectives with concrete examples. Instead of “the interface should be clean,” write “this page must be operable in no more than three steps.”
Attach screenshots of how things are now. An annotated screen from your current system or a competitor communicates far more efficiently than a paragraph of description.
Write down what you are not doing. Explicitly listing the features excluded from this phase saves an enormous amount of argument later.
Mark priorities. Three levels — essential, important, nice to have. When budget or schedule gets squeezed, that is what tells you what to cut.

How requirements relate to quotes

When quotes vary widely, the reason is usually not that the vendors differ. It is that each of them saw a different scope. A vague set of requirements can only produce quotes that are each vendor’s own guess. A clear set is what makes comparison possible at all.

To get comparable quotes, organize your requirements into a single list, ask every vendor to respond against that same list item by item, and require them to state explicitly what is excluded. For the cost structure and what to watch for, see How Website Costs Are Calculated.

The other common situation is rushing to start a project before the requirements have settled. Here the pragmatic choice is not to force out a document pretending to be complete, but to narrow the scope, build a first version, and let real usage fill in the rest — see the Guide to MVP Development for how.

Change management: requirements will change, so decide how

Requirements changing during development is normal. The real problem is changes that go unrecorded and unassessed. Agree three things when the project opens:

Changes are submitted in writing. Verbal additions do not count.
Changes are assessed before they start. Which completed features they touch, how much time they add, and how they are priced — work begins only once both sides have confirmed it.
Changes have a place to land. Non-urgent requests are scheduled into a later cycle rather than interrupting work in progress. NETVANA works in two-week sprints, ending each cycle with a working demo, and new requirements normally go into the following cycle.

Most of the reasons projects run long trace back to changes that were never managed; for more scenarios, see Why Software Projects Run Late.

A requirements document is not a formality. It is a tool for exposing the gap between what you assume and what the other side assumes, early. Writing it will always surface things you had not fully thought through yourself — which is exactly where its value lies.

If you have an initial idea but do not know how to shape it into something that can be quoted, talk to NETVANA about your project. Our requirements discovery phase helps turn rough thinking into a first draft of a written specification; for what each service includes and delivers, see the software services overview.

Further reading: for choosing a partner once the requirements are written, see How to Choose a Software Development Company. If you want to start moving before the requirements have settled, see the Guide to MVP Development. And to understand how to run acceptance once the work is delivered, see the Guide to Software Acceptance Testing and UAT. For the decision that follows a finished requirements doc, see Outsourcing or Building an In-House Team; and for writing accessibility into the requirements up front, see A Web Accessibility Guide for Businesses. For how much detail the contract model demands up front, see Fixed Price or Agile: Choosing a Contract Model. Once requirements are written, the next step is decoding what vendors quote back, see How to Read a Software Quotation. Requirements are only part of it, see what else clients should prepare before kickoff, see Software Project Kickoff Preparation.