This quick post is just to share an article I came across that I thought might be beneficial, especially to the relatively new analyst. “Specifying Good Requirements“, by Donald Firesmith, includes some good, basic information about requirement quality assurance. Basically, […]
You’ve poured your heart and soul into drafting the perfect requirements specification. You’ve checked, doubled checked, and triple checked every syllable of the document for clarity, spelling, testability. You have full traceability to every business requirement. You’ve been extra, extra careful not to tread in the domain of design. Your spec is rock solid.
So, why, after 5 review sessions with project stakeholders and document consumers, are you still making edits?
Numerous professional studies have shown that poorly understood software requirements are the number one cause of schedule and budget overruns and ultimately project failure. Studies have also shown that the earlier in the SDLC that scope is understood, and defects […]
“Functional specifications documents lead to an illusion of agreement. A bunch of people agreeing on paragraphs of text is not real agreement. Everyone is reading the same thing, but they’re often thinking something different.”
One of the main challenges in drafting requirements is to state “what” the solution must entail, and not “how” the solution must be tailored. I found the excerpt below from a paper authored by Ivy Hooks very helpful.