Four Key Requirements Engineering Techniques Author Christof Ebert Vector Consulting Services Ingersheimer Straße 24, D-70499 Stuttgart [email protected] Abstract Requirements are the initial and basic building blocks combining processes in a product’s life-cycle. We take the position that only by taking an requirements engineering perspective in four key product life-cycle management activities, the underlying projects will be success- ful. The article describes a field study with data from 246 industry projects in the domains of software platforms, embedded systems and software applications. We found that these four life-cycle techniques must be used simultaneously to achieve tangible performance im- provement measured by schedule adherence. Each technique is elaborated by concrete, practical experiences. Keywords: PLM, portfolio management, product management, project management, product life cycle, process improvement, requirements engineering. Copyright Copyright by Vector Consulting Services GmbH and IEEE Computer Society Press. All rights reserved. Any distribution or copying is subject to prior written approval by Vector. A preliminary version of this article had been coined the “best paper” at the International Requirements Engineering Conference, Paris 2005. A subsequent version of this article has appeared in IEEE Software Journal as follows: Ebert, Christof: Understanding the Product Life Cycle: Four Key Requirements Engineering Techniques. IEEE Software, ISSN: 07407459, Vol. 23, No. 3, pp. 19-25, May 2006. http://doi.ieeecomputersociety.org/10.1109/MS.2006.88 Four Key Requirements Engineering Techniques 2 / 10 1 REQUIREMENTS AND THE PRODUCT LIFE CYCLE Time to market and schedule performance is considered by many enterprises to be the key differentiator between market leaders and followers. Matching schedule commitments and shortening cycle time until release assures the perception as a reliable supplier as well as overall profit optimization. Pressed to accelerate project handover and new product commer- cialization, companies have improved the execution of R&D during the past years with in- struments like CMMI. They continue however in facing challenges in cross-functional coordi- nation which result in project delays and long cycle-time. Specifically requirements and con- tracts are frequently committed without proper alignment of sales, product management, pro- ject management and marketing in order to boost short-term revenues. Such misalignment results in insufficient capacity planning or product development resource allocation, thus making projects late. Having a winning product requires being successful in identifying market needs and translat- ing them into a product vision and scope which is executed following sound project man- agement principles. Requirements are the initial and basic building blocks gluing together different phases of the product life cycle. A recent Chaos report showed that only half of the originally allocated requirements appear in the final released version [1]. This is primarily the consequence of this process not having a clear corporate owner with assigned accountability for its success. The Bermuda triangle in many IT and software companies lies in between sales / marketing, strategy and product management and technical and R&D management. Not that the people don’t talk to each other, but often they are unable to integrate their differ- ent agendas into winning products following a pipeline approach as we know it from pharma- ceuticals. Different studies look to the effect on requirements engineering on product success [2,3]. In a study looking at new product development from a broader scope, Cooper found in 105 busi- ness units from various industries in USA that the top 20% of enterprises deliver 79% of their new products in time, while the average delivers only 51% of projects in time. From that same set of top 20% ranking companies 66% relate their resource breakdown to strategic needs. Only 31% of the average companies are aligning their strategies with resource utiliza- tion in projects. Typical results from poor upstream processes are insufficient project plan- ning, continuous changes in the requirements and project scope, delays, configuration prob- lems, defects, and overall customer dissatisfaction due to not keeping commitments or not getting the product they expect. The traditional rule of thumb indicates a change rate of 1-3% per month in terms of effort related to the allocated requirements [2,3]. This translates into more than 30% changes (i.e., new, deleted or changed requirements) to overall requirements for a project duration of two years. As a consequence, many contractors and also clients strongly urged to reduce project duration towards one year maximum. With this reduction of project duration, projects indeed performed better. We faced in the past years an increase of change rates to even double that amount, i.e., 30% in a one-year project. This cannot anymore be fixed with only shortening project duration and working with iterations. A common denominator of requirements chang- es is that they practically always correlate with project delays. Let us briefly explain some terminology which we use in the article. The product life cycle (PLC) is the sum of all activities needed to define, develop, implement, build, operate, ser- vice, and phase out a product or solution and its related variants. Product management is the discipline and role which governs a product (or solution or service) from its inception to the market/customer delivery in order to generate biggest possible value to the business. Prod- uct life cycle management (PLM) is the process for guiding products and solutions from in- 2014, Vector Consulting Services GmbH Version 3.0, 2014-01-01 Four Key Requirements Engineering Techniques 3 / 10 ception through retirement to deliver the greatest business value to an enterprise, its stake- holders and its customers. Portfolio management is a dynamic decision process aimed at having the right product mix and selecting the right projects to implement a given strategy. Fig. 1 shows a simplified product life cycle. In this example the upstream process covers the funnel until the first gating review (triangle marked with “1”), while downstream processes relate to the different activities between gate 1 and gate 3. Effective PLM assures under- standing and collaboration across the entire product life cycle – from inception (i.e., long be- fore requirements are elicited and defined) to end of support and phase-out. To benefit from improved business processes, the different functions of the enterprise plus potential external partners (e.g., outsource manufacturing) need to agree on the related processes, cycle, tools and practices. They need to apply common access to knowledge, performance metrics and decision-making protocols. They need to share information, communication, and underlying resources. business 1 project 2 project 3 maintenance 4 analysis definition execution upstream downstream • market analysis • effort estimation • progress control, • sales feedback • business plan • make, buy, reuse, tracking, oversight • maintenance plan • business case outsourcing • trade-off analysis • cost/benefit of • capital expenses • technology and (time, cost, content, extensions • risk assessment architecture benefits, ROI) • repair vs. • trade-off analysis • supplier selection • cost to complete replacement (time, cost, content, • license cost • release criteria • customer service benefits, ROI) • budget plans • maint. cost & risk (training, etc.) • competitive info • risk management • sales assumptions • competitive info Figure 1: Simplified product life-cycle with four decision gates and upstream (left) and down- stream (right) processes. Product development can be stopped at each of the gates. Downstream processes around the project execution have received much attention both from project management as well as from requirements engineering perspectives [1,2,4]. Unfortu- nately the upstream processes were not getting much attention in research, although they are also part of RE. This is often because of their complexity (e.g., heterogeneous and over- lapping ownerships, vague processes, unclear impacts of stakeholders). At most the up- stream activities are mentioned in the requirements elicitation process. A major barrier is the short-term profit and loss responsibility that provides incentives to focus on current quarter results (i.e., ongoing projects and contracts) and not to invest in future products or platforms. We want to emphasize with this study to consider product life-cycle processes, such as gate reviews or empowered project teams, part of the RE discipline. The article is structured as follows. Chapter 2 describes briefly the setting of this field study and investigates root causes of insufficient project performance. Chapter 3 provides lessons learned and concrete data from using the described practices and how they can be general- ized for transfer into other settings. Finally, chapter 4 summarizes results. 2014, Vector Consulting Services GmbH Version 3.0, 2014-01-01 Four Key Requirements Engineering Techniques 4 / 10 2 FIELD STUDY LAYOUT For this field study we investigated products and solutions within different business groups. 246 projects were taken from our history database. Project size in effort was between some person weeks and several 100 person years. All projects that had recorded valid data in the history database