I had a conversation with a recruiter recently. As a contract engineer, I've worked several jobs over the years and it's been ages since I saw a formal specification. Confluence pages, yes. Jira items, yes. Agile and Kanban documents, yes. I made the statement that specifications are discredited because, like war plans, they don't survive contact with the enemy.

So what is the general experience of the community? Are Product Specifications still relevant in an age of Agile Design?

  • 4
    see On discussions and why they don't make good questions
    – gnat
    Commented Nov 30, 2018 at 17:10
  • 1
    This would be a good question to ask in Software Engineering Chat Commented Nov 30, 2018 at 17:39
  • 2
    This is super industry-dependent – software development is far from a homogeneous industry. One of the documents I have here is a 40-page contract that lists milestones and obligations for the next two years of a project to create some prototype software.
    – amon
    Commented Nov 30, 2018 at 17:42

1 Answer 1


Confluence pages, Jira items and Agile and Kanban documents are formal product specifications.

What you may be interested in is one of the principles of Agile Manifesto:


we have come to value:


Working software over comprehensive documentation

I already explained in a different answer what this principle means. If you assume that the only form of the formal product specifications is a one-thousand pages document that nobody reads, then yes, there is no place any longer in mainstream development for this sort of things (I would expect, however, specialized branches, such as life-critical software, to still rely on this form of specifications).

But you still have a lot of formal product specifications, and hopefully so: a product with no spec would be rather fragile.

  • Speaking of life-critical software, have a look at the medical device software standard IEC 62304. All classes require a write-up about requirements analysis. Not all classes require a write-up about detailed design. Commented Nov 30, 2018 at 18:20
  • Thank you for the thoughtful answer. To you last comment I would argue: those documents never served any purpose other than to add one more item to the list of things that had to be maintained. My experience with TDD has been much more positive. The unit and system tests are done in the language of engineering and provide a much better description of the product than English ever could.
    – Quark Soup
    Commented Nov 30, 2018 at 18:29
  • @DonaldAirey You might be interested in learning about BDD which is a kind of high-level TDD. An idea that was developed in that context is expressing requirements in a human (non-programmer) readable format that can also be parsed and executed as an acceptance test – an executable requirements specification. This has the advantage that requirements and tests are one document and therefore are up to date.
    – amon
    Commented Nov 30, 2018 at 18:45
  • @amon - I will look into it, thanks. At face value, I agree with the goals.
    – Quark Soup
    Commented Nov 30, 2018 at 20:04

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