What is the usual process of summarizing the specification documents for review and comparision

Question

My engineering team is gearing up for a bidding on a public project, where the specifications document is huge (~500 pages). I would like to break it down clause by clause in a spreadsheet and then assign the teams the relevant "portion". I checked, but PDF document is the only way these specs are provided.

The idea is to record it such that we can compare it with specifications of previous projects that are recorded in similar manner. I am still a trainee, so am not aware how this process works around different companies, but here in my team, the last project was documented manually in a similar manner.

So my question is:

Is this (converting the PDFs to Spreadsheets, clause by clause, manually or otherwise) the correct way of managing specification documents? Because this process seems to be extremely inefficient and time consuming.

If not, what would be the usual standard methods, assuming that the specification documents are always similar PDFs

If it is the standard way, is there a software suite that is usually employed for this purpose or is it given to teams to manually record?

I did go through a somewhat relevant question here Dealing with large specifications with Scrum but the post is really old and does not really answer the questions I have. I hope that in 10 years there might have been some changes and updates.

Answer 1

My experience is that this issue is handled inefficiently throughout the industry.

Working for a car manufacturer there was a dedicated team to convert "customer requirements" into "a list of requirements". Those were non-technical people so following the list was a disaster thus us SW people strived to just get the original document and ignore the interpretation.

Everywhere else when I asked about requirements the answer was "What do you mean 'requirements'?! We are doing AGILE - there are no requirements."

What I imagine would have been nice is:

• Summary. Like a paper's abstract, just somewhat longer.
• Behavior diagram. Humans are visual creatures.
• Hyperlinks. Even if the god of engineering translated a customer document into a list of specs, information will still be lost. Provide the original content to the technical team.
• Breakpoints. "After completing this bunch of topics, contact the client and make sure we're still on track."

This should make it easy for a technical manager to judge can some code be borrowed from another project.

_{< whine > spreadsheets are notgrep-able}

Answer 2

After 25 years in software delivery I have never seen 2 requirements document that are the same so it is inherently an inefficient process.

That being said, I normally take a few steps to make things manageable.

1. Tag clauses using MoSCoW
2. Organise requirements into iterations
3. Assign high level resources to each iteration: -

• Skills ( architecture, security, analysis, testing, documentation, release, maintenance, call centre, legal, procurement, data governance, etc ) and -Equipment ( bar scanner, software, laptops, etc ) to each iteration.
• Dependencies ( external, internal, technical )

4. Then as you say, get the right people involved.

I would recommend not over-optimising the process as that will give you quickly diminishing returns, Hope this helps.

Answer 3

Bidding for a public project requires to take all the requirements into account upfront and very systematically to prepare the bid. There are two aspects in this analysis:

1. Compliance: You will have to check for each requirement what it means for your future delivery team to comply (i.e. special skills, third party APIs, etc...). Depending on the kind of tender, you might even have to confirm that your product is/will be compliant with each item, and provide justification/explanation. In this case, a missing answer/confirmation can result in a lower ranking of your bid compared to your competitors.

2. Estimates for making the bid: it will depend heavily on the way the requirements are structured. In some cases you can consider a bottom-up approach, i.e. estimating each requirement separately and add the numbers up. But very often (and especially with large sets of requirements) this will not work, because requirements are not necessarily features, overlap, do not complete each other, are ambiguous, or even contradict themselves. You'd often need to take a more holistic approach, and use grouped requirement items to fine-tune your overall estimate and narrow down the uncertainty.

In both cases, a breakdown of the requirements into a tabular document is a proven and popular approach to dispatch the analysis across an engineering team and collect/aggregate the feedback. (It might not be the most efficient way to do things for the delivery afterwards; but you first have to get your bid approved before having the opportunity to deliver)

There are even specialised requirement management tools such as IBM Rational Doors, and others, who can manage individual requirements, categorise them, assign them, and even link and hierarchize them, and later on trace them across the deliveries. But unless your company has a strong RM culture, this might be overkill, especially considering that these tools are not best suited for iterative or agile delivery if you can use theses once you win the bid.