By William Nazzaro & Dr. Charles Suscheck
Having coached traditional requirements, use cases, user stories, and agile development, I’ve fielded a lot of questions around the differences among the three major ways of specifying requirements, particularly by people migrating to user stories. To set the record straight on requirements, use cases, and user stories, I will describe each methodology and then compare the three against each other.
Traditional requirements
Traditional requirements are criteria to which the system or business must adhere. They are usually created before the coding begins and are nearly always written as text. They often are thought of as constraints, conditions, or capabilities to which the system must conform.
Good requirements have the following characteristics:
- Complete. Requirements should be as complete as possible—no open-ended requirements.
- Testable. Must be able to create a test for all requirements.
- Consistent. Requirements must be consistent with each other—no conflicts.
- Design Free. Software requirements should be specified in the business perspective rather than the software perspective.
- Unambiguous. Use "shall" and other related words. Don’t be wishy-washy.
