Requirements Definition Cost and Outsourcing Guide for SMBs

Requirements definition is the stage before building a system where you clarify what the system is for, who will use it and what it must do, so that you and the development company share the same picture of the finished product. In short, when outsourcing requirements definition, commonly seen market guidelines are tens of thousands to around 1 million yen for small projects, roughly 1 million to a few million yen for mid-sized ones, and several million yen or more for large ones, often about 10-20% of the total development cost. The contract is usually a quasi-mandate (jun-inin) contract, paid for the work performed, rather than a contract for work that promises completion.

You can also order requirements definition on its own, as a separate contract from development. This split ordering leaves you with a requirements document you own, lets you request quotes from several companies on the same conditions, and makes it easier to right-size the development budget or change vendors. This article is written for executives and non-IT staff of Japanese small and mid-sized businesses. It covers cost ranges, the pros and cons of split ordering, why quasi-mandate contracts are common, what the deliverable should contain, typical durations, what you should prepare and which internal roles you need, common failures, how to spot a good partner, a pre-order checklist and an FAQ. All amounts and periods are rough guidelines commonly seen in the market and vary widely by vendor, project and team structure.

System development broadly runs from requirements definition to design, development, testing, and then rollout and operation. Requirements definition is the first of these, the upstream stage, where the conditions the system must meet are decided and written down. Requirements come in two kinds. Functional requirements describe what the system must be able to do (for example, output a quotation as a PDF, or send a notice when stock falls below a set number). Non-functional requirements describe how well it must run (for example, how many people can use it at once, how long it may be down, and how strict security must be).

This stage matters because gaps and misunderstandings here come back as rework many times larger in later stages. If you learn during development that approval flows actually differ by department, screens and data structures may have to be rebuilt. It is generally said that the later a problem is found, the more it costs to fix, which is why it pays to give the first stage proper time and budget. A related term is the RFP (request for proposal), a document for asking vendors to propose; requirements definition is the process of firming up its contents in more detail. See RFP and requirements basics for how the two relate.

One more point: requirements definition is not simply listening to what the buyer wants. It is organizing business problems and deciding together the scope the system should solve. Lining up every request raised in interviews pushes up cost and buries what is truly needed. Deciding what to build and what not to build is itself the value of this stage.

The cost depends on how broad the target business is, how many departments and external systems are involved, and how many meetings are needed. The table below shows rough ranges commonly seen in Japanese contract development, by development budget. They are not any specific company's prices or guarantees, and actual figures can fall outside these ranges depending on how organized your data is and on the size of the vendor.

As a share of the total, 10-20% of development cost is one guideline for small projects, but the share tends to shrink as projects grow. Larger projects cost more to define in absolute terms, yet development and operations costs grow by far more. Put another way, a requirements definition costing several hundred thousand yen on a development of a few million yen is neither especially high nor low. For the wider picture of development costs, see the system development cost guide.

Fees are most often built up from person-months or person-days: the number of consultants or engineers multiplied by days and a unit rate. When you receive a quote, check not only the total but also who will work at what level of involvement, how many meetings are assumed, and what the deliverables are.

Even for the same requirements definition, quotes can differ several times over. The main reasons are as follows.

- Breadth of the target process: one task, or the whole flow from order to invoice
- Number of stakeholders: more departments and people mean more coordination time
- Integration with existing systems and external services: each one needs its specifications confirmed
- State of current-process documentation: written down, or only in people's heads
- Strictness of non-functional requirements: personal data, payments, a process that cannot stop
- Level of detail in the deliverable: down to screen mock-ups, or only a feature list
- Speed of buyer decisions: slow confirmations and approvals stretch the schedule and the cost

Of these, the ones a buyer can most easily influence are the state of process documentation and decision speed. Simply jotting down the current workflow, collecting sample forms and screens, and having the decision-maker attend meetings can visibly reduce the effort needed. These points are covered below in the section on what you should prepare.

