I’m in the middle of teaching my Software Requirements Engineering course at UCSC Extension.\u00a0 On the first day of class, I always ask my students what problems they’re hoping to solve by coming to this class.\u00a0 Once again I was struck by the commonality of answers from students in all kinds and sizes of companies in the Valley:<\/p>\n
“My management won’t support the introduction of process\/project management into the company because they think:<\/p>\n
a.\u00a0\u00a0 it won’t be worth the time and money<\/p>\n
b.\u00a0\u00a0 we don’t have the time<\/p>\n
c.\u00a0\u00a0 we can’t spare the resources because we need them to work on Urgent Project X that is behind schedule<\/p>\n
d.\u00a0\u00a0\u00a0 it’s just a boondoggle for highly-paid consultants and managers<\/p>\n
e.\u00a0\u00a0\u00a0 yada yada yada”.<\/p>\n
It’s the same story over and over again.\u00a0 The students have a gut feeling that there must be something out there that can make their projects more successful (or at least less chaotic), but they are not supported by their management in their quest for answers in the project management world.<\/p>\n
My students are all engineers of one sort or another (software, testing, hardware), and I promised them (as I did students in my Software Project Planning, Monitoring, and Management course) that I would give them persuasive arguments to help them convince Management.<\/p>\n
Written Requirements<\/strong><\/em><\/p>\n So, once again, my students are telling me the same requirement stories:<\/p>\n \u00b7\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 “no one will write down project requirements for us”<\/p>\n \u00b7\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 “it even seems like they’re avoiding<\/em> writing them down”.<\/p>\n And the excuses they get from their management are a variation on those above:<\/p>\n \u00b7\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 “we don’t have time to write down requirements for you (it will delay the start of the project)”<\/p>\n \u00b7\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 “you know what we need, why do we have to write it down?”<\/p>\n \u00b7\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 “we can’t spare the resources (they’re busy starting the project)”<\/p>\n \u00b7\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 (and, my personal favorite) “they’ll just change anyway”.<\/p>\n The importance of software requirements for Engineering organizations is the typical list, obvious to many, but not so to all:<\/p>\n \u00b7\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 Makes sure the expectations of what the product will do is shared by all stakeholders<\/p>\n \u00b7\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 Makes sure the product is technically feasible<\/p>\n \u00b7\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 Forms the basis for work estimates and the schedule<\/p>\n \u00b7\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 Forms the basis for later testing<\/p>\n \u00b7\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 Forms the basis for change<\/p>\n These address why requirements<\/em> are important for Engineering, but doesn’t address why they should be written<\/em>.\u00a0 And the reasons for needing written<\/em> requirements strikes at the heart of some of the struggles getting them written down.\u00a0<\/p>\n Getting requirements written down (and ultimately signed off) is the way Engineering gets the writers (whoever that may be) to commit.\u00a0 And fear of commitment is, I believe, the primary thing that keeps potential writers from doing the writing.\u00a0 By committing the requirements to writing, and putting their signature on the document, the writers are saying “This is it.\u00a0 This is all.\u00a0 This is now perfect.\u00a0 Go forth and build.”<\/p>\n And for a multitude of reasons, they just can’t make themselves do that.<\/p>\n But written they must be.\u00a0 Perhaps\u00a0Management could see the\u00a0benefits to them<\/em>\u00a0of written requirements…<\/p>\n Helps with Marketing decisions.\u00a0 <\/strong>The more detailed product information that goes into written requirements helps Executive management and Marketing decide which projects to fund.<\/p>\n Provides Marketing material.\u00a0 <\/strong>Those screen shots and user scenarios can form the basis of excellent product data sheets.\u00a0 The writing that goes into good requirement descriptions leads to good customer-benefit text which\u00a0helps with\u00a0advertising text.<\/p>\n Will help<\/strong> meet critical delivery timelines <\/strong>because accurate work estimates lead to reliable scheduling.\u00a0\u00a0This should be a no-brainer, but, sadly, isn’t.<\/p>\n High quality, written requirements will lower the costs of developing and<\/em> maintaining<\/em> software and speed time to market <\/strong>because they will reduce rework.\u00a0 Explaining the costs of software rework isn’t always as easy as explaining the cost of tearing down and rebuilding part of a construction project, but with patience, it can be explained that way.\u00a0 Relating maintenance costs to technical support staff, interference with future new projects, and company reputation can be very helpful.<\/p>\n And a final one that should be used very carefully: <\/p>\n You can’t change what isn’t written down<\/strong>. \u00a0Recognizing that some change is inevitable, when the time comes to make a change, it really can’t be accomplished unless there’s something<\/em> to change.\u00a0 Following this up with a dialog about change management is usually a good idea here.<\/p>\n Build a good dialog around these points, and at least you can say you tried: <\/p>\n And, if all else fails, then you need to write the requirements down yourself.\u00a0 But that’s another topic.<\/p>\n Anita Wotiz \u00a0<\/p>\n","protected":false},"excerpt":{"rendered":" I’m in the middle of teaching my Software Requirements Engineering course at UCSC Extension.\u00a0 On the first day of class, […]<\/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":[2,7],"tags":[39,146,164,38,154,50,298],"class_list":["post-863","post","type-post","status-publish","format-standard","hentry","category-leadership","category-goals","tag-best-practices","tag-engineering-management","tag-everyone-wins","tag-project-management","tag-project-success","tag-requirements","tag-ucsc-extension"],"aioseo_notices":[],"jetpack_featured_media_url":"","_links":{"self":[{"href":"https:\/\/svapm.org\/index.php?rest_route=\/wp\/v2\/posts\/863","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=863"}],"version-history":[{"count":1,"href":"https:\/\/svapm.org\/index.php?rest_route=\/wp\/v2\/posts\/863\/revisions"}],"predecessor-version":[{"id":13918,"href":"https:\/\/svapm.org\/index.php?rest_route=\/wp\/v2\/posts\/863\/revisions\/13918"}],"wp:attachment":[{"href":"https:\/\/svapm.org\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=863"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/svapm.org\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=863"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/svapm.org\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=863"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
\nwww.duckpondsoftware.com<\/a>
\nInstructor, UCSC Extension, SEQ Program<\/a>
\nSoftware Requirements Engineering (next class Aug 2008)
\nSoftware Project Planning, Monitoring, and Management (next class Nov 2008)<\/p>\n