In our company we split up software development in three non-overlapping teams: a team that writes the specification, a team that writes the code, and a third team that tests the implementation against the specification. I'm looking for a bibliography reference for a description of this division of labour? It seems to me that it is common practice in safety-critical domains.

  • 1
    Note that just because separate things exist does not mean there exists explicit literature on enforcing its separation. You're describing three very different jobs with different skillsets, it's no surprise that these attract different people with different job titles. On top of that, specialization often leads to narrowed job responsibilities. Medical professionals can be highly specialized in different ways, but that doesn't mean such an enforced division is enshrined in any kind of written material.
    – Flater
    Oct 13, 2020 at 8:46

2 Answers 2


The principles are Division of Concerns, and Defence in Depth.

Division of Concerns is to as much as possible minimise the amount of privileged information sharing. This is often mandated by governments of organisations who deal with sensitive or risky information that can unduly influence others, or would cause damage to others if too wide spread.

Defence in Depth is to provide as much chance as possible to catch problems. The specifiers use their formal systems, and models to specify and catch problems. The developers then attempt to develop those specifications, and catch more problems. The testors who then attempt to poke holes in the system in everyway they can.

However most likely your organisation is organised this way not due to safety concerns. It is most likely organised this way because that is how engineering and manufacture of real world items is organised. A set of highly skilled engineers on top, a plethora of craftsmen/workers underneath to execute that vision, and alongside a department of people dedicated to finding faults in the organsiation and product.

If your organisation were truly worried about safety you would be organised around the pattern used for aircraft aeronautics system development. 3 separate organisations each individually responsible for implementing the same component in 3 different ways with a simple governer rigerously verified by each of those three organisations who simply provides the same inputs to each, and compares the results for agreement to some percentage of error.

  • I would upvote but there is no reason to put the testers below the engineers or the craftsman. In fact, by creating a hierarchy you lose a lot of the independence of independent verification and validation. Oct 13, 2020 at 16:12
  • @candied_orange Hierarchy? Where? Do you mean between the engineers/craftsmen in a common engineering outfit? The testers are external to that. How did you walk away with that understanding?
    – Kain0_0
    Oct 13, 2020 at 22:46
  • By reading what you wrote. Consider an edit if impressions besides your own mater to you. I’ve no interest in arguing. Oct 13, 2020 at 23:52
  • Strange definition of "Division of Concerns" Very domain-specifc.
    – fpmurphy
    Oct 14, 2020 at 6:30
  • @fpmurphy Financial and governmental bodies tend to require this. It is indeed different to the software concept of division of concerns.
    – Kain0_0
    Oct 14, 2020 at 6:40

What you describe here seems to be an exaggeration of a very old and common misconception in Software Engineering. I use "engineering" here and not "development" for the sake of making it clear that there are indeed similarities to other engineering duties, but sadly very often misconceived.

  1. Specification is not requirements nor blueprint. The requirements are formulated by the stakeholders and product managers/owners. The "specification" is often just a high level description of how the requirements will be implemented. You can call them also "non-functional requirements" or "design rules/constraints".

  2. Implementation is not building the product. Implementation is the same process like creating the blueprints for the product with which a fully automated production line can then build it. For physical production this is usually very costly - for software, even if it takes half a day - relatively cheap. So you can change the "design" and rebuild the product again and again.

  3. Testing has a very different meaning in manufacturing and software. In manufacturing there are two different tests - testing the design (validation) and testing the unique built item whether it is built to spec (verification). In software there is very little need for latter as the building tools rarely fail, so most effort goes into validation. In some cases this even makes sense, but only if you test against the requirements and not against the "specification".

Almost every SW-development process, especially the waterfall (or V-) model builds upon the #2 misconception that "implementing" is "building" and should be guardrailed the same way like the cost-heavy production process in a factory instead of embracing the agile way of iterating towards the requirements of the stakeholders.

Sadly there is very few literature about this out there, but maybe you may want to check out this talk from Glenn Vanderburg: https://www.youtube.com/watch?v=RhdlBHHimeM

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.