Requirements Gathering
Agile process
Agile doesn't mean no documentation, it means just enough documentation.
Discovery/UX/Design Phases
It's important to start capturing requirements in the form of user stories or another format ("The system shall...") early on for client and team approval.
These will turn into more detailed requirements once the annotations are complete and the team has discussed the work during planning. These can be captured in Jira, Excel, or any other tool.
Wireframes
Wires are needed so that all parties understand what needs to be built and how the site will generally function.
From the wires, user stories can be written with initial acceptance criteria.
Annotations
Who needs annotations? Every single person on the team, including the client. PM's need them to write and track acceptance criteria, QA uses them to write test cases, developers need them to understand what they're building. Annotations are typically the main document all will refer to during the project. These must be kept up to date when changes occur.
Visual Designs
Once wires and annotations are complete, the visual designs are the final piece needed before detailed requirements and development can begin. Design can show functionality not displayed in the wireframes.
Acceptance Criteria
Acceptance criteria are the requirements that need to be met before a story is considered "done". Acceptance criteria are written in a pass/fail format and answer the question, "How will we know when it does what it should do?"
Definition of Done
This is very important to clarify with the team before development begins. The DOD can vary by team. Below is an example:
• Story is coded
• Code is unit tested
• Code passes Peer Review
• Story passes QA engineer
• Acceptance criteria met and approved by product owner
Sprint Planning
Once the user stories and acceptance criteria are written, then the rest of the requriements come during team conversation in the planning session.
During planning, the "how" comes into play. Once the team discusses how they need to implement, the acceptance criteria are updated along with additional notes. You now have a complete user story with requirements.
QA
During a sprint, testing happens in parallel. The test cases are written from a combination of the acceptance criteria, annotations, and visual designs. All of these documents must be kept up to date so testing is accurate.
Tying it all together
• Need single source of truth for requirements
• Links to designs, annotations in each user story
• Acceptance criteria in each user story
• Be clear in every user story where the developer can find the functionality in documents referenced
