{"id":5449,"date":"2014-02-06T10:23:40","date_gmt":"2014-02-06T16:23:40","guid":{"rendered":"http:\/\/www.watermarklearning.com\/blog\/?p=5449"},"modified":"2022-07-14T14:45:05","modified_gmt":"2022-07-14T19:45:05","slug":"requirements-vs-design-does-it-really-matter","status":"publish","type":"post","link":"https:\/\/www.watermarklearning.com\/blog\/requirements-vs-design-does-it-really-matter\/","title":{"rendered":"Requirements vs. Design \u2013 Does it Really Matter?"},"content":{"rendered":"<p><strong>By Richard Larson and Elizabeth Larson<\/strong><\/p>\n<p>This post is an abridged version of an article to be published soon.<\/p>\n<p>Much has been written recently about design in the business analysis field. Some writers have even suggested that since most or all of what we do is about design, then requirements don&#8217;t matter anymore. It is popular &#8211; even exciting perhaps &#8211; for BAs to think of ourselves as designers, since much of the work we do results in solutions. We don\u2019t disagree with the trend and the main concern prompting us to write this article is to point out the importance of including the \u201cas is\u201d state as part of any requirements \u2013 or should we say design &#8211; effort.<\/p>\n<p>Part of the impetus for the new design focus has been a strong aversion by some in the Agile community to business analysts or business analysis. Those who feel strongly tend to concentrate on the design aspects of a new product and don\u2019t see the need for much if any actual analysis of the business or business need. (See Tony Heap\u2019s blog <span style=\"text-decoration: underline;\">its-all-design.com<\/span> for an example (1). If business analysts are now just designers and we need little analysis, we are moving back to the earlier systems analyst role. This does not always serve our organization well. To say that we don\u2019t need to worry about requirements is missing the essence of what a business analyst can and should be.<\/p>\n<p>Let\u2019s walk through some reasons why the emphasis on design over analysis is an issue. Being only or mostly interested in \u201cdesign\u201d implies that we don\u2019t care about the \u201cas is\u201d state anymore, as is suggested in recent articles, blogs, and discussion groups. (See David Morris\u2019 article in <em>BA Times <\/em>(2). Without understanding the current situation, we cannot hope to understand:<\/p>\n<ul>\n<li>How end-users\u2019 jobs will change with the implementation of the new product or product increment. If we do not know the extent of the change we cannot help workers adapt to the change, which increases the risk of lack of buy-in, unhappiness, and even possible sabotage.<\/li>\n<li>Which of the issues with the \u201cas-is\u201d need to be addressed. If we implement new processes and systems without curing existing ills, we will lose credibility.<\/li>\n<li>No new product or solution is devoid of the current state. That means we will have requirements that must be met \u2013 not designs &#8211; to ensure the new solution contains existing functionality that works and without which the new product cannot perform adequately.<\/li>\n<li>In addition, most of us work on projects that are not entirely new products, but replacements and enhancements of existing systems or processes. These efforts need plenty of analysis of the \u201cas is\u201d state and its corresponding requirements to make sure the changes we bring will fit into the rest of the business operation.<\/li>\n<li>Even for brand new products, there are many business rules and decisions that apply across projects and should be taken into account for the project at hand.<\/li>\n<li>The <i>BABOK\u00ae Guide<\/i> version 3 talks about requirements being the representation of a need and design as a representation of a solution. That is a workable distinction, although it is a bit awkward to talk about \u201cdesigns\u201d at the same level as requirements. To understand the distinction better, it helps to substitute the words for the <i>process<\/i> instead of the <i>outputs<\/i>:\n<ul>\n<li><b>Analysis<\/b> is understanding the needs and requirements and communicating them to the appropriate audience.<\/li>\n<li><b>Design<\/b> is how new features and functions will be incorporated into a solution, plus maintaining existing requirements that should be kept in the new solution.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<p>The last point is perhaps our biggest concern with the new thinking. The business analysis community has fought for years to keep analysis distinct from technical design. In the end, Elizabeth and I don\u2019t care that fashioning a solution is called design. After all, what is now being called design is nothing different from calling the output of the process \u201cTo-be\u201d requirements.<\/p>\n<p>To illustrate our point, consider Figure 1.&nbsp; The example might be a typical enhancement to an existing system or process. In the traditional business analysis approach, the \u201cas-Is\u201d state is analyzed as a starting point to capture processes, data, and interactions that must be kept for any new solution. Those are \u201cas-is\u201d requirements.<\/p>\n<p>The \u201ccurrent state to be retained\u201d in the \u201cDesign\u201d box below are also requirements. They could be processes, data, or user and system interfaces. The design process comes into play when determining how to integrate them with the new features being added. Those new features could equally be called \u201cTo Be\u201d requirements as well as design.<\/p>\n<p style=\"text-align: center;\"><a href=\"https:\/\/www.watermarklearning.com\/blog\/wp-content\/uploads\/2014\/02\/reqs-vs.design2.png\"><img loading=\"lazy\" decoding=\"async\" class=\"alignnone size-large wp-image-5469\" alt=\"reqs-vs.design2\" src=\"https:\/\/www.watermarklearning.com\/blog\/wp-content\/uploads\/2014\/02\/reqs-vs.design2-1024x315.png\" width=\"584\" height=\"179\" srcset=\"https:\/\/www.watermarklearning.com\/blog\/wp-content\/uploads\/2014\/02\/reqs-vs.design2-1024x315.png 1024w, https:\/\/www.watermarklearning.com\/blog\/wp-content\/uploads\/2014\/02\/reqs-vs.design2-300x92.png 300w, https:\/\/www.watermarklearning.com\/blog\/wp-content\/uploads\/2014\/02\/reqs-vs.design2-500x154.png 500w, https:\/\/www.watermarklearning.com\/blog\/wp-content\/uploads\/2014\/02\/reqs-vs.design2.png 1216w\" sizes=\"auto, (max-width: 584px) 100vw, 584px\" \/><\/a><\/p>\n<p>Examples of \u201cTo Be\u201d requirements (or design if you prefer) include many traditional BA outputs including:<\/p>\n<ul>\n<li>Process models showing an \u201cAs Is\u201d as well as a new business process.<\/li>\n<li>Data models showing \u201cTo Be\u201d data requirements and business rules relating to the relationships between entities.<\/li>\n<li>Use Case models with interaction requirements and corresponding business rules.<\/li>\n<li>Prototypes and mock-ups indicating interface requirements.<\/li>\n<li>Interfaces with other systems.<\/li>\n<\/ul>\n<p><strong>SUMMARY<\/strong><\/p>\n<p>In the end as long as we are talking about \u201clogical\u201d design and not technical or physical design, the authors agree with the current trend calling BAs designers. In actuality, BAs have always been designers because we help people conceptualize and visualize solutions that will help businesses meet goals and objectives through solutions. As long as we don\u2019t forget the importance of \u201cAs Is\u201d and \u201cTo Be\u201d requirements and the part they both play in any solution, then emphasizing design over requirements becomes to us an academic argument.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>By Richard Larson and Elizabeth Larson This post is an abridged version of an article to be published soon. Much has been written recently about design in the business analysis field. Some writers have even suggested that since most or all of what we do is about design, then requirements don&#8217;t matter anymore. It is [&hellip;]<\/p>\n","protected":false},"author":3,"featured_media":10403,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"content-type":"","site-sidebar-layout":"default","site-content-layout":"","ast-site-content-layout":"","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":"","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":"var(--ast-global-color-4)","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":[1],"tags":[],"coauthors":[138],"class_list":["post-5449","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-watermark-learning"],"_links":{"self":[{"href":"https:\/\/www.watermarklearning.com\/blog\/wp-json\/wp\/v2\/posts\/5449","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.watermarklearning.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.watermarklearning.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.watermarklearning.com\/blog\/wp-json\/wp\/v2\/users\/3"}],"replies":[{"embeddable":true,"href":"https:\/\/www.watermarklearning.com\/blog\/wp-json\/wp\/v2\/comments?post=5449"}],"version-history":[{"count":19,"href":"https:\/\/www.watermarklearning.com\/blog\/wp-json\/wp\/v2\/posts\/5449\/revisions"}],"predecessor-version":[{"id":10404,"href":"https:\/\/www.watermarklearning.com\/blog\/wp-json\/wp\/v2\/posts\/5449\/revisions\/10404"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.watermarklearning.com\/blog\/wp-json\/wp\/v2\/media\/10403"}],"wp:attachment":[{"href":"https:\/\/www.watermarklearning.com\/blog\/wp-json\/wp\/v2\/media?parent=5449"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.watermarklearning.com\/blog\/wp-json\/wp\/v2\/categories?post=5449"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.watermarklearning.com\/blog\/wp-json\/wp\/v2\/tags?post=5449"},{"taxonomy":"author","embeddable":true,"href":"https:\/\/www.watermarklearning.com\/blog\/wp-json\/wp\/v2\/coauthors?post=5449"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}