Effective Requirements Elicitation and Management

Key Insight

Requirements are rarely simple to 'gather'; they are often buried beneath assumptions, misconceptions, and politics, sometimes not existing at all. The 'Requirements Myth' of exact up-front specifications arose when early computers were expensive and problems limited, but today, programmers are crucial in helping clients understand their true needs. Initial statements are invitations to explore; for instance, a request for 'free shipping on orders costing $50 or more' prompts detailed questions about tax inclusion, existing shipping charges, product types (e.g., paper books vs. ebooks), international orders, and future limit changes, uncovering critical nuances and potential system vulnerabilities like customers 'gaming' the system.

Requirements discovery is an ongoing feedback loop where developers interpret client statements and present consequences. This leads to an 'exploration' and refinement of thinking, often facilitated by mockups and prototypes, allowing clients to articulate what they 'meant' through interaction. To truly understand needs, developers should 'Work with a User to Think Like a User,' immersing themselves in client roles, such as monitoring help desk calls or working in a warehouse, which also builds trust. It is vital to distinguish 'requirements' (underlying semantic invariants) from 'policy' (business rules); for example, 'Only authorized users may access an employee record' is a requirement, while 'Only supervisors and the personnel department may view that employee’s records' is policy. Implementing general cases with policy as metadata allows for flexible systems that adapt to changes easily.

Working code is considered the best requirements documentation. Large, traditional requirements documents are generally ineffective as clients rarely read them, finding them too technical and boring. Instead, project planning benefits from short descriptions like user stories, often fitting on an index card. Their brevity encourages developers to ask clarifying questions, enhancing the feedback process. Overspecification must be avoided; requirements should be abstract, capturing the business need without dictating architecture, design, or user interface. To combat 'feature bloat' or 'requirements creep,' continuous feedback loops allow clients to directly experience the impact of new features, aiding prioritization. Maintaining a project glossary is essential for defining specific terms and ensuring consistent vocabulary among all project participants.