Recent posts on the importance of usage scenarios (use cases or\u00a0user stories)\u00a0in the development process warmed my heart.\u00a0 In my experience, scenarios are perhaps the single most valuable practice in the process.\u00a0 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.<\/p>\n
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.\u00a0 Specifically, the author was voicing concerns about how to handle them in traceability matrices.\u00a0 I personally think it’s a non-issue, and I thought I’d spend a minute saying why.<\/p>\n
Scenarios are absolutely critical, and yes, they do need to be included in requirement documents.\u00a0 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.\u00a0 The requirement document’s change control process will ensure this will happen.<\/p>\n
But the scenarios are not the actual<\/em> requirement statements.\u00a0 They describe how<\/em> the system\/product will be used to solve a specific<\/em> user problem, but because each one describes only a single path through the product, they should not be the ultimate requirement statement.\u00a0<\/p>\n Consider them cases that should be tested to ensure that what was expected by the user was implemented in the product.\u00a0\u00a0 Grouping them together in a “Usage Scenarios” section of the document can clarify their status.<\/p>\n Consider a requirements document for a system implemented with many user screens.\u00a0 Screen mockups are critical.\u00a0 They can be tweaked as the development progresses, but things link consistency and standardized look and feel are important to convey to everyone.\u00a0 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.\u00a0 Each of these requirement statements should be traced to a test.<\/p>\n 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.\u00a0 It won’t describe all the possible choices on each screen or what happens in error situations.\u00a0 To have scenarios for every combination, hitting every possibility on every screen is pretty unrealistic.<\/p>\n So, scenarios augment<\/em> the requirement statements, but they don’t replace them.<\/p>\n Each scenario will become a test, and each scenario should be traced to a test to make sure that the product works as agreed.\u00a0 But don’t worry about tracing each step of a scenario to a test.<\/p>\n Anita Wotiz Recent posts on the importance of usage scenarios (use cases or\u00a0user stories)\u00a0in the development process warmed my heart.\u00a0 In my […]<\/p>\n","protected":false},"author":18,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"give_campaign_id":0,"site-sidebar-layout":"default","site-content-layout":"","ast-site-content-layout":"default","site-content-style":"default","site-sidebar-style":"default","ast-global-header-display":"","ast-banner-title-visibility":"","ast-main-header-display":"","ast-hfb-above-header-display":"","ast-hfb-below-header-display":"","ast-hfb-mobile-header-display":"","site-post-title":"","ast-breadcrumbs-content":"","ast-featured-img":"","footer-sml-layout":"","ast-disable-related-posts":"","theme-transparent-header-meta":"","adv-header-id-meta":"","stick-header-meta":"","header-above-stick-meta":"","header-main-stick-meta":"","header-below-stick-meta":"","astra-migrate-meta-layouts":"default","ast-page-background-enabled":"default","ast-page-background-meta":{"desktop":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"tablet":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"mobile":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""}},"ast-content-background-meta":{"desktop":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"tablet":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"mobile":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""}},"footnotes":""},"categories":[7],"tags":[39,50,359,336,298,377,367,368],"class_list":["post-1102","post","type-post","status-publish","format-standard","hentry","category-goals","tag-best-practices","tag-requirements","tag-specifications","tag-sw-development","tag-ucsc-extension","tag-usage-scenarios","tag-use-cases","tag-user-stories"],"aioseo_notices":[],"jetpack_featured_media_url":"","_links":{"self":[{"href":"https:\/\/svapm.org\/index.php?rest_route=\/wp\/v2\/posts\/1102","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/svapm.org\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/svapm.org\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/svapm.org\/index.php?rest_route=\/wp\/v2\/users\/18"}],"replies":[{"embeddable":true,"href":"https:\/\/svapm.org\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=1102"}],"version-history":[{"count":1,"href":"https:\/\/svapm.org\/index.php?rest_route=\/wp\/v2\/posts\/1102\/revisions"}],"predecessor-version":[{"id":14046,"href":"https:\/\/svapm.org\/index.php?rest_route=\/wp\/v2\/posts\/1102\/revisions\/14046"}],"wp:attachment":[{"href":"https:\/\/svapm.org\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=1102"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/svapm.org\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=1102"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/svapm.org\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=1102"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
\nwww.duckpondsoftware.com<\/a> (see the Consulting tab)
\nInstructor, UCSC Extension, SEQ Program<\/a>
\nSoftware Requirements Engineering and Management<\/a> (next class starts Aug 5 2008)
\nSoftware Project Planning, Monitoring, and Management<\/a> (next class Oct\/Nov 2008)<\/p>\n","protected":false},"excerpt":{"rendered":"