SD West: Software Requirements: 10 Traps

Next up: Karl Wiegers talks about the 10 Traps of Software Requirements.  I plan to check out processimpact.com  for sample documents and spreadsheets (the requirements prioritization example spreadsheet sounds especially useful). 

Lots of good advice and pointers to resources in the talk.  He had some valuable points regarding the different views of what a 'requirement' is to different stakeholders.  He presented a framework for separation into business (why), user (what), and functional (high-level how) requirements, and how to categorize requirements into this framework to help avoid confusion.  This becomes particularly important when doing incremental development (which is what almost everybody does):  It's OK to be fuzzy on some of the functional requirements before starting a project, but the business requirements had better be very clear and solid.

Regarding change control boards, I asked how one can scale a CCB so it doesn't become a bottleneck in a large program.  He said (interpreting a bit) that the way to scale a CCB is to identify policies so that you can distribute responsibilities among CCBs -- only escalating change requests up to a central CCB if its scope truly warrants it. 

The slightly depressing part about this talk was that I knew most of the solutions presented; however, none of them helped to solve the really hard people problems that actually are the root cause of most requirements issues. 

On a side note, the wireless network stopped working for me during this talk.  I started seeing packet round-trip times of >>1sec to reach what was supposedly our DNS server.  I think this highlights one of the nonfunctional requirements that should have been part of the requirements for the Santa Clara Convention Center network:  When you build a wireless network for a convention center in the middle of Silicon Valley, make sure that it can handle a few thousand software engineers with laptops!