Is there a fixed format for a government information system requirements specification?
Key takeaway
There is currently no single requirements specification format that can be applied directly to every government agency and every information system project. Each agency still decides the actual content according to its own rules, procurement method, the nature of the system, and the project's needs.
The real problem a requirements specification has to solve is not “which template to use” but this:
Is this document already clear enough for the agency and the development vendor to build a shared understanding of the project scope?
Take the current Guidelines for Information System Development and Maintenance of the Water Resources Agency, Ministry of Economic Affairs, and its subordinate bodies as an example. It divides information system development and maintenance into eight lifecycle stages, system evaluation, requirements and system analysis, system design, programming, system testing, training, go-live, and maintenance, and provides reference formats for the requirements specification, requirements interview records, design specification, test plan, and test report. The guidelines were last revised on August 21, 2024.
But these are the management rules of the Water Resources Agency and its subordinate bodies. They cannot be written up as a format or process that every government agency must adopt.
What is worth borrowing is the logic behind them:
Requirements are not an isolated tender document. They are the starting point for the design, development, testing, and go-live that follow.
Why can't requirements start from a feature list?
Key takeaway
“Case management,” “online applications,” and “member management” only say roughly what the system should have. They are not enough to define the real development scope.
Suppose the requirements specification says only “build an online application feature.” From a business perspective, the requirement seems clear. From a system development perspective, many questions still have no answer:
- Does the applicant need to log in?
- How is identity verified?
- Which data and attachments must be provided?
- Who receives the case after submission?
- Is supervisor approval required?
- When data is wrong, is the case rejected or returned for correction?
- After correction, which step does it return to?
- Can the applicant check progress?
- How is the result communicated?
- Which statistics and reports do case officers need?
None of this changes the feature name “online application,” yet it can make an enormous difference to the development scope.
So requirements should not only ask “which features does the system need?” They should ask: who, in what situation, needs to complete what work through the system, and what result follows?
For example, instead of writing only “the system shall provide case enquiry,” describe it further: after logging in, a case officer can search the cases of their own unit by case number, applicant, application date, and case status, and view the basic case data and processing history.
Only then can the development team identify login, role permissions, conditional search, case data, and history records as the things that actually need to be built.
What should a government information system requirements specification confirm first?
Key takeaway
Government information system requirements can be confirmed across eight areas, purpose, roles, processes, features, data, integration, non-functional requirements, and acceptance, with the emphasis on defining the system boundary clearly rather than on the number of features.
Projects differ in scale and demands, but from a development standpoint the following eight areas can at least be checked first.
1. Project purpose
Why is this system needed? What problems does the current way of working run into? What should improve after it is built?
For example, the real need may not be “a case management system” but that cases are currently scattered across email, Excel, and paper, making cross-unit enquiries difficult and progress impossible to track.
2. Users and roles
Who will use the system? Citizens, case officers, supervisors, system administrators, or other agencies, and what does each need to accomplish? Which data can each role see, edit, and process?
3. Business processes
Which steps does a piece of work pass through from start to finish? Beyond the normal path, which exceptions exist, such as rejection, correction, cancellation, resubmission, or cross-unit handling?
4. Functional requirements
Which operations does each role need to perform through the system? Features should connect back to the actual process wherever possible rather than being listed as names on their own.
5. Data requirements
Which data does the system need to create, search, keep, import, export, or exchange? Does existing data need to be migrated into the new system?
6. System integration
Does it need to connect to existing accounts, databases, other government information systems, or third-party APIs? Who provides the data, and how is it exchanged?
7. Non-functional and security requirements
Beyond “what it does,” consider usage volume, performance, compatibility, permissions, security, and the applicable cybersecurity requirements.
8. Testing and acceptance
Once each important feature is done, how will it be confirmed against the original requirement? Which conditions mean the system can be formally delivered?
| Area | Questions to ask first |
|---|---|
| Project purpose | Why build this system? What is the biggest problem today? |
| Users | Which roles exist, and what can each role do? |
| Processes | How does a piece of work move from start to finish? |
| Features | Which system operations does each process need? |
| Data | Where does the data come from? What must be kept or migrated? |
| Integration | Does it need to connect to existing systems, accounts, or APIs? |
| Constraints | What existing environment, security, performance, or compatibility requirements apply? |
| Acceptance | How will it be proven that the requirements were actually met? |
These eight items are not fixed chapters that every government project must use by law. They are a planning aid for confirming whether the development requirements already form a complete system boundary.
How detailed should functional requirements be?
Key takeaway
Functional requirements should be detailed enough for a vendor to understand the usage scenarios and development scope, but that does not mean every UI, technical architecture, and implementation method has to be specified when there is no need to.
Writing only “the system provides permission management,” for example, still makes the real workload hard to estimate. Expand it to: ordinary case officers can only search and process cases in their own unit; unit supervisors can view their unit's cases and perform designated approvals; system administrators can manage accounts and system settings. Now the development team can see the relationship between roles and data access.
On the other hand, if the real need is only to ensure the system achieves certain functions and benefits, whether it is necessary to specify a particular programming language, database brand, or package is a separate judgement.
The Implementation Notes for Article 26 of the Government Procurement Act, issued by the Public Construction Commission of the Executive Yuan, state that technical specifications for open competition should be limited to what is necessary to meet the agency's needs in terms of function, benefit, or characteristics, and that whether a specification restricts competition is judged by whether it goes beyond what the agency actually needs.
So the core question for a requirements specification is not “how much technical detail can I add?” but “which conditions does the agency actually need, and which must the vendor know?”
If the project is not yet sure which technical solutions the market offers, the Commission's current notes also state that, apart from cases handled under the public review system, an agency setting technical specifications may publicly invite vendors to provide reference material under Article 34, Paragraph 1 of the Government Procurement Act, for deliberation before the specifications are set.
This also means business requirements and technical solutions do not all have to be decided on the first day of requirements planning.
Which easily missed requirements directly affect development scope?
Key takeaway
What really creates differences in quotes, architecture, and schedule is often not the main features but data, usage volume, permissions, integration, security, and the existing environment.
Take two systems both called “case management system.” One serves ten internal staff; the other has to let large numbers of citizens apply and check status online. The feature names may look alike, but the needs for account management, traffic, capacity, data security, and infrastructure can be completely different.
The same goes for data migration. If years of historical cases must be retained after the new system goes live, the requirement is no longer just “develop a new case system.” It also covers data inventory, format clean-up, field mapping, conversion, validation, and the switchover between old and new systems.
Likewise, if an existing system must be connected, do not write only “the system shall provide API integration.” Also confirm:
- Which system is being connected?
- Who provides the interface?
- Which data is exchanged?
- How often?
- What happens when an exchange fails?
- Which permission and security constraints apply?
The Water Resources Agency's current internal rules, for instance, list among the points to note in a requirements specification the annual data growth, main and peak user numbers, peak periods, network traffic, server capacity, compatibility with existing applications and third-party components, data compatibility, and cybersecurity protection needs.
This again shows that the number of features is not the only basis for judging the scale of system development. It is also why, when different vendors receive the same requirements and quote very different prices, it is not necessarily that one is more expensive; they may actually be estimating different scopes.
Why should security also be confirmed at the requirements stage?
For a government information system, security is not a test run once after the system is finished.
Article 10 of the current Cyber Security Management Act provides that when a government agency or a specific non-government agency, within the Act's scope, outsources the construction, operation, or services of an information and communication system, it must select an appropriate contractor, require an effective cybersecurity management mechanism and supervise its implementation, and set out both parties' rights, obligations, and liability for breach in a written contract.
Article 11 of the current Regulations on Classification of Cyber Security Responsibility Levels, issued on January 7, 2026, also provides that information and communication systems developed by an agency itself or through outsourcing must complete protection requirement classification under Appendix 9 and apply control measures according to the protection baseline in Appendix 10.
So if the system involves login, permissions, personal data, sensitive information, or cross-system data exchange, the relevant requirements may directly affect its architecture and development approach. The earlier they are confirmed at the requirements stage, the lower the risk of discovering late that the system needs major changes.
How do requirements connect to testing and acceptance?
Key takeaway
Good requirements do not only answer “what should the system do?” They should also answer “how do we prove it is done?” The more a requirement can be turned into a testable scenario, the easier it is to build a shared standard for acceptance.
Suppose the requirement says “citizens can check the progress of their case.” Once testing begins, this can be confirmed further:
- Can citizens search in the specified way?
- Are the different case statuses shown correctly?
- Are people without permission prevented from viewing a case?
- How does the system respond when the case does not exist?
If the original requirement was only a vague “provide case enquiry,” and these conditions are discussed for the first time at acceptance, it is easy to end up with a gap between “the agency thought this was obviously included” and “the vendor thought the original requirement did not cover it.”
Under the Water Resources Agency's current system development and maintenance rules, for example, the testing stage runs functional tests against the plan, the requirements specification, and the design documents, and results that fall short of the requirements and design expectations are followed up. Again, this is the regime of the Water Resources Agency and its subordinate bodies, not a uniform acceptance method for all agencies, but it illustrates an important principle of system development: requirements, design, testing, and acceptance should not be separated from one another.
So once the requirements specification is complete, check each item:
- Who uses this requirement?
- Under what conditions is it triggered?
- What is the expected result?
- What happens on failure or exception?
- How is it verified in the end?
If an important requirement cannot answer the last question, it usually still needs clarification.
When are requirements ready for the next stage?
Key takeaway
Requirements do not have to settle every screen and technical detail before they count as ready. What matters more is that the project's problem, users, processes, data, main features, constraints, and direction for acceptance are clear enough.
A few questions help make that call:
Can the requirements already be understood?
Would different readers come away with broadly the same answer to “what is this system meant to solve?”
Has a system boundary formed?
Is it known which features belong to this project and which need external systems, other units, or third-party services to cooperate?
Are the main processes complete?
Beyond the normal path, is it becoming clear what happens on rejection, correction, cancellation, errors, or insufficient permissions?
Has the important data been inventoried?
Is it known which data needs to be created, kept, migrated, or exchanged?
Have the development constraints been disclosed?
For example the existing environment, deployment approach, information security, compatibility, or other necessary project conditions.
Can the direction for acceptance be described?
At least, can it be explained which scenarios will confirm the outcome once the important features are done?
If most of these can be answered, the requirements have moved from “we want to build a system” to “we know what this system mainly needs to solve, and we can start assessing how to do it.”
Conversely, if all that exists today is a direction such as “we want to digitise the process,” “we want a case management platform,” or “we want to introduce online applications,” that does not mean the project cannot start. It is simply better to begin with:
- 01
Inventory of the current process
- 02
User and requirements interviews
- 03
Inventory of data and the existing environment
- 04
System boundary definition
- 05
Feature and technology assessment
and form the formal development requirements step by step from there.
Frequently asked questions
Not necessarily. There is currently no universal rule for government information system procurement that requires every UI screen to be finished before tendering. Whether wireframes, flowcharts, screen mock-ups, or other documents are needed depends on the case and the agency's rules. From a development standpoint, what matters more early on is confirming the users, processes, features, data, and system boundary.
Regulations and standards cited
- Guidelines for Information System Development and Maintenance (Water Resources Agency and subordinate bodies)Water Resources Agency, Ministry of Economic Affairs (internal rules)
- Implementation Notes for Article 26 of the Government Procurement ActPublic Construction Commission, Executive Yuan
- Government Procurement Act, Article 34, Paragraph 1Public Construction Commission, Executive Yuan
- Cyber Security Management Act, Article 10Current statute
- Regulations on Classification of Cyber Security Responsibility Levels, Article 11Current statute
These are the regulations and standards cited at the time of writing. Rules may be revised; always check the latest official announcement before relying on them.