One of the most common misconceptions about software testing is that QA does not come into play until the development of a module is complete and ready to test.
In actuality, the earlier QA is involved in the Software Development Life Cycle (SDLC) the better. Studies have shown that up to two-thirds of defects can be attributed to requirements and design.
Gathering requirements for software development projects has always been a difficult process, and has veered through various methodologies like waterfall and agile. Regardless of the methodology, though, there are certain pitfalls to deciding and describing just what an application should do that can result in projects stumbling or failing. Requirements fractalization, focus on little used details, or lack of developer and stakeholder involvement can all actively harm the best architecture.
While preparing some documents today I ended back here on the blog reading two posts from last year that are still fresh and deserve a second (or first, if you missed them the first time!) look.
First, a post I wrote while waiting at the airport for a flight to SXSW 2014. That flight ended up being so delayed that I came closer to missing the panel I was speaking on than I care to ever repeat again:
Thoughts on Estimating Software Projects
To be honest, while I’m excited to be speaking at SXSW, I wasn’t at all excited at first to be talking about this topic; it’s an area that’s not considered ‘cool’ in modern software development circles. The most obvious indication of this attitude is an article in a recent issue of Pragmatic Programmer Magazine by Ron Jeffries titled “Estimation is Evil: Overcoming the Estimation Obsession.”
…and a follow-up post a week later by Noah Miller talking about our guidelines for writing useful and meaningful requirements docs for software projects:
Thoughts on Writing Software Requirements
Writing and estimating requirements is painful to most everyone involved, highly problematic, totally not hip – and essential to well run projects.
Check them out.
Image by https://www.flickr.com/photos/gazeronly/
See the horror in the elephant’s eye? He has a spec due Sunday.
Matt Reinbold, http://www.flickr.com/photos/furryscalyman/1830292015/
I’ve had notes sitting around for months for a post on writing software project requirements, but Brett’s piece last Friday on Estimating Software Projects inspired me to pull them out. Writing and estimating requirements is painful to most everyone involved, highly problematic, totally not hip – and essential to well run projects. But since it’s probably just as painful to read about writing specs, I’ll keep this bullet-pointy 🙂 (more…)