Slide Deck: Requirements Engineering
Once a requirements engineer has gathered all the information they need from the stakeholders (well… at least for now…), it is now their job to communicate those requirements to the developers.
The exact method of this will vary greatly depending on how likely the requirements are to change. If the requirements could change frequently as more information is gathered from stakeholders (either due to feedback or a change in needs), then the specification technique will be more informal. This could be as simple as a large wall with Post-It notes on it and a feature written on each note. Yes, some very agile projects work this way and things are just fine because there is extensive communication with the stakeholders to determine if the features are being developed correctly. There is, in effect, a living requirements discussion.
For larger projects where requirements won’t change much (if at all) and you are trying to keep a large team in sync, you will often use a more formal technique, such as a Software Requirements Specification (SRS).
A technique that is somewhat in between agile and plan-drive (and often used in both) is user stories. User stories first came out of Extreme Programming as one of the 12 practices - “The Planning Game.” The original idea was to merge requirements elicitation and specification into a single process. Today, user stories are a common way to communicate basic requirements without extensive documentation, but enough information that they can be easily communicated. Numerous software tools have emerged around user stories to provide a platform for digitally maintaining these artifacts.
Related to user stories (and sometimes lumped in with them) are use cases and, by extension, UML (Unified Modeling Language) diagrams. While user stories are generally single-sentence representations of a requirement, a use case with a UML diagram is a visual representation of a user interaction with a system. It is not uncommon to see these techniques mixed together to create a requirements artifact that is not as overly detailed as an SRS, but more than a list of notes on a whiteboard.
Links