{"id":9004111223054294,"date":"2007-08-10T04:00:00","date_gmt":"2007-08-10T04:00:00","guid":{"rendered":"https:\/\/www.pragmaticinstitute.com\/uncategorized\/prioritizing-software-requirements-with-kano-analysis\/"},"modified":"2007-08-10T04:00:00","modified_gmt":"2007-08-10T04:00:00","slug":"prioritizing-software-requirements-with-kano-analysis","status":"publish","type":"resources","link":"https:\/\/www.pragmaticinstitute.com\/resources\/articles\/product\/prioritizing-software-requirements-with-kano-analysis\/","title":{"rendered":"Prioritizing Software Requirements with Kano Analysis"},"content":{"rendered":"<p>Noriaki Kano developed the Kano analysis model in the late 1980s to identify and contrast essential customer requirements from incremental requirements. One of his goals was to initiate critical thinking about the nature of requirements. His characterization approach can be used to drive prioritization of software requirements.<\/p>\n<p>Kano analysis allows us to prioritize requirements as a function of customer satisfaction.<\/p>\n<p>Kano defined four categories into which each feature or requirement can be classified (an Apple\u00ae iPod\u00ae is used for examples in each of the following four requirement categories):<\/p>\n<ol>\n<li><strong><em>Surprise and delight.<\/em><\/strong> Capabilities that differentiate a product from its competition (e.g. the iPod nav-wheel).<\/li>\n<li><strong><em>More is better. <\/em><\/strong>Dimensions along a continuum with a clear direction of increasing utility (e.g. battery life or song capacity).<\/li>\n<li><strong><em>Must be.<\/em><\/strong> Functional barriers to entry\u2014without these capabilities, customers will not use the product (e.g. UL approval).<\/li>\n<li><strong><em>Better not be.<\/em><\/strong> Represents things that dissatisfy customers (e.g. inability to increase song capacity via upgrades).<\/li>\n<\/ol>\n<h2><em>Surprise and delight <\/em>requirements<\/h2>\n<p>For just a moment, think about software as a user, not an accountant. We want software that is interesting and fun to use. Affordances in the user interface that allow us to just \u201cdo what comes naturally\u201d and have the software do exactly what we want. New ideas that make software better. We\u2019re not talking about a button that pops up dancing squirrels when clicked, rather valuable features that make software great.<\/p>\n<p>Great examples of valuable features include:<\/p>\n<ul>\n<li>The nav-wheel on the iPod, as a good hardware example.<\/li>\n<li>Google\u2019s Gmail\u2122 use of labels instead of folders for organizing email, as a good software example.<\/li>\n<li>Contextual help buttons that open to exactly the right page in a Help file.<\/li>\n<\/ul>\n<p>All of the examples above are <em>implementation details<\/em> or the results of design decisions\u2014not part of specifying requirements. However, when converting from market requirements to product requirements, we can point our development teams in the right direction and help them focus on innovative solutions to the right problems. These might be the requirements behind the delightful features listed above.<\/p>\n<ul>\n<li>Users must be able to select songs while holding the iPod in one hand.<\/li>\n<li>The system must provide an efficient way to organize email, with the assumption that users will never delete email.<\/li>\n<li>The system shall provide relevant help information for the context in which the user requests help.<\/li>\n<\/ul>\n<h2 style=\"margin-top: 40px;\"><em>More is better <\/em>requirements<\/h2>\n<p>These are the most easily grasped concepts\u2014bigger, faster, better, stronger. The challenge in writing a <em>more is better<\/em> requirement is in knowing when enough is enough. Requirements such as \u201cminimize\u201d or \u201cmaximize\u201d are ambiguous. What is the theoretical minimum response time for a search engine? Does it take a few hundred micro-seconds for the bits to travel from the server to the user, plus a few micro-seconds for switch latency, plus a few nano-seconds for a CPU to find the answer? It would be completely impractical to unambiguously request that our developers minimize search time.<\/p>\n<p>Specifying precise objectives can be very difficult as well. The law of diminishing returns comes into play. There is a concept in economics called <em>utility <\/em>which represents the tangible and intangible benefits of something. We can consider the utility of a feature with respect to the target users. A graph of the utility for <em>speed of search-result generation<\/em> would look like this:<\/p>\n<p><a href=\"https:\/\/www.pragmaticinstitute.com\/wp-content\/uploads\/2020\/05\/ss1.jpg\"><img decoding=\"async\" class=\"aligncenter wp-image-1988 size-full\" src=\"https:\/\/www.pragmaticinstitute.com\/wp-content\/uploads\/2020\/05\/ss1.jpg\" alt=\"increasing utility with speed\" width=\"175\" height=\"175\" srcset=\"https:\/\/www.pragmaticinstitute.com\/resources\/wp-content\/uploads\/sites\/6\/2020\/05\/ss1.jpg 175w, https:\/\/www.pragmaticinstitute.com\/resources\/wp-content\/uploads\/sites\/6\/2020\/05\/ss1-150x150.jpg 150w\" sizes=\"(max-width: 175px) 100vw, 175px\" \/><\/a><\/p>\n<p>We can see that as the speed of results increases, the incremental benefit to the user decreases. While utility is strictly increasing, it is increasing by less and less. When writing a requirement, how do we determine the speed that is truly required? It would be ambiguous to say \u201cas fast as possible\u201d or \u201cas fast as is reasonable.\u201d And it would be naive to think that we did not need to understand something about the implementation before specifying an unambiguous requirement like \u201csearch must complete in 2 seconds.\u201d<\/p>\n<p>Thus far, we have only described the <em>benefit<\/em> side of the <em>cost-benefit analysis<\/em> needed to specify the requirement. We have to <em>iterate and interact<\/em> with our development team to determine the impact of a speed specification on costs. After getting feedback from our implementation team, we now have an understanding of the cost of implementing \u201csearch,\u201d as shown below:<\/p>\n<p><a href=\"https:\/\/www.pragmaticinstitute.com\/wp-content\/uploads\/2020\/05\/ss1.jpg\"><img decoding=\"async\" class=\"aligncenter wp-image-1988 size-full\" src=\"https:\/\/www.pragmaticinstitute.com\/wp-content\/uploads\/2020\/05\/ss2.jpg\" alt=\"cost versus speed diagram\" width=\"175\" height=\"175\" \/><\/a><\/p>\n<p>We can see how it gets progressively more expensive to make progressively smaller increases in speed. This is our \u201cdevelopment reality\u201d and we can\u2019t ignore it when specifying how fast \u201csearch\u201d needs to be. To determine the optimal specification, we have to find the point in the curves where the incremental benefit of searching faster is equal to the incremental cost of searching faster. We can do that by graphing utility versus cost as shown below:<\/p>\n<p><a href=\"https:\/\/www.pragmaticinstitute.com\/wp-content\/uploads\/2020\/05\/ss1.jpg\"><img decoding=\"async\" class=\"aligncenter wp-image-1988 size-full\" src=\"https:\/\/www.pragmaticinstitute.com\/wp-content\/uploads\/2020\/05\/ss1.jpg\" alt=\"utility versus cost\" width=\"175\" height=\"175\" srcset=\"https:\/\/www.pragmaticinstitute.com\/resources\/wp-content\/uploads\/sites\/6\/2020\/05\/ss1.jpg 175w, https:\/\/www.pragmaticinstitute.com\/resources\/wp-content\/uploads\/sites\/6\/2020\/05\/ss1-150x150.jpg 150w\" sizes=\"(max-width: 175px) 100vw, 175px\" \/><\/a><\/p>\n<p>The circle in the graph above shows the point where the slope of the curve equals 1. At this point in the curve, an additional increase in speed provides less benefit than the associated increase in cost. At any point to the left of the circle, we are \u201cleaving money on the table\u201d because there is a better point to the right. This is the optimal speed to specify.<\/p>\n<h2>Reality check<\/h2>\n<p>In the real world, we will not have the precise data that allows us to draw these graphs and quantitatively identify the Pareto optimal point on the cost-benefit curve. It is important to understand the fundamental principles of the trade off so that we can make informed decisions and judgment calls.<\/p>\n<p>Some analyses will be relatively easy, as our development curves are usually discrete data points based on estimates of the work required to implement particular designs. We also won\u2019t have access to the full spectrum of design choices, because we will be limited by other constraints on the system as well as the creativity and capabilities of our development team in proposing alternatives.<\/p>\n<h2><em>Must be <\/em>requirements<\/h2>\n<p><em>Must be <\/em>requirements are the easiest to elicit and are the ones that most people consider when they talk about requirements.<\/p>\n<p>Stakeholders can usually tell us what they <em>must<\/em> have in the software. In the <em><a href=\"http:\/\/tynerblain.com\/blog\/2006\/02\/17\/prioritizing-software-requirements-am-i-hot-or-not\/\" target=\"_blank\" rel=\"noopener noreferrer\">Am I hot or not?<\/a> <\/em>post on requirements prioritization<em>,<\/em> the company 37signals focuses on this as its primary criterion for inclusion in a software initial release. They choose to only put essential, or <em>must be<\/em> requirements, into the initial release of software.<\/p>\n<h2><em>Better not be <\/em>requirements<\/h2>\n<p>This is just the opposite of <em>surprise and delight.<\/em> If dreamers think about what makes something great, then critics complain about what holds it back. This bucket does not have a place in Kano\u2019s analysis. Saying, \u201cUsers don\u2019t like confusing navigation,\u201d does not provide any benefit relative to saying, \u201cUsers prefer intuitive navigation.\u201d We suggest not using this category at all.<\/p>\n<h2>Apply the Kano techniques to make good prioritization decisions<\/h2>\n<ol>\n<li>Are our 1.0 release requirements all<em> must be <\/em>requirements?.<\/li>\n<li>When we specify<em> more is better <\/em>requirements, are they unambiguous, and are they optimal\u2014or at least practical?<\/li>\n<li>Do we have any<em> surprise and delight <\/em>requirements that will enable us to create an innovative product?<\/li>\n<\/ol>\n<h2>Using Kano analysis to prioritize requirements<\/h2>\n<p>The first release of the software should primarily include<em> must be <\/em>requirements.<\/p>\n<p>We talked about how 37signals and other companies have taken the \u201cmore is less\u201d approach to releasing their software. The first releases (or beta releases, which has become the misnomer du jour) of successful products have focused the majority of their efforts towards achieving these highest priority requirements.<\/p>\n<p>This trend has evolved because of what used to be called \u201cInternet time.\u201d Products are being released more quickly by startups, skunk-works, and other teams operating in Agile development environments. The dot-bomb generation of software developers has almost a decade of experience now, and is increasingly influencing company decision making, with the benefits of lessons learned about hype and substance. These teams and leaders are driving \u201crelevant and differentiated\u201d innovation into the marketplace faster than ever.<\/p>\n<p>Geoffrey Moore, author of <em>Crossing the Chasm, Inside the Tornado,<\/em> and now <em>Dealing with Darwin: How Great Companies Innovate at Every Phase of Their Evolution,<\/em> recently posted an article <em><a href=\"http:\/\/sandhill.com\/opinion\/editorial.php?id=66\">Top 10 Innovation Myths<\/a><\/em>, that is in line with his new book and definitely worth a read. Mr. Moore points out that innovation is not the goal\u2014product differentiation resulting from innovation is the goal. He is absolutely right. An innovative way to minimize the window of an application is not likely to differentiate the product from its competitors. An innovative way to automatically validate requirements would be the proverbial better mouse trap.<\/p>\n<p>Making things even more competitive is the increased speed and reduced cost of getting the message out. Idea virus is a term coined by Seth Godin, and every day another company learns how to do it. When a new product gets digg\u2019ed or slashdotted, the stampede on the server is like the mobs that sought out super cheap computers during the last holiday season. The Internet traffic can become overwhelming and shut down the servers. But that still won\u2019t stop the flow of traffic for really hot ideas\u2014people will post links to a cached version of the page at Google\u2122, and the idea virus keeps spreading.<\/p>\n<p>It is not enough to be fast. But it is also not enough to be differentiated. Both are important\u2014neither is sufficient alone.The twin-dynamic of smarter, faster competition combined with cheaper, faster effective marketing, demands that we focus on reducing time to market.<\/p>\n<p><em>All <\/em>of the <em>must be <\/em>requirements need to be included in the first release. If we could release the software without implementing features to support a <em>must be <\/em>requirement, then either no one will use the software, or the requirement is not a<em> must be <\/em>requirement.<\/p>\n<h2>Define and prioritize <em>more is better<\/em> requirements based on ROI<\/h2>\n<p>We have already discussed how to find the Pareto optimal point for specifying a <em>more is better <\/em>requirement. This is the point where additional investments in the measured characteristic are not offset by comparable gains, due to the law of diminishing returns. We showed the optimal point to be where the slope of the cost-benefit curve is 1 (or 100%). What we have not accounted for is the opportunity cost of spending those development resources on other features, capabilities, or projects. If we have a hurdle rate of 20% for investments, we should find the point on the cost-benefit curve where the slope is 1\/1.2 (120% benefit for 100% cost). This normalizes our cost benefit decisions across projects.<\/p>\n<p>The key to scheduling <em>more is better <\/em>requirements is to take advantage of the fact that they represent a continuum of performance and a continuum of benefit from that performance. Include a minimal amount of the requirement in the earliest release(s)\u2014not the optimal amount. The optimal amount can be added later. We refer to this as requirement <em>staging<\/em>\u2014or implementing portions of (or versions of) a particular requirement across multiple releases.<\/p>\n<h2><em>Surprise and delight<\/em> requirements as differentiators<\/h2>\n<p>We care about <em>surprise and delight <\/em>features not because they are whimsical, but because they are valuable. A delightful splash screen does not make software easier to use, but it has value in both branding and word-of-mouth marketing. It is the buzz-marketing equivalent of great packaging for a physical product (like the ketchup bottle that stands upside down). Self-configuring software, error messages with <em>\u201cclick here to <\/em><em>automatically fix it\u201d<\/em> buttons are other examples of surprises with value. These examples can increase the number of possible users.<\/p>\n<p>When prioritizing <em>surprise and delight <\/em>requirements, we must consider our marketing strategy to determine the importance of the requirement. Are we a startup and is this our first product? Are we a behemoth rolling out another bolt-on package for our installed base? These types of features are most valuable when individuals are making purchasing decisions and when we are relying on word-of-mouth marketing. The features are least valuable when the decision maker is three layers (and six figures) removed from the actual users. This decision maker can pragmatically decide that usability is irrelevant because he does not personally have to use it.<\/p>\n<h2>Summary<\/h2>\n<p>Kano analysis provides a powerful and easy-to-use means to classify requirements. We can use that classification to drive our prioritization decisions, making sure that we deliver all of the <em>must be<\/em> requirements in the first release. Kano also helps us focus on the requirements that will <em>differentiate<\/em> our software, while helping us make informed cost-benefit analyses on the<em> more is better<\/em> features.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>The Kano analysis model was developed to identify and contrast essential customer requirements from incremental requirements, and initiate critical thinking.<\/p>\n","protected":false},"author":230,"featured_media":9004111222519958,"menu_order":0,"template":"","categories":[9004111222497210,1],"tags":[],"content-series":[],"content-format":[9004111223037711],"framework-box":[177,124,174,128],"vertical":[131],"ppma_author":[1162],"class_list":["post-9004111223054294","resources","type-resources","status-publish","has-post-thumbnail","hentry","category-product-development","category-uncategorized","content-format-article","framework-box-fw-buyer-personas","framework-box-fw-focus","framework-box-fw-planning","framework-box-fw-product-roadmap","vertical-product","author-scott-sehlhorst"],"yoast_head":"<!-- This site is optimized with the Yoast SEO plugin v27.2 - https:\/\/yoast.com\/product\/yoast-seo-wordpress\/ -->\n<title>Prioritizing Software Requirements with Kano Analysis | Pragmatic Institute<\/title>\n<meta name=\"description\" content=\"The first release of the software should primarily include must be requirements. Kano analysis provides a means to classify requirements.\" \/>\n<meta name=\"robots\" content=\"index, follow, max-snippet:-1, max-image-preview:large, max-video-preview:-1\" \/>\n<link rel=\"canonical\" href=\"https:\/\/www.pragmaticinstitute.com\/resources\/articles\/product\/prioritizing-software-requirements-with-kano-analysis\/\" \/>\n<meta property=\"og:locale\" content=\"en_US\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"Prioritizing Software Requirements with Kano Analysis | Pragmatic Institute\" \/>\n<meta property=\"og:description\" content=\"The first release of the software should primarily include must be requirements. Kano analysis provides a means to classify requirements.\" \/>\n<meta property=\"og:url\" content=\"https:\/\/www.pragmaticinstitute.com\/resources\/articles\/product\/prioritizing-software-requirements-with-kano-analysis\/\" \/>\n<meta property=\"og:site_name\" content=\"Pragmatic Institute - Resources\" \/>\n<meta property=\"og:image\" content=\"https:\/\/www.pragmaticinstitute.com\/resources\/wp-content\/uploads\/sites\/6\/2007\/08\/prioritizing-software-requirments.jpg\" \/>\n\t<meta property=\"og:image:width\" content=\"800\" \/>\n\t<meta property=\"og:image:height\" content=\"533\" \/>\n\t<meta property=\"og:image:type\" content=\"image\/jpeg\" \/>\n<meta name=\"twitter:card\" content=\"summary_large_image\" \/>\n<meta name=\"twitter:label1\" content=\"Est. reading time\" \/>\n\t<meta name=\"twitter:data1\" content=\"10 minutes\" \/>\n<script type=\"application\/ld+json\" class=\"yoast-schema-graph\">{\"@context\":\"https:\/\/schema.org\",\"@graph\":[{\"@type\":\"WebPage\",\"@id\":\"https:\/\/www.pragmaticinstitute.com\/resources\/articles\/product\/prioritizing-software-requirements-with-kano-analysis\/\",\"url\":\"https:\/\/www.pragmaticinstitute.com\/resources\/articles\/product\/prioritizing-software-requirements-with-kano-analysis\/\",\"name\":\"Prioritizing Software Requirements with Kano Analysis | Pragmatic Institute\",\"isPartOf\":{\"@id\":\"https:\/\/www.pragmaticinstitute.com\/resources\/#website\"},\"primaryImageOfPage\":{\"@id\":\"https:\/\/www.pragmaticinstitute.com\/resources\/articles\/product\/prioritizing-software-requirements-with-kano-analysis\/#primaryimage\"},\"image\":{\"@id\":\"https:\/\/www.pragmaticinstitute.com\/resources\/articles\/product\/prioritizing-software-requirements-with-kano-analysis\/#primaryimage\"},\"thumbnailUrl\":\"https:\/\/www.pragmaticinstitute.com\/resources\/wp-content\/uploads\/sites\/6\/2007\/08\/prioritizing-software-requirments.jpg\",\"datePublished\":\"2007-08-10T04:00:00+00:00\",\"description\":\"The first release of the software should primarily include must be requirements. Kano analysis provides a means to classify requirements.\",\"breadcrumb\":{\"@id\":\"https:\/\/www.pragmaticinstitute.com\/resources\/articles\/product\/prioritizing-software-requirements-with-kano-analysis\/#breadcrumb\"},\"inLanguage\":\"en-US\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"https:\/\/www.pragmaticinstitute.com\/resources\/articles\/product\/prioritizing-software-requirements-with-kano-analysis\/\"]}]},{\"@type\":\"ImageObject\",\"inLanguage\":\"en-US\",\"@id\":\"https:\/\/www.pragmaticinstitute.com\/resources\/articles\/product\/prioritizing-software-requirements-with-kano-analysis\/#primaryimage\",\"url\":\"https:\/\/www.pragmaticinstitute.com\/resources\/wp-content\/uploads\/sites\/6\/2007\/08\/prioritizing-software-requirments.jpg\",\"contentUrl\":\"https:\/\/www.pragmaticinstitute.com\/resources\/wp-content\/uploads\/sites\/6\/2007\/08\/prioritizing-software-requirments.jpg\",\"width\":800,\"height\":533,\"caption\":\"Photo By Fotis Fotopoulos on Unsplash\"},{\"@type\":\"BreadcrumbList\",\"@id\":\"https:\/\/www.pragmaticinstitute.com\/resources\/articles\/product\/prioritizing-software-requirements-with-kano-analysis\/#breadcrumb\",\"itemListElement\":[{\"@type\":\"ListItem\",\"position\":1,\"name\":\"Home\",\"item\":\"https:\/\/www.pragmaticinstitute.com\/resources\/\"},{\"@type\":\"ListItem\",\"position\":2,\"name\":\"Resources\",\"item\":\"https:\/\/www.pragmaticinstitute.com\/resources\/resources\/\"},{\"@type\":\"ListItem\",\"position\":3,\"name\":\"Prioritizing Software Requirements with Kano Analysis\"}]},{\"@type\":\"WebSite\",\"@id\":\"https:\/\/www.pragmaticinstitute.com\/resources\/#website\",\"url\":\"https:\/\/www.pragmaticinstitute.com\/resources\/\",\"name\":\"Pragmatic Institute\",\"description\":\"\",\"publisher\":{\"@id\":\"https:\/\/www.pragmaticinstitute.com\/resources\/#organization\"},\"alternateName\":\"Pragmatic\",\"potentialAction\":[{\"@type\":\"SearchAction\",\"target\":{\"@type\":\"EntryPoint\",\"urlTemplate\":\"https:\/\/www.pragmaticinstitute.com\/resources\/?s={search_term_string}\"},\"query-input\":{\"@type\":\"PropertyValueSpecification\",\"valueRequired\":true,\"valueName\":\"search_term_string\"}}],\"inLanguage\":\"en-US\"},{\"@type\":\"Organization\",\"@id\":\"https:\/\/www.pragmaticinstitute.com\/resources\/#organization\",\"name\":\"Pragmatic Institute\",\"url\":\"https:\/\/www.pragmaticinstitute.com\/resources\/\",\"logo\":{\"@type\":\"ImageObject\",\"inLanguage\":\"en-US\",\"@id\":\"https:\/\/www.pragmaticinstitute.com\/resources\/#\/schema\/logo\/image\/\",\"url\":\"https:\/\/www.pragmaticinstitute.com\/resources\/wp-content\/uploads\/sites\/6\/2021\/09\/The_Pragmatic_Institute_Stacked_Logo.png\",\"contentUrl\":\"https:\/\/www.pragmaticinstitute.com\/resources\/wp-content\/uploads\/sites\/6\/2021\/09\/The_Pragmatic_Institute_Stacked_Logo.png\",\"width\":216,\"height\":224,\"caption\":\"Pragmatic Institute\"},\"image\":{\"@id\":\"https:\/\/www.pragmaticinstitute.com\/resources\/#\/schema\/logo\/image\/\"}}]}<\/script>\n<!-- \/ Yoast SEO plugin. -->","yoast_head_json":{"title":"Prioritizing Software Requirements with Kano Analysis | Pragmatic Institute","description":"The first release of the software should primarily include must be requirements. Kano analysis provides a means to classify requirements.","robots":{"index":"index","follow":"follow","max-snippet":"max-snippet:-1","max-image-preview":"max-image-preview:large","max-video-preview":"max-video-preview:-1"},"canonical":"https:\/\/www.pragmaticinstitute.com\/resources\/articles\/product\/prioritizing-software-requirements-with-kano-analysis\/","og_locale":"en_US","og_type":"article","og_title":"Prioritizing Software Requirements with Kano Analysis | Pragmatic Institute","og_description":"The first release of the software should primarily include must be requirements. Kano analysis provides a means to classify requirements.","og_url":"https:\/\/www.pragmaticinstitute.com\/resources\/articles\/product\/prioritizing-software-requirements-with-kano-analysis\/","og_site_name":"Pragmatic Institute - Resources","og_image":[{"width":800,"height":533,"url":"https:\/\/www.pragmaticinstitute.com\/resources\/wp-content\/uploads\/sites\/6\/2007\/08\/prioritizing-software-requirments.jpg","type":"image\/jpeg"}],"twitter_card":"summary_large_image","twitter_misc":{"Est. reading time":"10 minutes"},"schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":"WebPage","@id":"https:\/\/www.pragmaticinstitute.com\/resources\/articles\/product\/prioritizing-software-requirements-with-kano-analysis\/","url":"https:\/\/www.pragmaticinstitute.com\/resources\/articles\/product\/prioritizing-software-requirements-with-kano-analysis\/","name":"Prioritizing Software Requirements with Kano Analysis | Pragmatic Institute","isPartOf":{"@id":"https:\/\/www.pragmaticinstitute.com\/resources\/#website"},"primaryImageOfPage":{"@id":"https:\/\/www.pragmaticinstitute.com\/resources\/articles\/product\/prioritizing-software-requirements-with-kano-analysis\/#primaryimage"},"image":{"@id":"https:\/\/www.pragmaticinstitute.com\/resources\/articles\/product\/prioritizing-software-requirements-with-kano-analysis\/#primaryimage"},"thumbnailUrl":"https:\/\/www.pragmaticinstitute.com\/resources\/wp-content\/uploads\/sites\/6\/2007\/08\/prioritizing-software-requirments.jpg","datePublished":"2007-08-10T04:00:00+00:00","description":"The first release of the software should primarily include must be requirements. Kano analysis provides a means to classify requirements.","breadcrumb":{"@id":"https:\/\/www.pragmaticinstitute.com\/resources\/articles\/product\/prioritizing-software-requirements-with-kano-analysis\/#breadcrumb"},"inLanguage":"en-US","potentialAction":[{"@type":"ReadAction","target":["https:\/\/www.pragmaticinstitute.com\/resources\/articles\/product\/prioritizing-software-requirements-with-kano-analysis\/"]}]},{"@type":"ImageObject","inLanguage":"en-US","@id":"https:\/\/www.pragmaticinstitute.com\/resources\/articles\/product\/prioritizing-software-requirements-with-kano-analysis\/#primaryimage","url":"https:\/\/www.pragmaticinstitute.com\/resources\/wp-content\/uploads\/sites\/6\/2007\/08\/prioritizing-software-requirments.jpg","contentUrl":"https:\/\/www.pragmaticinstitute.com\/resources\/wp-content\/uploads\/sites\/6\/2007\/08\/prioritizing-software-requirments.jpg","width":800,"height":533,"caption":"Photo By Fotis Fotopoulos on Unsplash"},{"@type":"BreadcrumbList","@id":"https:\/\/www.pragmaticinstitute.com\/resources\/articles\/product\/prioritizing-software-requirements-with-kano-analysis\/#breadcrumb","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https:\/\/www.pragmaticinstitute.com\/resources\/"},{"@type":"ListItem","position":2,"name":"Resources","item":"https:\/\/www.pragmaticinstitute.com\/resources\/resources\/"},{"@type":"ListItem","position":3,"name":"Prioritizing Software Requirements with Kano Analysis"}]},{"@type":"WebSite","@id":"https:\/\/www.pragmaticinstitute.com\/resources\/#website","url":"https:\/\/www.pragmaticinstitute.com\/resources\/","name":"Pragmatic Institute","description":"","publisher":{"@id":"https:\/\/www.pragmaticinstitute.com\/resources\/#organization"},"alternateName":"Pragmatic","potentialAction":[{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https:\/\/www.pragmaticinstitute.com\/resources\/?s={search_term_string}"},"query-input":{"@type":"PropertyValueSpecification","valueRequired":true,"valueName":"search_term_string"}}],"inLanguage":"en-US"},{"@type":"Organization","@id":"https:\/\/www.pragmaticinstitute.com\/resources\/#organization","name":"Pragmatic Institute","url":"https:\/\/www.pragmaticinstitute.com\/resources\/","logo":{"@type":"ImageObject","inLanguage":"en-US","@id":"https:\/\/www.pragmaticinstitute.com\/resources\/#\/schema\/logo\/image\/","url":"https:\/\/www.pragmaticinstitute.com\/resources\/wp-content\/uploads\/sites\/6\/2021\/09\/The_Pragmatic_Institute_Stacked_Logo.png","contentUrl":"https:\/\/www.pragmaticinstitute.com\/resources\/wp-content\/uploads\/sites\/6\/2021\/09\/The_Pragmatic_Institute_Stacked_Logo.png","width":216,"height":224,"caption":"Pragmatic Institute"},"image":{"@id":"https:\/\/www.pragmaticinstitute.com\/resources\/#\/schema\/logo\/image\/"}}]}},"_links":{"self":[{"href":"https:\/\/www.pragmaticinstitute.com\/resources\/wp-json\/wp\/v2\/resources\/9004111223054294","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.pragmaticinstitute.com\/resources\/wp-json\/wp\/v2\/resources"}],"about":[{"href":"https:\/\/www.pragmaticinstitute.com\/resources\/wp-json\/wp\/v2\/types\/resources"}],"author":[{"embeddable":true,"href":"https:\/\/www.pragmaticinstitute.com\/resources\/wp-json\/wp\/v2\/users\/230"}],"version-history":[{"count":0,"href":"https:\/\/www.pragmaticinstitute.com\/resources\/wp-json\/wp\/v2\/resources\/9004111223054294\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.pragmaticinstitute.com\/resources\/wp-json\/wp\/v2\/media\/9004111222519958"}],"wp:attachment":[{"href":"https:\/\/www.pragmaticinstitute.com\/resources\/wp-json\/wp\/v2\/media?parent=9004111223054294"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.pragmaticinstitute.com\/resources\/wp-json\/wp\/v2\/categories?post=9004111223054294"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.pragmaticinstitute.com\/resources\/wp-json\/wp\/v2\/tags?post=9004111223054294"},{"taxonomy":"content-series","embeddable":true,"href":"https:\/\/www.pragmaticinstitute.com\/resources\/wp-json\/wp\/v2\/content-series?post=9004111223054294"},{"taxonomy":"content-format","embeddable":true,"href":"https:\/\/www.pragmaticinstitute.com\/resources\/wp-json\/wp\/v2\/content-format?post=9004111223054294"},{"taxonomy":"framework-box","embeddable":true,"href":"https:\/\/www.pragmaticinstitute.com\/resources\/wp-json\/wp\/v2\/framework-box?post=9004111223054294"},{"taxonomy":"vertical","embeddable":true,"href":"https:\/\/www.pragmaticinstitute.com\/resources\/wp-json\/wp\/v2\/vertical?post=9004111223054294"},{"taxonomy":"author","embeddable":true,"href":"https:\/\/www.pragmaticinstitute.com\/resources\/wp-json\/wp\/v2\/ppma_author?post=9004111223054294"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}