requirements
Editor: Neil Maiden
■

C i t y U n i v e r s i t y, L o n d o n

■

n . a . m . m a i d e n @ c i t y. a c . u k

10 Small Steps to Better Requirements
Ian Alexander

T

he journey of a thousand miles begins with a single step.” This Chinese proverb helps people focus on the present, rather than the unmanageable future. Project teams can take several small, easy steps to improve requirements to the point where they’re good enough. But every project is different. Your team might need to take steps that wouldn’t be right in other situations. The basic steps listed here, roughly in order, demand nothing more than a whiteboard or a pen and paper. Requirements management tools and specialized models can help later on.

where software is just a (large) component. Later, you can analyze each interface in detail.

Step 1: Mission and scope If you don’t know where you’re going, you’re not likely to end up there, said Forrest Gump. Is your mission clear? Write a short statement of what you want your project to achieve. Out of that will grow an understanding of the project’s scope. The scope will develop as you more clearly understand exactly what achieving the mission entails. A traditional context diagram is a good tool for describing scope in a simple outline. Unlike a use-case summary diagram, it indicates interfaces and the information or materials that must come in or out of them, rather than just roles (that is, UML actors). This becomes especially important when specifying physical systems
0740-7459/06/$20.00 © 2006 IEEE

Step 2: Stakeholders Requirements come from people, not books. You can look in old system documents and read change requests, but you must still validate any candidate requirements you discover with people. Missing a group of stakeholders means your system could lack a whole chunk of functionality or other