{"id":1267,"date":"2021-06-17T12:31:00","date_gmt":"2021-06-17T12:31:00","guid":{"rendered":"http:\/\/janbosch.com\/blog\/?p=1267"},"modified":"2021-06-17T12:31:01","modified_gmt":"2021-06-17T12:31:01","slug":"outdated-belief-1-requirements-are-instrumental","status":"publish","type":"post","link":"https:\/\/janbosch.com\/blog\/index.php\/2021\/06\/17\/outdated-belief-1-requirements-are-instrumental\/","title":{"rendered":"Outdated belief #1: Requirements are instrumental"},"content":{"rendered":"\n
\"\"
Image by Steve Buissinne from Pixabay<\/figcaption><\/figure>\n\n\n\n

Building software-intensive systems from scratch is far from trivial. One of the main reasons is that it\u2019s hard to capture concisely and precisely what the system should look like in terms of functionality. Even if all stakeholders individually have a clear understanding of what they want, it doesn\u2019t mean that the expectations are aligned. In many cases, there are conflicting needs and wishes that need to be managed.<\/p>\n\n\n\n

Traditionally, this is addressed by embarking on a requirements \nelicitation process where the needs and wishes from all stakeholders are\n captured, conflicts are identified and resolved, resulting in a clear \nand crisp requirements specification that precisely states what the \nsystem should provide in terms of functional and non-functional \nbehavior.<\/p>\n\n\n\n

The challenge with requirements engineering is that it has at least \nthree inherent problems. First, the assumption that capturing \nrequirements and then building the system will result in everyone being \nhappy is fundamentally false as requirements change all the time. The \nrule of thumb in software engineering is that requirements change at a \nrate of 1 percent per month. For a complex system with 10,000 \nrequirements (not atypical for the industries I work in), that means 100\n new or changed requirements per month. Assuming a development project \nlasting 36 months (a typical car project), that means 3,600 new and \nchanged requirements \u2013 an overhaul of more than a third of the \nrequirements.<\/p>\n\n\n\n

Second, the assumption is that requirements can capture the required \nfunctionality of the system precisely. In practice, however, \nrequirements only capture a small part and 90 percent or more of what \nthe system should do is left to the interpretation of the engineers \nbuilding it. The standard response has been to write more elaborate \nspecifications, describing things in more detail. This doesn\u2019t work in \npractice as it only adds more statements that can be freely interpreted \nby others. It tends to lead to lots of discussion and disagreement \nconcerning the correct interpretation of each requirement.<\/p>\n\n\n\n

Third, requirements describe what customers think they want, but not \nwhat they really use and benefit from in practice. In requirements \nengineering, one of the cardinal rules is that requirements should \nspecify problem domain functionality and avoid describing solution \ndomain functionality. In practice, however, even the requirements in the\n problem domain already describe solutions based on stakeholder \nunderstanding of what a solution should look like. There\u2019s ample \nevidence of the gap between espoused theory (what people say they do) \nand theory-in-use (what people really do). Requirements tend to capture \nthe \u201cespoused\u201d theory as they\u2019re based on what stakeholders say they \nwant.<\/p>\n\n\n\n

So, the first outdated belief in software is that requirements matter\n and are critical for product success. As you might gather, I\u2019m not at \nall convinced that this is the case. So, what should we do instead? \nAlthough I won\u2019t provide a ready-made solution, the overall concept is \nto move away from the notion that the system is defined, built and put \nin operation, but to accept that any software-intensive system will be \nin perpetual beta, meaning it continues to evolve for its entire \neconomic life. In many domains, it\u2019s better to accept that the system\u2019s \nfull scope will only become clear over time, things change constantly \nand that there are better ways than upfront defined requirements to \nmanage the functionality growth. At least three principles go a long way\n to addressing this challenge.<\/p>\n\n\n\n

The first is to focus on outcomes rather than requirements. In earlier posts, I\u2019ve talked about value modeling<\/a> as an approach to describe what measurable outcomes we\u2019re looking to accomplish. Quantitatively described outcomes have several benefits over traditional requirements. First, the desired outcomes tend to be much more stable than requirements. Second, the preciseness of these outcomes forces any conflicts between stakeholders to surface so that these can be addressed and a decision can be made. Third, it forces stakeholders to put relative priorities on the desired outcomes, stating which ones are more important than others.<\/p>\n\n\n\n

The second principle is that if we accept that we can\u2019t know all the \nrequirements before the start of development and that some are even \nunknowable, it\u2019s much better to take an evolutionary approach with small\n steps. This allows us to take an experimental approach where rather \nthan talking about requirements, we use the notion of hypotheses. A \nhypothesis is an unproven statement about the world that can be tested \nwith an experiment. In our context, we state that building some \nfunctionality will have some measurable (and typically positive) impact \non one or more of our desired outcomes with an acceptable negative \nimpact on other outcomes. By building a slice of the functionality and \nmeasuring the effect, we can develop a better understanding of the \nrelationship between the functionality and the measurable impacts on \nsystem and user behavior. In earlier work, we developed the HYPEX model<\/a> that describes this in more detail.<\/p>\n\n\n\n

Third, in those cases where you can\u2019t get away from specifying the \nfunctionality of part of the system, capture the desired functionality \nin test cases that can be executed automatically. This approach is used \nin one of the Software Center companies and it works well for them. The \nmain reason for its success is twofold. First, it forces an in-depth \ndiscussion between stakeholders, product management and development so \nthat the waste due to rework is minimized. Second, as most companies use\n a continuous integration and test approach, once the test case is part \nof the test suite, any later changes to the system that cause the case \nto fail are captured immediately, causing immediate fixes. This ensures \ncontinuous feature growth without breaking existing functionality.<\/p>\n\n\n\n

I\u2019m of course aware that many industries, such as defense and automotive, have set up their business ecosystem interfaces based on requirements specifications and that changing this will take time. Still, also in these industries, the first examples of agile contracting and subscription models allowing for continuous approaches are appearing. So, we\u2019re moving away from the traditional requirements-driven approaches and adopting more continuous, outcome-based and data-driven ones. Where would you like to be? Desperately holding on to outdated beliefs and practices or proactively inventing the future? I know what I prefer!<\/p>\n\n\n\n

To get more insights earlier, sign up for my newsletter at <\/em>jan@janbosch.com<\/em><\/a> or follow me on<\/em> janbosch.com\/blog<\/em><\/a>, LinkedIn (<\/em>linkedin.com\/in\/janbosch<\/em><\/a>), Medium<\/a> or Twitter (<\/em>@JanBosch<\/em><\/a>).<\/em><\/p>\n","protected":false},"excerpt":{"rendered":"

Building software-intensive systems from scratch is far from trivial. One of the main reasons is that it\u2019s hard to capture concisely and precisely what the system should look like in terms of functionality. Even if all stakeholders individually have a clear understanding of what they want, it doesn\u2019t mean that the expectations are aligned. In … Read more<\/a><\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"generate_page_header":"","footnotes":""},"categories":[8,3,10],"tags":[],"_links":{"self":[{"href":"https:\/\/janbosch.com\/blog\/index.php\/wp-json\/wp\/v2\/posts\/1267"}],"collection":[{"href":"https:\/\/janbosch.com\/blog\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/janbosch.com\/blog\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/janbosch.com\/blog\/index.php\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/janbosch.com\/blog\/index.php\/wp-json\/wp\/v2\/comments?post=1267"}],"version-history":[{"count":1,"href":"https:\/\/janbosch.com\/blog\/index.php\/wp-json\/wp\/v2\/posts\/1267\/revisions"}],"predecessor-version":[{"id":1269,"href":"https:\/\/janbosch.com\/blog\/index.php\/wp-json\/wp\/v2\/posts\/1267\/revisions\/1269"}],"wp:attachment":[{"href":"https:\/\/janbosch.com\/blog\/index.php\/wp-json\/wp\/v2\/media?parent=1267"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/janbosch.com\/blog\/index.php\/wp-json\/wp\/v2\/categories?post=1267"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/janbosch.com\/blog\/index.php\/wp-json\/wp\/v2\/tags?post=1267"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}