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.
Anita Wotiz
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)
Yes, I think we’re on the same page. I didn’t mean to get rid of them, just not worry too much about making updates due to changes in requirements or test scripts.
The original scenarios used in requirements gathering may come in handy later, like you said. It may be useful to take an original scenario and update it to reflect new functionality….doing that may help clarify the need and how they want it to function, and thus help revise the requirements.
I really enjoy using use case scenarios, even when it’s not for software. It’s a great way to visually depict what the customer wants, how it should work, and how people will interact with it. I’ve used this whether it’s a process, a document, software, etc. I’ll usually sit down with them and create the use case scenarios while they are there with me. It’s a really good way to get on the same page and have it well documented too.
Josh Nankivel
http://www.PMStudent.com
I think using the scenario steps as a double-check to make sure that everything necessary is covered in requirement statements is important, perhaps without a formal “matrix trace”, however. But that might be what you meant.
Once the scenario has been turned into a test, it is redundant, but I’d keep it around. It’s the agreement between the PM, user/customer, and development, and tests can be easily changed as they’re rarely under change control. It’s a good historical record.
Great post! I can see not worrying about tracing steps in a use case directly to a test, but wouldn’t you want traceability from the scenario to the requirements, and then between the requirements and test scripts? If so, then you get indirect traceability.
Scenario >> Requirements >> Test
In practice, I think some might build the scenarios only to facilitate the requirements gathering and generating test scripts. After requirements and test scripts are baselined, they might chuck the scenarios out, since the essence of them are now covered within the configuration-controlled requirements and test scripts.
Is that what you mean?
Josh Nankivel
http://www.PMStudent.com