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 somevaluable points regarding the different views of what a 'requirement'is to different stakeholders. He presented a frameworkfor separation into business (why), user (what), and functional(high-level how) requirements, and how to categorize requirements intothis framework to help avoid confusion. This becomes particularlyimportant when doing incremental development (which is what almosteverybody does): It's OK to be fuzzy on some of the functionalrequirements before starting a project, but the business requirementshad better be very clear and solid.
Regarding change control boards, I asked how one can scale a CCB so itdoesn't become a bottleneck in a large program. He said (interpretinga bit) that the way to scale a CCB is to identify policies so that youcan distribute responsibilities among CCBs -- only escalating changerequests up to a central CCB if its scope truly warrants it.
The slightly depressing part about this talk was that I knew most ofthe solutions presented; however, none of them helped to solve thereally hard people problems that actually are the root cause ofmost requirements issues.
On a side note, the wireless network stopped working for me during thistalk. I started seeing packet round-trip times of >>1sec to reachwhat was supposedly our DNS server. I think this highlights one of thenonfunctional requirements that should have been part of the requirements for the Santa Clara Convention Centernetwork: When you build a wireless network for a convention center inthe middle of Silicon Valley, make sure that it can handle a fewthousand software engineers with laptops!