System development is often ordered from requirements to delivery from a single company, but you can instead sign a separate contract for requirements definition first. This is called split ordering. For example, you ask a specialist firm, or a team separate from the developers, to do requirements definition, then ask several development companies for quotes based on the resulting document.

The biggest advantage of split ordering is that you keep the requirements document as your own asset. With requirements fixed in writing, you can request quotes from several companies on identical conditions and compare prices and proposals. It also acts as a safety valve: if you find at this stage that the budget will not stretch, you can review the scope before committing to development.

There are cautions too. Because requirements definition is paid for separately, small projects can end up more expensive. If the document is of low quality, developers cannot read it properly and the discussions start over. And if the requirements firm and the developer differ, requirements that are hard to realize technically may remain in the specification and be flagged later by the developer. To avoid this, confirm that the requirements staff can judge technical feasibility, and that the contract leaves the copyright and usage rights of the document with you.

As a rule of thumb, if the development is a few million yen and the specifications are clear, a single order is often less effort and cost. If it is in the tens of millions of yen, many departments are involved and opinions are divided internally, or you simply cannot gauge the going rate, split ordering is worth considering. If you choose a method such as agile development that does not lock requirements down tightly, the role of requirements definition changes; see the agile development ordering guide.

Requirements definition is usually contracted as a quasi-mandate (jun-inin) contract. This pays for the performance of expert work itself, not for completion of a deliverable. A contract for work (ukeoi), by contrast, promises delivery of a finished result, and pay is not due (or is reduced) if it is not completed.

The reason requirements definition tends to be quasi-mandate is that "completion" is hard to define objectively. In design or development you can judge completion by whether the system works as specified. In requirements definition, new issues surface as interviews proceed, and content changes with the buyer's decisions. It is hard to decide in advance at what point all requirements have emerged, and under a contract for work the vendor must price in a buffer for unexpected changes. Paying for the way of working and the period is more realistic for both sides.

From the buyer's side, no guarantee of completion can feel uneasy. What helps is to specify the process and deliverables as concretely as possible in the contract or work plan: the number and frequency of meetings, how reports are made, the table of contents of the final requirements document, how acceptance is checked, and the maximum period with how extensions are agreed. Even under quasi-mandate, writing these down gives you ample control. For general contract thinking, see development contract basics.

Duration depends on size and on how long coordination among your stakeholders takes. Commonly seen guidelines are 2-6 weeks for small projects, 1-3 months for medium ones, and 3-6 months or more for large ones. If it runs too long, business conditions can change while you are still deliberating, so for periods over a few months consider deciding in phases. The rough flow is as follows.

1. Understand the current state: organize today's workflow, forms and systems in use, and pain points
2. Clarify problems and purpose: put into words what to solve and why now
3. Gather requests: collect requests from departments and list candidate functions, data and screens
4. Prioritize and set scope: sort into must-have, nice-to-have and not-this-time
5. Document the requirements: compile functional and non-functional requirements and constraints
6. Review and agree: stakeholders check the content and the decision-maker approves
7. Check rough estimate and plan: confirm the expected cost, schedule and team from the requirements

What matters is not to aim for a finished version suddenly between steps 5 and 6, but to share drafts early and go back and forth several times. Seeing a feature list and workflow drafts in stages lets you notice misalignment sooner than waiting for a thick document.

The deliverable is a document called the requirements document. Formats differ by company, but for SMB projects the minimum content you should expect is shown below. To avoid not knowing what will be delivered, confirm at the quotation stage how far the documents go.

More pages are not necessarily better. What matters is whether the wording leaves no room for different readings. Phrases such as "easy-to-use screens" or "fast operation" mean different things to different people. Check whether things are written in a verifiable way, such as "order entry takes within 3 minutes per order" or "search results appear within 3 seconds".

Also confirm rights over the deliverable. If it is unclear who holds the copyright or usage rights of the document, or whether you may hand it to other developers for quotes, the benefit of split ordering is lost. It is safest to state in the contract that the buyer can freely use the requirements document.

