Part III Development: keeping the project on track
What is expected of you, what to check, how to manage changes, and how to accept the finished work.
Chapter 14: Analysis: what exactly the software must do
What is not written down will not be delivered, and whatever is written in on top, you pay for. Every requirement must be verifiable: set acceptance criteria for user stories, and replace general words such as “fast and secure” with specific values and requirements. Just as important is a signed list of what will not be delivered, and one person on your side who approves the specification.
First the problem and the users, then the features
The brief for vendor selection (chapter 6) describes what you need and why. Analysis with the selected vendor turns it into a specification: who will use the system, in what situations, and how you will tell that it works. The UK and Australian governments call this discovery, and the New South Wales government usually sets aside 4–8 weeks for it NSW Government, 2026. For a smaller, clearer system, a shorter discovery is enough, which is why chapter 8 gives a range of 2–8 weeks. The result can even be a decision that developing a new system makes no sense.
The most common mistake is to turn a paper form into a screen 1:1. The Supreme Audit Office (NKÚ) criticizes the state for “digitalization at the level of forms”: after investments of more than CZK 50 billion in 2020–2024, only 18% of services were fully digital NKÚ, 2026. Simplify the process first, then digitalize it.
Talk to the people who will use the system every day, not just to management. In the digital building permit system project, according to the technical audit, the requirements were drawn up without involving the key future users DSŘ audit, technical part, 2025 (chapter 20 describes how the launch went).
The cheapest test is a clickable prototype. For a first check, try it out with 5–8 people who do the day-to-day work. That way you can find most process errors before the first line of code is written. Rewriting a screen in a prototype takes hours; in a finished system, it takes weeks.
Every requirement must be verifiable
According to a PMI survey from 2014, 47% of unsuccessful projects failed to meet their goals because of poor requirements management PMI, 2014. This is a share of projects, not of organizations as with the 37% in chapter 6. The basic unit of a specification is therefore the user story: As a [role], I want [what] so that [why]. It comes with acceptance criteria in the form Given / When / Then. The vendor prepares tests based on them. At acceptance, instead of arguing about impressions, you then verify whether the system meets the criteria. Do not let a user story without criteria into development.
| Unverifiable requirement | Specific and verifiable requirement |
|---|---|
| Unverifiable requirement“The system will allow applications to be recorded.” | Specific and verifiable requirement“As a case officer, I want to see new applications sorted by submission date so that I can process them within the deadline.” Given: 3 new applications from different days. When: I open the overview. Then: I see them from the oldest, with the number of days left until the deadline, and an application past the deadline is marked “Overdue” in red. |
| Unverifiable requirement“The system will be fast.” | Specific and verifiable requirement“95% of responses within 2 s, 99% within 5 s with 200 concurrent users; verified by a performance test in an environment similar to production before acceptance.” |
| Unverifiable requirement“The system will be secure and compliant with legislation.” | Specific and verifiable requirement“Meets OWASP ASVS 5.0 level 2, demonstrated by independent verification with a list of the requirements checked; before launch, a penetration test with no critical or high findings; access logs make it possible to file an initial incident report within 24 h.” |
| Unverifiable requirement“It will be possible to export the data.” | Specific and verifiable requirement“The administrator can export all data at any time to CSV or JSON with a documented data model, without the vendor’s cooperation and free of charge.” |
The numbers in the examples are illustrative; set your own values based on the number of users and the impact of an outage. ASVS is a catalog of verifiable security requirements OWASP ASVS 5.0, 2025; the deadlines for reporting incidents are set by the Cybersecurity Act Act No. 264/2025 Coll.. Chapter 15 discusses both.
“Fast and secure” gets translated into numbers
Non-functional requirements say how well the system must work. You will find it hard to verify and enforce general words such as “fast” or “reliable.” Specific values and standards make it possible. The specification should cover at least these areas:
| Area | What to write | How it is verified |
|---|---|---|
| Performance | response time with a given number of concurrent users | performance test before acceptance |
| Availability | operating hours and permitted outage time | measurement in operation |
| Security | OWASP ASVS level, access logs | independent verification of ASVS compliance and a penetration test |
| Accessibility | WCAG 2.2 AA | audit, including manual testing with a screen reader |
| Operations | monitoring, logs, backups, and recovery | a test restore from backup |
| Data | export of all data in an open format | a test export |
| Legislation | GDPR, cybersecurity, AI Act | review with the data protection officer and the security team |
The values are examples. Chapter 15 explains the security level and the WCAG version; chapter 21 covers availability and outages.
An MVP is the smallest useful version, not half of everything
An MVP is the smallest version that real users will actually use. Only requirements with Must priority belong in the MVP (chapter 6). Plan the stages according to when they will deliver value: a pilot at one site, an expansion, full deployment. Short stages are the best insurance against cost overruns, because overruns grow with every year a project lasts (chapter 10).
It is just as important to write down what will not be delivered. The out-of-scope list is a separate part of the specification and is signed together with it. For example:
- migration of data older than 2015,
- integration with the attendance system,
- a mobile app (a website that also works on a phone is enough),
- an English version.
A specification works like an order at a building supply store: what is not on it will not be delivered, and what you add at the checkout you pay for separately. Anything left unclear will later turn into a dispute over additional work (chapter 18).
Who approves the specification?
Your product owner is responsible for the specification. The vendor helps them formulate and verify it. Each party approves its own part:
- user stories, priorities, and the MVP: the product owner,
- security, operations, and architecture: IT, the architect, and the cybersecurity manager,
- personal data: the data protection officer,
- changes to goals, budget, or deadline: the steering committee.
Document the approval with a version number or minutes.
| How it goes wrong | How to do it right |
|---|---|
| How it goes wrongThe vendor writes the specification, and you sign it “so we can get started.” | How to do it rightYour product owner is responsible for the specification; the vendor helps with formulation and verification. |
| How it goes wrongA paper form turned into a screen 1:1. | How to do it rightFirst a simpler process, then digitalization. |
| How it goes wrongAcceptance criteria “we’ll add later.” | How to do it rightNo user story goes into development without criteria. |
| How it goes wrongThe MVP is the first half of all features. | How to do it rightThe MVP is the smallest version that users will use in a pilot. |
| How it goes wrongUsers see the system for the first time at acceptance. | How to do it rightUsers try out a prototype before programming starts. |
| How it goes wrongWhatever is not in the brief will “get sorted out somehow.” | How to do it rightAn out-of-scope list signed together with the specification. |
- Have the analysis finished before the tender, ideally as a separate small contract (watch out for the ban on splitting contracts, chapter 12). Then include the prototype and the initial list of requirements in the tender documentation.
- In the tender documentation, state that the list of requirements is initial, not exhaustive, and reserve rules for changing it (Section 100(1), Public Procurement Act – ZZVZ). Otherwise a major expansion risks becoming a substantial contract modification under Section 222 (chapter 18).
- Accessibility is mandatory for public authorities’ websites and mobile apps under Act No. 99/2019 Coll. Act No. 99/2019 Coll., so it always belongs among the non-functional requirements.