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?

put on hold as primarily opinion-based by gnat, Nicol Bolas, Greg Burghardt, Eric King, BobDalgleish Dec 10 at 15:46

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.

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. – Nick Alexeev Nov 30 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. – Donald Airey Nov 30 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 Nov 30 at 18:45
  • @amon - I will look into it, thanks. At face value, I agree with the goals. – Donald Airey Nov 30 at 20:04

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