Requirements describe what a product, feature, or project needs to achieve. Business or functional requirements give developers a basis for building a system; technical requirements guide the development work. A lead developer may write technical requirements for assigned tasks or work from requirements supplied by an architect. section 1.1.3
Before designing a solution, clarify the business need with clients and check that the team agrees on it. Ask why the feature matters, not only how to build it. Starting from vague descriptions can invite scope creep or leave problems undiscovered until implementation. section 1.2.3 section 6.5.1
Use requirements throughout the project, not just at kickoff:
- Before implementation, push back on insufficient product requirements and agree on a standard for what the team needs to know. Think through the technical design and document it. section 6.5.1
- Before estimating, understand the requirements and scope, break the work into tasks, and revise estimates when necessary. section 7.2.1
- When budgeting, clarify features, performance criteria, and deployment needs so time and resource estimates reflect the technical work. section 12.3.1
- During testing, document technical requirements and work with QA to check that the result matches them. section 1.2.2
A client presentation that missed the mark
A lead developer presented a technical approach without noticing that the client’s technical expert had already outlined ideas. The client challenged much of the presentation. Discussing the missed requirements helped the teams get back on track. Play back your understanding of the problem and reach agreement before presenting a solution. section 8.2.3
Requirements should also reflect the wider project: business goals, audience, timelines, and constraints. On an enterprise web project, meeting the project manager first helped a lead developer tailor technical requirements to business objectives. section 12.2.2
