Recent posts on the importance of usage scenarios (use cases or user stories) in the development process warmed my heart. In my experience, scenarios are perhaps the single most valuable practice in the process. Scenarios help clarify requirements for everyone, ensuring that the ultimate user knows what they’re getting, guiding the developer, and forming the basis of tests for the quality and test engineer.
When I was doing research for course material, I noticed some concerns published in IEEE Software about how to handle usage scenarios in requirement documents. Specifically, the author was voicing concerns about how to handle them in traceability matrices. I personally think it’s a non-issue, and I thought I’d spend a minute saying why.
Scenarios are absolutely critical, and yes, they do need to be included in requirement documents. If scenarios change, this usually means there must be changes elsewhere in the requirement document, and developers and testers need to know about these changes. The requirement document’s change control process will ensure this will happen.
But the scenarios are not the actual requirement statements. They describe how the system/product will be used to solve a specific user problem, but because each one describes only a single path through the product, they should not be the ultimate requirement statement.
Consider them cases that should be tested to ensure that what was expected by the user was implemented in the product. Grouping them together in a “Usage Scenarios” section of the document can clarify their status.
Consider a requirements document for a system implemented with many user screens. Screen mockups are critical. They can be tweaked as the development progresses, but things link consistency and standardized look and feel are important to convey to everyone. Data fields, pull-down menus, buttons, pop-ups, error messages, etc. need to be explained in text to ensure that the developer builds what’s expected and testers know what to test. Each of these requirement statements should be traced to a test.
For their part, each usage scenario is a path through those requirements that illustrates how the product is to be used to perform a specific task, describing the user action on each screen, in sequence. It won’t describe all the possible choices on each screen or what happens in error situations. To have scenarios for every combination, hitting every possibility on every screen is pretty unrealistic.
So, scenarios augment the requirement statements, but they don’t replace them.
Each scenario will become a test, and each scenario should be traced to a test to make sure that the product works as agreed. But don’t worry about tracing each step of a scenario to a test.
www.duckpondsoftware.com (see the Consulting tab)
Instructor, UCSC Extension, SEQ Program
Software Requirements Engineering and Management (next class starts Aug 5 2008)
Software Project Planning, Monitoring, and Management (next class Oct/Nov 2008)