> But, at all times, your requirements/specification must be accurate.
>
> If the requirements say "the system does X", the electrical engineers must be free to use this assumption, without talking to the software engineers. The sales people must be able to put this in the marketing docs, without having to guess.
Fine, sounds nice! A team that can work without a communication overflow, that's wonderful!
A few lines later:
> Requirements should be a living document.
He lost me here.
On one side, he preaches for a "source of truth" that everybody can read and take autonomous decision accordingly; on the other side, he recognizes that the "truth" has the horrible tendency to drift with time. He just misses the elephant in the room: what do you do after you updated the document?
How do you track all the assumptions that every team member has made based on that item that you have just changed? What useful is an accurate document if you can't trust it won't change?
Requirement/specification change is the bane of every complex engineering challenge, and acknowledging it while proposing to ignore it cannot be a solution.
Requirements changing are a reality. In safety critical fields, these changes are noticed by using traceability tools.
I haven't written this far yet: but you should have a process for changing things like system requirements. It should be discussed, reviewed, and approved by the relevant teams. The "downstream" documents, like software or hardware reqs, should be updated as well.
Hard to fit all the details in a single summary, but happy to answer questions
Fine, sounds nice! A team that can work without a communication overflow, that's wonderful!
A few lines later:
> Requirements should be a living document.
He lost me here.
On one side, he preaches for a "source of truth" that everybody can read and take autonomous decision accordingly; on the other side, he recognizes that the "truth" has the horrible tendency to drift with time. He just misses the elephant in the room: what do you do after you updated the document?
How do you track all the assumptions that every team member has made based on that item that you have just changed? What useful is an accurate document if you can't trust it won't change?
Requirement/specification change is the bane of every complex engineering challenge, and acknowledging it while proposing to ignore it cannot be a solution.