I was talking a program manager recently who described a funny requirements situation from her past that topped most of the stories I have heard.
She had assigned the team’s business analyst do some requirements for a particular feature of a system they were implementing. He was dragging his feet for weeks on this, delivering no drafts along the way, but insisting he was working on the requirements. Well it came time to deliver the actual requirements, and he delivered. This individual had done requirements documents in the past for her projects, so she was familiar with and expected some of the typical writing issues by this person. Well, when she got the requirements document for this new system, she noticed that the typical writing issues were not present. While this seemed suspicious, one could chalk it up to having a proof-reader help out. But she also thought the requirements lacked any real substance around how to implement the feature for their business environment. It had no details about business rules, configuration needs, actual roles and permissions for their organization, etc. In fact, she noticed they seemed like they were very generic descriptions of what this feature would look like.
So after a bit more thought, she decided to do a Google search on some key phrases from the requirements document. Sure enough, she found them on the internet. It turns out, this business analyst had gone out and found a spec for an off-the-shelf product for the feature they were implementing and he submitted that as his requirements for development on their project.
What I will say is that if you can re-use requirements from your internal projects, I say go for it. I highly encourage requirements reuse using requirements patterns! The key difference here is you aren’t violating confidentiality, you aren’t stealing someone else’s work (since it’s the property of the company!), and it’s actually a useful re-use.
Creative? Perhaps.
Lazy? Likely.
Useless? Mostly.
Good story? Definitely!
