When to use User Stories, Use Cases and IEEE 830 – Part 3: Requirement Statements

Requirement statements that begin with the phrase “The system shall” are often referred to as IEEE style statements, because they were recommended  for specifying software requirements in IEEE standard 830, and still are in 29148:2011.

The IEEE standard for software requirements specification recommends this method as they have many advantages  Continue reading

When to use User Stories, Use Cases and IEEE 830 – Part 2: Use Cases

I find use cases extremely valuable for eliciting requirements. Focusing the discussion on the business process with an informal use case, where each step is simply a bullet point and we don’t worry about using correct use case terminology, makes it much easier to keep conversation on track and productive and helps clarify and avoid misunderstandings that often occur between stakeholders and development staff in requirements discussions. Continue reading

When to use User Stories, Use Cases and IEEE 830 – Part 1

A hammer is good for nails, not so good for fixing televisions. A scooter is the best way to get around town, unless you’re in Montreal in January. Choosing one method to describe the customer’s need across projects, teams and environments actually hinders good analysts, architects and developers as much as it helps. What is much more valuable is having an analyst who understands and has the ability to use all of the tools, and relying on her to work with her team to decide whether to hammer the nail or take the subway.

Use Cases, IEEE 830 style “The system shall…” requirement statements, and User Stories each have advantages and disadvantages. A good analyst, or project manager, should know the advantages and have the ability to choose which is most appropriate for the project. Continue reading