I'm never a fan of "project surveys" for all the right statistical analysis reasons. But Baseline Magazine has a nice presentation that goes along with a survey from a consulting company.
The Truths About Project Planning is worth a look.
The pitch is generally about managing requirements. The best books I've got on requirements are:
- Requirements Engineering , Methodology for Writing High Quality Requirement Specifications and for Evaluating Existing Ones, Software Assurance Technology Center,Linda Rosenberg, NASA Goddard Space Flight Center Greenbelt, MD
- Systems Requirements Practices,Jeffery Grady, McGraw Hill, 1993
- “Good Practices for Developing User Requirements,” Ellen Gottesdiener CrossTalk, 3/08
- The Requirements Engineering Handbook, Ralph R. Young, Artech House
There are many others of course, but these cover a broad set of domains and contexts.
A Bit About Requirements
- Requirements need a reasons for being - they must be connected to some business reason. This connection needs to be traceable back to a statement in the business case. This traceability is usually held in the document called the Concept of Operations.
- Requirements need to be "engineered," in the same way the system architecture is engineered and in the same way the software is engineered. That is someone has to look at the requirements and make sure they make sense. This is called Requirements Engineering and Requirements Management.
- Requirements need to be verified and validated among themselves and back to the business case or the Concept of Operations. Then need to be traceable to the code, hardware, operational behaviors. This allows the project to answer the question "who ordered this requirement?," and "if I drop this requirement, what else gets dropped?"
There is no way around these activities. The implementation of the requirements processes varies from 3x5 cards stuck on the wall for your XP project to a TeleLogic DOORS database with 10,000 requirements for a manned spaceflight program.