The quality of requirements definition depends not only on the outside experts' skill but heavily on the buyer's preparation. Experts do not know your business. If the necessary material does not come from your side, interviews drag on and cost and time increase. Preparing the following before you ask makes things smoother.

- Write purpose and problem in one sentence: what to improve, by how much and by when, with figures if possible
- Note down the current workflow: a neat diagram is not needed, just who does what
- Collect forms, spreadsheets and screens actually in use: samples convey far more than explanations in words
- Gather problems and requests from stakeholders in advance: requests that appear later raise cost
- Decide the budget ceiling and desired timing: without them, realistic proposals are hard to make
- Prepare a list of existing systems and subscribed services: needed to consider integration and migration
- Decide the decision-maker and meeting contact: make clear from the start who has the final say

You do not need to prepare perfectly. It is more important to honestly say "this much is decided, beyond this it is not". Hiding undecided parts or leaving them vague becomes a cause of extra cost and rework later.

Even when outsourced, requirements definition cannot be fully handed off. The buyer knows the business best, draws out that knowledge and makes the final decisions. The development company's role is to ask, organize, document and propose how to realize it, not to decide what is right for your business.

- Decision-maker: sets purpose and budget, makes final calls on scope and priority, and attends key meetings
- Project contact: single point of communication with outside parties, consolidates internal opinions and answers by deadlines; expect several hours to days per week
- Field staff: explain how work really runs and review screen and form drafts, reflecting the voices of real users
- IT staff (if any): confirm existing systems and security conditions; otherwise the project contact covers this
- Finance, administration and other departments: confirm surrounding rules such as invoicing, approvals and access rights

Securing the project contact is especially important. During requirements definition there are several meetings a week, documents to review and internal checks. If that person is double-booked with little time, the schedule slips and cost eventually rises. When choosing the contact, consider freeing up time, for example by shifting part of their regular duties to others. If a dedicated person is hard to assign, an outside IT consultant can support the contact role.

The most common is ending as a list of wishes. In interviews, field staff keep saying "it would be handy if it could do that too". Absorbing all of it makes budget and schedule limitless. The skill in requirements definition is sorting requests against the purpose. Ask the partner to sort them by three questions: is it needed in the first release, can it wait for later releases, and is it something a system should solve at all?

For failures common across system development as a whole, see system development failure patterns. For projects with large technical uncertainty, a PoC (proof of concept) that tests on a small scale can be run alongside; see PoC cost and how to run it.

Judge a partner not by size or fame but by how they work. In quotes and the first meeting, check the following.

- They ask why you want it and what troubles you today before asking what you want built
- They do not accept requests as they are, and propose prioritization and decisions not to do things
- They explain in plain words you can understand, without jargon
- They show a sample requirements document or an example table of contents
- They can explain the quote breakdown (who, how many days, which work) and state assumptions
- They tell you early about technically difficult points and risks
- They state that the requirements document belongs to you and that you may hand it to others for quotes
- They explain in advance when extra work outside the contract arises and how it is priced
- They understand the business well and have experience with companies of similar industry and size

Be wary, on the other hand, of firms that say requirements definition is free if you leave development to them and then quote development while the requirements are still unclear, or that cannot explain the basis of their quote. Free or very cheap requirements definition is not necessarily bad, but check whether the cost is added to development fees and whether conditions make it hard to switch vendors. For how to compare several companies, see also RFP and requirements basics.

Check the following before requesting requirements definition. You need not answer yes to everything, but the items you cannot answer are likely to cause trouble later.

- You can state the problem and purpose in one sentence
- You can show the current workflow with notes or sample forms
- You have decided a budget ceiling and desired timing
- You have considered ordering requirements as a package or split
- You understand the contract type (quasi-mandate or work) and how cost is set
- You have confirmed what the deliverable includes and how acceptance works
- You have confirmed in the contract that the buyer holds rights to the document
- A decision-maker and a contact are named and can set aside meeting time
- Field staff can take part in reviews
- You have confirmed the maximum period and what happens if an extension is needed
- You are ready to decide what will not be done this time