Who should have full visibility of all (non-data) requirements information?
- by ebyrob
I work at a smallish mid-size company where requirements are sometimes nothing more than an email or brief meeting with a subject matter manager requiring some new feature.
Should a programmer working on a feature reasonably expect to have access to such "request emails" and other requirements information? Is it more appropriate for a "program manager" (PGM) to rewrite all requirements before sharing with programmers?
The company is not technology-centric and has between 50 and 250 employees. (fewer than 10 programmers in sum)
Our project management "software" consists of a "TODO.txt" checked into source control in "/doc/".
Note: This is nothing to do with "sensitive data access". Unless a particular subject matter manager's style of email correspondence is top secret.
Given the suggested duplicate, perhaps this could be a turf war, as the PGM would like to specify HOW. Whereas WHY is absent and WHAT is muddled by the time it gets through to the programmer(s)...
Basically. Should specification be transparent to programmers? Perhaps a history of requirements might exist. Shouldn't a programmer be able to see that history of reqs if/when they can tell something is hinky in the spec?
This isn't a question about organizing requirements. It is a question about WHO should have full VISIBILITY of requirements. I'd propose it should be ALL STAKEHOLDERS. Please point out where I'm wrong here.
