I'll admit something.
After 25 years in IT and many insurance, banking and leasing projects, I too have written functional specifications that nobody read. At the time I didn't know why. Then I started noticing the patterns.
The problem wasn't that the document was bad. The problem was that the requirements specification was good - but nobody read it. Those are not the same thing.
If you work as a business analyst, you probably recognise the feeling: you spend weeks on a functional specification, the stakeholders approve it, and then when development starts it turns out everyone understood the core processes differently. Not because you did a poor job, but because your document wasn't truly readable - or at least not in the way you thought.
Here are the five surest signs.
Sign 1 - The functional specification is 47 pages long, and that's just the general section
There is an inverse relationship between a document's length and the likelihood of it being read. That isn't opinion - it is observation.
I worked on an insurance project where the requirements document ran to 94 pages. At the first sprint review, the developers asked questions that were already answered on page 12. Not because they were lazy - but because nobody reads a 94-page functional specification linearly, and nobody actively goes looking for page 12.
Length gives the business analyst a sense of security: "I've written everything down, it's all in there." But it is a false sense of security.
What works instead: Start every requirements specification with a summary of no more than one page, covering the three to five most critical business decisions and assumptions. Everyone reads that. Put the details in appendices - complete there, but not the first layer.
You don't need to cut a 94-page document to 10 pages. But the first page has to be good enough that anyone who reads only that knows the most important things.
Sign 2 - It doesn't contain a single concrete example
"The system enables the user to complete the claims notification process via the designated interface."
That is a real sentence from a real functional specification. Every word is correct. Nothing can be learned from it.
A lack of concreteness is one of the most common and most dangerous problems in business analysts' requirements documentation - especially on financial services projects, where processes are actually very concrete, but nobody writes them down that way.
A concrete version of the same thing: "A claims handler processes 40-50 claims notifications a day. On average, 12 of them require manual intervention - typically those where the policy number can't be identified automatically or the claim amount exceeds HUF 200,000. The system must place these in a separate queue and automatically notify the claims handler."
The second version is twice as long. But it is ten times more readable - and as a developer or tester, you know exactly what has to be implemented.
What works: For every functional requirement, ask yourself: "If a developer reads this, can they write code from it?" If the answer is no, the requirement isn't concrete enough.
Sign 3 - The developers don't ask any questions
This is one of the most counter-intuitive signs - and one of the most reliable.
If you hand the requirements specification to the development team and not a single question arrives in the first week, it doesn't mean everything is perfectly clear. It most likely means they haven't even opened it.
A good functional specification generates questions, because it makes people think. The developer starts working through the implementation and runs into edge cases, integration points and exceptions. These questions are healthy - in fact, they are necessary.
If developers still haven't asked anything after a week, don't assume all is well. Ask them: "Was there any detail that wasn't clear?" In 80% of cases, that is when it turns out the document hasn't even been opened.
What works: When handing over the requirements document, don't just send it - run a 30-minute walk-through. Not so you can explain the whole thing, but so the developers open it and the first questions come up straight away. That is where real understanding happens.
Sign 4 - The testers rewrite it in their own words
The QA team is one of the most honest judges of a functional specification's quality.
When testers can't derive test cases from the requirements document - and so write their own interpretation, or ask the developers "is this right?" - the business analyst has lost control of the requirements. Not deliberately, not through error - but lost it nonetheless.
We saw this up close on a Salesforce rollout. The functional specification existed, but during testing the QA team produced its own interpretation document - because the expected behaviour in certain exceptional cases couldn't be clearly derived from the original requirements specification.
That wasn't the testers' fault. It was a sign that the functional specification hadn't gone deep enough in describing concrete behaviour.
What works: Think in test cases when writing the requirements specification. For every process, ask: "How will the tester verify that this works correctly?" If you can't answer, the requirement isn't concrete enough.
Sign 5 - The stakeholders signed it off but didn't read it
This is the most common sign in requirements management - and the one that causes the most problems.
In most organisations, sign-off is an administrative act - not genuine reading and approval. The stakeholder signs because the project manager asks, because there is a deadline, because they assume the business analyst must have done it right.
The reality: most business stakeholders don't read a functional specification of 30+ pages. Not because they don't care, but because they don't have the time and aren't used to the format.
There is a technique I have used for years: I embed a specific question in the requirements document that only someone who has actually read it through will find. Something like: "Regarding the exception handling logic described in section 5.3.2: what is the expected behaviour if the customer amends the notification within 48 hours? Please confirm or clarify."
If nobody answers that question after sign-off, the functional specification hasn't been read.
What works: Highlight the summary and the critical decision points visually - with a separate "Questions requiring a decision" section at the start of the document. Everyone reads these, because they communicate decision-making responsibility.
What do these signs have in common?
They all trace back to the same underlying problem: the business analyst writes the document but doesn't plan the communication.
A requirements specification doesn't exist on its own - it is a communication tool within an organisation. And like any communication tool, reading, interpretation and feedback have to be actively planned - it isn't enough to send it and wait.
That doesn't mean the business analyst is responsible for making sure everyone reads it. But they are responsible for making the functional specification readable. And they are responsible for making sure handover doesn't end with sending an email.
BAs who understand this don't just write documents - they own the business requirement throughout the project lifecycle.
A question for you
Which sign is most familiar from your own projects? Is there a sixth sign I have missed?
If you want to work in a professional environment where your requirements specifications are actually read and used, see how we work: frontx.hu/en/careers
Frequently asked questions about requirements specifications
Why aren't requirements specifications read on IT projects? Three main reasons: the functional specification is too long and unstructured, there aren't enough concrete examples and descriptions of expected behaviour, and the handover process doesn't actively plan for reading. In most organisations, sign-off is an administrative act, not genuine approval.
How long should a good requirements specification be? There is no single right length - but the golden rule is that the first page should be good enough that anyone who reads only that knows the three to five most critical business decisions and assumptions. The details should be complete in appendices, but not the first layer. Structure and concreteness matter more than length.
What is the difference between a functional specification and a requirements specification? A requirements specification (Software Requirements Specification, SRS) is the broader concept - it covers business needs, user requirements and system requirements. A functional specification is narrower: it describes only the expected behaviour of the system. In practice, many organisations use the two terms interchangeably.
How can you check whether a stakeholder has really read the functional specification? An effective technique: embed a specific question requiring an answer somewhere in the document that only someone who reads it through will find. If nobody answers it after sign-off, the document hasn't been read. Alternatively, hold a short review meeting before sign-off where stakeholders have to answer specific questions.
What can a business analyst do to make sure the requirements document is read? Run a 30-minute walk-through with the development team when handing over the functional specification. Highlight the "Questions requiring a decision" section in every review cycle. Track in the first week whether questions arrive - if not, actively ask. Keep the document structured: a summary at the front, details in appendices.
How does requirements management relate to project success? For years the Standish Group CHAOS Report has consistently shown that one of the most common causes of IT project failure is incomplete or misunderstood business requirements. A well-written functional specification that is actually read reduces rework, scope creep and testing surprises - all three of which are direct project costs.
__________________________________________________________________________________________________________________
László Behán is Managing Director and Co-Founder of FrontX Kft. He was previously CIO of Signal Biztosító (an IT team of 25, reporting directly to the CEO), Head of Development and Data Warehousing at Groupama Biztosító, and Operations Director and a member of the Board at LeasePlan Hungaria. He has 25 years of IT and business leadership experience in financial services. LinkedIn | FrontX insights
