Writing requirements is easy.
Writing GOOD requirements, tight User Stories, detailed Design Documents that:
– is easily understood
– is easy to write test cases for
– is robust enough to withstand scrutiny
– limit discussions about scope and interpretation
Well written requirements, following detailed workshops, capture the crux of the issues faced by the business and is able to articulate the best-fit solution(s).
Let’s say the business wants to display data from external systems within the system console
Not detailing performance needs or reportability means that we can approach this in quite a few ways, many of which will not be satisfactory to customer.
Unclear Acceptance Criteria results in time spent ‘clarifying’ the ambiguity, and can also cost much effort, money and goodwill.
Learn to write GOOD requirements.
This is particularly important for Consulting Partners, who generally gets one shot at this (during Discovery for a greenfield client) as this forms the basis of estimation and SoW costs.
After that… amendments become Change Requests.
And arguing about what constitutes a Change Request is about as much fun as wisdom tooth extraction. Without anesthetics. 😖