There is a set of SW practices that I consider non-negotiable, and they begin with 2 that are requirements-related:
\n1.\tWritten, reviewed, approved requirements
\n2.\tA requirements baseline, implemented with a requirements management (RM) tool<\/p>\n
In my last company, getting these done in a way that was accepted by engineers and management alike did require a pinch of \u201cwriting the requirements spec ourselves\u201d and a dash of \u201centering the spec into the RM baseline and doing the updates ourselves\u201d. That the CTO and I (the VP) were willing to do that work shows how important we deemed it as well as how easy our RM tool was to use (we used DOORS\u00ae).<\/p>\n
Many companies assign the spec writing task to Product Marketing (PM), and this is a fine place for it if there is someone there committed to do it \u201cright\u201d. We often had good specs from PM at our company. But sometimes there was information needed by engineering that was more easily discovered and input by one of us. This partnership between PM and the CTO\/VP served us well.<\/p>\n
The fact that our engineers wouldn\u2019t work on a requirement until the spec was updated in the DOORS\u00ae baseline is testament to how important the engineers felt this practice was (whether for the project or for themselves is almost irrelevant) and how well they bought in.<\/p>\n
Management too (including Marketing, Sales, everyone) accepted this process and knew that there was no way any feature would be implemented unless it appeared in the DOORS\u00ae baseline, either initially or by the formal change process.<\/p>\n
These requirement practices were made easier by the use of a formal RM tool, and I can\u2019t stress enough the importance of having one of these. Yes, RM tools can be expensive, but if you do the cost\/benefit tradeoff, buying one will win. There are open-source tools that might take more staff-power to implement than a commercial one, but that would still be preferable to trying to manipulate a word-processing or spreadsheet application into serving this role. <\/p>\n
The primary reason you need a formal RM tool is its ability to create attribute categories and assign attribute values for individual requirement objects. We created attributes for the assigned release, test information (needs testing, was tested, when tested, etc.), and change tracking (links into our change tracking tool). The release assignment (per requirement object) meant that we could maintain a single spec for a feature or product and not spec fragments per release. This might not seem important as you create version 1 and even version 2 of your product, but when you get to version 5 or 6, trust me, you\u2019ll wish you had some single requirements document that described the whole product.<\/p>\n
A second important benefit of an RM tool is the history it keeps (per requirement object). Tracing back the reason for changes can save tons of time later in research.<\/p>\n
But, if you are just starting out with a tiny team and don\u2019t have the time, energy, focus, money, etc. to acquire and use a formal RM tool, more important is to get the requirements written<\/em>, in something, and stored away somewhere accessible to everyone but changeable only by you. An RM tool can come later. You\u2019ll know when you need it, and remember, it\u2019s never too late to move to it.<\/p>\n These 2 requirement practices passed the \u201cpracticality\u201d test. Everyone understood their value, everyone bought into them, they had evangelists, and we made it all easy to implement.<\/p>\n Anita Wotiz There is a set of SW practices that I consider non-negotiable, and they begin with 2 that are requirements-related: 1. […]<\/p>\n","protected":false},"author":18,"featured_media":0,"comment_status":"open","ping_status":"open","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":[2,7,1],"tags":[39,11,38,50],"class_list":["post-1980","post","type-post","status-publish","format-standard","hentry","category-leadership","category-goals","category-miscellaneous","tag-best-practices","tag-implementing-project-management","tag-project-management","tag-requirements"],"aioseo_notices":[],"jetpack_featured_media_url":"","_links":{"self":[{"href":"https:\/\/svapm.org\/index.php?rest_route=\/wp\/v2\/posts\/1980","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=1980"}],"version-history":[{"count":1,"href":"https:\/\/svapm.org\/index.php?rest_route=\/wp\/v2\/posts\/1980\/revisions"}],"predecessor-version":[{"id":14219,"href":"https:\/\/svapm.org\/index.php?rest_route=\/wp\/v2\/posts\/1980\/revisions\/14219"}],"wp:attachment":[{"href":"https:\/\/svapm.org\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=1980"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/svapm.org\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=1980"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/svapm.org\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=1980"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
\nwww.duckpondsoftware.com<\/a> (see the Consulting tab)
\nInstructor, UCSC Extension in Silicon Valley
\nSoftware Requirements Engineering and Management<\/a> (next class Aug 2009)
\nSoftware Project Planning, Monitoring, and Management<\/a> (next class Oct\/Nov 2009)<\/p>\n","protected":false},"excerpt":{"rendered":"