A One-Page Custom Software Requirements Brief for Philippine SMEs

An SME can describe its software idea in one sentence and still receive three very different quotations. “We need an inventory system” leaves open how stock arrives, who can adjust it, what happens at another branch, and which reports must agree at day’s end. We use a one-page brief to make those decisions visible before discussing screens or a development estimate. A Biñan retailer replacing a shared spreadsheet can complete the same exercise as a warehouse or service company.

Start with the business event, not a feature list

Write one problem that a manager can verify. For example: “At closing, the branch manager cannot tell whether the quantity in the spreadsheet includes today’s returns.” Name the person who owns the answer, the current workaround, and the cost of ambiguity in operational terms. You need not invent a peso loss. “Two people reconcile the file every evening” is enough if that describes your actual work.

Then define one observable improvement: “The manager can see stock by branch, and every adjustment has a reason and approver.” That is more useful than “easy to use.” Atlassian’s product requirements template likewise asks teams to record objectives, success measures, assumptions, scope, and open questions. Your brief can be much shorter, but those decisions still matter.

Trace one transaction from start to finish

Choose a real transaction that exposes the hard parts of the process. A delivery arrives in Laguna. A receiving clerk checks quantities, records a short shipment, and saves the supplier document. A manager approves an adjustment. The item appears as available stock only after the agreed step. Later, one unit sells at the second branch. Which record changes, and who may reverse the sale?

Describe the normal path and one exception. Software estimates often diverge at exceptions: partial deliveries, cancelled orders, missing barcodes, duplicated entries, and an internet connection that drops during checkout. If the answer is “staff write it down and enter it later,” identify who reconciles those entries and how the system prevents a second deduction. You are specifying a business rule, not a particular technical architecture.

For each step, note the actor, input, approval, output, and proof. “Manager approves stock adjustment; system records the previous quantity, new quantity, reason, and approver” can become both a screen requirement and an acceptance test. A mockup may clarify the flow, but a drawing alone cannot define the rule.

List dependencies that change the scope

Include the people and systems around the proposed application. Will clerks, branch managers, accountants, and owners see different records? Is there a current POS, spreadsheet, payroll tool, or accounting package? Identify its vendor and export format if known. Do not assume that another product has an available API or that an integration is included in a base quote.

Count the starting records: products, customers, suppliers, staff, branches, and historical transactions. Decide which history must be searchable on launch day and which can remain in an archive. A “data migration” line without a source file, cleaning owner, and sample verification invites different interpretations. The same is true for offline use: specify whether staff must create transactions offline, merely view cached information, or wait until service returns.

Ask who provides devices, hosting, backups, credentials, and training time. These may be delivered by different parties. If you need a printed report or an exported file for a third party, attach a sample with sensitive details removed. A sample reveals columns and calculations that a phrase like “monthly report” cannot.

Copy this one-page brief

Use the following as a working document. Keep unknowns explicit; a vendor can then price discovery rather than guess.

Field	Your answer
Business owner and contact	Name, role, decision maker
Problem and present workaround	One sentence each
Launch outcome	What a user can do or verify
Core workflow	Trigger → entry → review → exception → close
User roles and permissions	Who views, enters, approves, exports
Current records and migration	Sources, approximate volume, cleaning owner
Integrations and devices	Vendor, version, export/API status, locations
Connectivity rule	What must work during an outage; how to reconcile
Required outputs	Sample reports, alerts, exports
Launch essentials	Items required for the first usable release
Later phase	Useful items that can wait
Acceptance evidence	Transactions and reports that must pass
Handover	Access, documentation, training, code ownership, support
Open questions	Who will resolve each one, and by when

Keep the brief to a page by linking to sample files or diagrams instead of squeezing every rule into a cell. Remove employee and customer identifiers from any examples sent to a vendor.

Ask vendors to quote against the same test

Send the same brief and attachments to each shortlisted developer. Request a breakdown for discovery, build, integration, migration, testing, launch, training, and support. Ask each to mark assumptions, exclusions, third-party costs, and what would trigger a change request. A low initial total means little if it leaves data cleanup and approval rules unresolved.

Use one sample acceptance scenario across proposals: receive ten units at Branch A, transfer two to Branch B, sell one there, refund it, and compare the branch quantities and exported report. State who witnesses the test and what counts as a pass. The numbers are illustrative; replace them with your own transaction types. Also request the format and timing of documentation, admin access, and source-code handover. Our custom software service includes requirements discovery and handover planning, but the precise deliverables belong in the signed scope.

You do not need a perfect specification before contacting a developer. You need a brief that exposes the next decisions. If you have completed the table, send it with your request and we can discuss which workflow to scope first.