This is part of a regular series that highlights new books and their authors. Also in this series: Michael Ogrinz on Mashups, J. Peter Bruzzese on Exchange Server 2007, Joel Scambray on exposing the hacker's advantage, and Scott Hogg on IPv6 security. (You can find all the installments in this series here.)
Requirements engineering is a key part of the product or project lifecycle -- and often the most difficult part. As Joe Sutter, the father of the Boeing 747, said in an interview with Air and Space magazine: "At the start of a program, asking questions is the most important part of the process. If you get [the customer's] requirements wrong, then you don't have a successful product." It is a challenging field.
About the book Software & Systems Requirements Engineering: In Practice is intended to appeal to a wide range of IT professionals. Best practices are described for requirements elicitation, business modeling, requirements management and the relationship between requirements and testing. The appendix includes information on requirements databases and their use.
We also talk about things in this book that are not commonly discussed in RE primers. For example, we discuss the management of large numbers of requirements on industrial projects, the practical application of RE techniques to handling architectural requirements, and we offer some tips for rapid prototyping.
Name: Brian Berenbach
What I'm working on now: Currently I am part of a team defining the requirements for a major upgrade to a regional rail system.
Favorite learning sites: You can learn a lot by reading conference papers. I am partial to material presented at major IEEE and ACM conferences such as the IEEE International Requirements Engineering Conference and the International Conference on Software Engineering.
Something most people don't know about me: I have a 6th degree black belt in Okinawan Karate.
Philosophy: I am always looking for a better way to do my job, and curious about how people work. If I do find a better way, I like to share it with the community.
5 keys for success
- When creating requirements for mission critical projects, at least one senior team member should have done it before on a successful project.
- Create a meta-model of all project artifacts, and then define processes and tools that implement the model.
- Plan for scale – it may not seem important at the beginning of a project, but without tools and facilities in place for managing scale, the project can implode.
- Maintain a full time core team.
- Expect to spend up to 18% of the total project budget on requirements development and management.
5 classic mistakes
- One typical mistake is to consider requirements elicitation a second class task and assign it to junior staff. Requirements engineering is difficult, and sometimes senior staff will shy away from doing it because it is considered uninteresting.
- On contract based projects, project staff sometimes ignore requirements until, late in the project, the client asks for a trace matrix, at which time it may be too late. Furthermore, not having a viable tracing model and tools support, can, unfortunately have catastrophic consequences.
- When eliciting requirements from stakeholders, a common error is to focus on the customer and ignore the ultimate end user. An example would be eliciting requirements from the purchaser of a control system without eliciting requirements from the operators who will be using the system.
- Another problem we have seen is the breakdown in communication between the requirements staff and development or manufacturing. For example, how will requirements changes be passed to manufacturing? What will the impact of a change be?
- Different software methodogies may be applicable on different types of projects. A common mistake we have seen is to use an inappropriate methodology because of the comfort factor; for example, using an agile approach to iteratively develop a complex product on a fixed price contract.
Parting words: Business models should not be viewed as collections of pictures, but rather as coherent directed graphs. Heuristics and rules for models should be created up front that can be used to measure progress and quality, and, most important, define completeness.
When creating project processes, pay special attention to managing scale and what stakeholders will need to do their jobs once a project is into implementation and testing.