DOCSLIB.ORG

Four Key Requirements Engineering Techniques

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Four Key Requirements Engineering Techniques 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
Load more

Recommended publications
  • Project Management © Adrienne Watt
    Project Management © Adrienne Watt This work is licensed under a Creative Commons-ShareAlike 4.0 International License Original source: The Saylor Foundation http://open.bccampus.ca/find-open-textbooks/?uuid=8678fbae-6724-454c-a796-3c666 7d826be&contributor=&keyword=&subject= Contents Introduction ...................................................................................................................1 Preface ............................................................................................................................2 About the Book ..............................................................................................................3 Chapter 1 Project Management: Past and Present ....................................................5 1.1 Careers Using Project Management Skills ......................................................................5 1.2 Business Owners ...............................................................................................................5 Example: Restaurant Owner/Manager ..........................................................................6 1.2.1 Outsourcing Services ..............................................................................................7 Example: Construction Managers ..........................................................................8 1.3 Creative Services ................................................................................................................9 Example: Graphic Artists ...............................................................................................10
    [Show full text]
  • Computer Organization and Architecture Designing for Performance Ninth Edition
    COMPUTER ORGANIZATION AND ARCHITECTURE DESIGNING FOR PERFORMANCE NINTH EDITION William Stallings Boston Columbus Indianapolis New York San Francisco Upper Saddle River Amsterdam Cape Town Dubai London Madrid Milan Munich Paris Montréal Toronto Delhi Mexico City São Paulo Sydney Hong Kong Seoul Singapore Taipei Tokyo Editorial Director: Marcia Horton Designer: Bruce Kenselaar Executive Editor: Tracy Dunkelberger Manager, Visual Research: Karen Sanatar Associate Editor: Carole Snyder Manager, Rights and Permissions: Mike Joyce Director of Marketing: Patrice Jones Text Permission Coordinator: Jen Roach Marketing Manager: Yez Alayan Cover Art: Charles Bowman/Robert Harding Marketing Coordinator: Kathryn Ferranti Lead Media Project Manager: Daniel Sandin Marketing Assistant: Emma Snider Full-Service Project Management: Shiny Rajesh/ Director of Production: Vince O’Brien Integra Software Services Pvt. Ltd. Managing Editor: Jeff Holcomb Composition: Integra Software Services Pvt. Ltd. Production Project Manager: Kayla Smith-Tarbox Printer/Binder: Edward Brothers Production Editor: Pat Brown Cover Printer: Lehigh-Phoenix Color/Hagerstown Manufacturing Buyer: Pat Brown Text Font: Times Ten-Roman Creative Director: Jayne Conte Credits: Figure 2.14: reprinted with permission from The Computer Language Company, Inc. Figure 17.10: Buyya, Rajkumar, High-Performance Cluster Computing: Architectures and Systems, Vol I, 1st edition, ©1999. Reprinted and Electronically reproduced by permission of Pearson Education, Inc. Upper Saddle River, New Jersey, Figure 17.11: Reprinted with permission from Ethernet Alliance. Credits and acknowledgments borrowed from other sources and reproduced, with permission, in this textbook appear on the appropriate page within text. Copyright © 2013, 2010, 2006 by Pearson Education, Inc., publishing as Prentice Hall. All rights reserved. Manufactured in the United States of America.
    [Show full text]
  • Innovations in Natural Language Document Processing for Requirements Engineering
    Calhoun: The NPS Institutional Archive Faculty and Researcher Publications Faculty and Researcher Publications 2008 Innovations in Natural Language Document Processing for Requirements Engineering Berzins, Valdis þÿB. Paech and C. Martell (Eds.): Monterey Workshop 2007, LNCS 5320, pp. 125 146, 2008. http://hdl.handle.net/10945/46073 Innovations in Natural Language Document Processing for Requirements Engineering Valdis Berzins, Craig Martell, Luqi, and Paige Adams Naval Postgraduate School, 1411 Cunningham Road, Monterey, California 93943 {berzins,cmartell,luqi,phadams}@nps.edu Abstract. This paper evaluates the potential contributions of natural language processing to requirements engineering. We present a selective history of the relationship between requirements engineering (RE) and natural-language processing (NLP), and briefly summarize relevant re- cent trends in NLP. The paper outlines basic issues in RE and how they relate to interactions between a NLP front end and system-development processes. We suggest some improvements to NLP that may be possible in the context of RE and conclude with an assessment of what should be done to improve likelihood of practical impact in this direction. Keywords: Requirements, Natural Language, Ambiguity, Gaps, Domain- Specific Methods. 1 Introduction A major challenge in requirements engineering is dealing with changes, especially in the context of systems of systems with correspondingly complex stakeholder communities and critical systems with stringent dependability requirements. Documentation driven development (DDD) is a recently developed approach for addressing these issues that seeks to simultaneously improve agility and de- pendability via computer assistance centered on a variety of documents [1,2]. The approach is based on a new view of documents as computationally active knowledge bases that support computer aid for many software engineering tasks from requirements engineering to system evolution, which is quite different from the traditional view of documents as passive pieces of paper.
    [Show full text]
  • Managing Requirements Engineering Risks: an Analysis and Synthesis of the Literature
    Lars Mathiassen – Timo Saarinen – Tuure Tuunanen – Matti Rossi MANAGING REQUIREMENTS ENGINEERING RISKS: AN ANALYSIS AND SYNTHESIS OF THE LITERATURE W-379 HELSINKI SCHOOL OF ECONOMICS ISSN 1795-1828 WORKING PAPERS ISBN 951-791-895-X (Electronic working paper) W-379 2004 Lars Mathiassen* – Timo Saarinen** – Tuure Tuunanen** – Matti Rossi** MANAGING REQUIREMENTS ENGINEERING RISKS: AN ANALYSIS AND SYNTHESIS OF THE LITERATURE *Center for Process Innovation, Georgia State University **Helsinki School Economics, Department of Management, Information Systems Science November 2004 HELSINGIN KAUPPAKORKEAKOULU HELSINKI SCHOOL OF ECONOMICS WORKING PAPERS W-379 HELSINGIN KAUPPAKORKEAKOULU HELSINKI SCHOOL OF ECONOMICS PL 1210 FIN-00101 HELSINKI FINLAND © Lars Mathiassen, Timo Saarinen, Tuure Tuunanen, Matti Rossi and Helsinki School of Economics ISSN 1795-1828 ISBN 951-791-895-X (Electronic working paper) Helsinki School of Economics - HeSE print 2004 Managing Requirements Engineering Risks: An Analysis and Synthesis of the Literature Lars Mathiassen ([email protected]) Center for Process Innovation, Georgia State University P. O. Box 4015, Atlanta, GA 30303-4015, USA Phone: +1-404-651-0933, Fax: +1-404-463-9292 Timo Saarinen ([email protected]) Helsinki School Economics, Department of Management, Information Systems Science P. O. Box 1210, FIN-00101 Helsinki, Finland Phone: +358-9-431-38272, Fax: Fax: +358-9-431-38700 Tuure Tuunanen ([email protected]) Helsinki School Economics, Department of Management, Information Systems Science P. O. Box 1210, FIN-00101 Helsinki, Finland Phone: +358-40-544-5591, Fax: +358-9-431-38700 http://www.tuunanen.fi Matti Rossi ([email protected]) Helsinki School Economics, Department of Management, Information Systems Science P.
    [Show full text]
  • Implementing Concurrent Engineering and QFD Method to Achieve Realization of Sustainable Project
    sustainability Article Implementing Concurrent Engineering and QFD Method to Achieve Realization of Sustainable Project Lidija Rihar and Janez Kušar * Faculty of Mechanical Engineering, University of Ljubljana, SI-1000 Ljubljana, Slovenia; [email protected] * Correspondence: [email protected] Abstract: In this paper, we present the impact of concurrent engineering strategies, methods, and tools on product sustainability. Concurrent engineering can be used to achieve the primary goals of a product realization project: lower costs, shorter times, high quality, and increasing value. Currently, it is important that new products also meet product sustainability goals, such as economic, environmental, and social goals. The sustainability of a product can be influenced the most in the early stages of product development, so in this paper, we present a customized quality function deployment (QFD) method called the house of sustainability, which translates sustainability requirements into technical solutions for a product. A seven-step process for implementing a sustainable product realization project is also proposed, in which the house of sustainability is one of the most important tools. The proposed process is illustrated with an example of a concurrent product realization project in engineering to order production. Keywords: concurrent engineering; product sustainability; production sustainability; new product development; QFD Citation: Rihar, L.; Kušar, J. 1. Introduction Implementing Concurrent Sustainability has lately become one of the key features of new products. Sustainabil- Engineering and QFD Method to ity implies product properties that characterize it from the idea, through development, Achieve Realization of Sustainable production, use, and maintenance, to the end of the life of the product (disposal).
    [Show full text]
  • Requirements Management Applied in an Agile Project Management Environment
    Requirements Management applied in an agile Project Management environment Franco (Frank) Curtolo CEng, Principal Consultant, Program Planning Professionals Ltd, [email protected] Categorisation • Accessibility: PRACTITIONER • Application: GOOD PRACTICE • Topics: Agile Systems Engineering; Project Management Abstract This paper looks at how the Requirements Management process of Systems Engineering may benefit from some of the aspects derived from developing systems within an agile Project Management environment, using as example, the Scaled Agile Framework® of © Scaled Agile, Inc. The aim is to see if some of these agile techniques can enhance the Systems Engineering approach. Systems Engineering (SE) is well suited to develop large, complex products in a project environment where the requirements can be defined and fixed upfront. In fact, SE relies on an initial, well-defined End User’s need specified in for example, a User Requirements Specification (URS), to establish an initial requirements baseline which is used to drive the rest of the development process. However not all development projects happen that way. Sometimes the End User’s need is not clear, or cannot be well defined upfront, thus not allowing it to be captured in a fixed requirements baseline. Furthermore, the project environment may need to accommodate rapid change, both in the End Users’ need and in the technologies available to satisfy this need. In such a project environment, an agile development approach, as described in the Scaled Agile Framework® (SAFe®), may be more suitable since it allows for incremental delivery of the product and change to requirements. This can accommodate undefined End User needs, rapid change in requirements and allow for the introduction of innovation during the development and implementation stages.
    [Show full text]
  • Microcomputers: NQS PUBLICATIONS Introduction to Features and Uses
    of Commerce Computer Science National Bureau and Technology of Standards NBS Special Publication 500-110 Microcomputers: NQS PUBLICATIONS Introduction to Features and Uses QO IGf) .U57 500-110 NATIONAL BUREAU OF STANDARDS The National Bureau of Standards' was established by an act ot Congress on March 3, 1901. The Bureau's overall goal is to strengthen and advance the Nation's science and technology and facilitate their effective application for public benefit. To this end, the Bureau conducts research and provides; (1) a basis for the Nation's physical measurement system, (2) scientific and technological services for industry and government, (3) a technical basis for equity in trade, and (4) technical services to promote public safety. The Bureau's technical work is per- formed by the National Measurement Laboratory, the National Engineering Laboratory, and the Institute for Computer Sciences and Technology. THE NATIONAL MEASUREMENT LABORATORY provides the national system of physical and chemical and materials measurement; coordinates the system with measurement systems of other nations and furnishes essential services leading to accurate and uniform physical and chemical measurement throughout the Nation's scientific community, industry, and commerce; conducts materials research leading to improved methods of measurement, standards, and data on the properties of materials needed by industry, commerce, educational institutions, and Government; provides advisory and research services to other Government agencies; develops, produces, and
    [Show full text]
  • Requirements Engineering Objectives
    Requirements Engineering Chapter 2 Requirements Engineering Processes Learning Objective ...to give a general introduction to the requirements engineering process. Different approaches to modeling requirements engineering processes are suggested and why human, social and organizational factors are important influences on those processes. Other concepts that are evaluated include process maturity, tools and process improvement. Frederick T Sheldon Assistant Professor of Computer Science University of Colorado at Colorado Springs CS 531 Software Requirements Analysis and Specification Chapter 2 From Requirements Engineering Processes and Techniques by G. Kotonya and I. Sommerville 1998 Slide 1 Objectives ⊗ To introduce the notion of processes and process models for requirements engineering ⊗ To explain the critical role of people in requirements engineering processes ⊗ To explain why process improvements is important and to suggest a process improvement model for requirements engineering CS 531 Software Requirements Analysis and Specification Chapter 2 From Requirements Engineering Processes and Techniques by G. Kotonya and I. Sommerville 1998 Slide 2 Processes ⊗ A process is an organized set of activities which transforms inputs to outputs ⊗ Process descriptions encapsulate knowledge and allow it to be reused ⊗ Examples of process descriptions • Instruction manual for a dishwasher • Cookery book • Procedures manual for a bank • Quality manual for software development CS 531 Software Requirements Analysis and Specification Chapter 2 From Requirements Engineering Processes and Techniques by G. Kotonya and I. Sommerville 1998 Slide 3 Design processes ⊗ Processes which involve creativity, interactions between a wide range of different people, engineering judgement and background knowledge and experience ⊗ Examples of design processes • Writing a book • Organizing a conference • Designing a processor chip • Requirements engineering CS 531 Software Requirements Analysis and Specification Chapter 2 From Requirements Engineering Processes and Techniques by G.
    [Show full text]
  • Development of a Multi-Bus Platform for Automation Testbed
    A Master Thesis Work in Electronics Development of a Multi‐bus platform for automation testbed By Lukas Knapik and Mathias Isaksson Examiner: Professor Lars Asplund, Mälardalens University Supervisor: Martin Ekström, PhD Student in Electronics, Mälardalen University Dan Olsson, M.SC Physics, Infotiv AB Lukas Knapik Mathias Isaksson 070‐7124691 073‐8079350 [email protected] [email protected] Mälardalen University, Västerås 2010‐02‐17 Development of a Multi‐bus platform for automation testbed Master Thesis CEL505 ABSTRACT The task for this thesis was to develop, construct and evaluate a multi‐bus communication system, connected to a PC via USB and capable of communicating in CAN, I2C and SPI and develop drivers for it in National Instruments LabVIEW. In the beginning a study was made of the communication buses followed by an investigation of what type of hardware that could accomplish this task. A microcontroller unit was selected and programmed in MikroElektronika MikroC Pro v.3.2 to act as the interface between the communication busses and PC. A PCB prototype of the system was constructed by using Eagle Cad software v.5.6.0. General drivers for this system where created in LabVIEW v.8.6.1 so the end‐user simply can create their own applications and control the compatible hardware depending on their type of purposes. The system was tested on criteria’s such as: speed, power consumption, burst performance and transmission length depending on which communication bus was used. Lukas Knapik, Mathias Isaksson Mälardalen University, Västerås 2010‐02‐17 Development of a Multi‐bus platform for automation testbed Master Thesis CEL505 ACKNOWLEDGEMENTS We would like to thank Infotiv AB for giving us the opportunity to do this thesis.
    [Show full text]
  • DAVID J. ERICKSON 6 Oak Drive Topsfield, MA 01983 978-887-0125 [email protected]
    DAVID J. ERICKSON 6 Oak Drive Topsfield, MA 01983 978-887-0125 [email protected] Objective: To develop successful products from concept to production using my skills in analog, digital and firmware design engineering, team and project management Management: Hands-on Engineering Management, Hardware Engineering and Project Management Education: B.S.E.E., 1976 Worcester Polytechnic Institute, Worcester, MA Design Analog processing including video, PLL, A/D, D/A, video timing, Specialties: video analog and digital LSI, graphics LCDs. Digital circuitry: Image memory (DRAM), multiport memory, pipelined image processors, bus interfaces, state machine, digital components used: PALs, DRAMs, SRAMs, PROMs, ASICs, TTL, ECL, PGAs (Xilinx, Actel, Altera), DSP blocks, FIFOs bit slice, VLSI. Instrument design for chemical and ATE industries. Medical (patient monitoring and display) electronics. Sensor interfacing, power supplies, low power design. Microprocessor hardware and firmware design, C and assembler: AVR, Z80 and 68hc11. Audio processing and control, amplifiers, test equipment. Marine and weather electronics. Troubleshooting all types of problems. Bus interfacing to MicroBus, VME/VXI, PC/AT, Multibus, Q-Bus LabView Experience: STH Company (Consultant, part time) Wayland, MA 4/02 - 9/02 Hardware and firmware design of Colorimeter Instrument complete redesign. Product development from specification to final release. Instrument uses an AVR microprocessor to implement a complete optical / chemical measurement instrument. Implemented complex acquisition timing, math, communications, display and serial interface, menu system. Development cost and product cost goals were met. Analogic Corp., Peabody, MA 1/98 to 6/02 Chief Engineer, Test and Measurement Division Directed the engineering department of the division that was the leading 3rd party supplier of mixed-signal instruments to the ATE industry.
    [Show full text]
  • Elicitation of Quality Agile User Stories Using QFD
    Elicitation of Quality Agile User Stories Using QFD NDIA 20th Annual Systems Engineering Conference “Agile in Systems Engineering“ 10:15 – 10:40 AM October 25, 2017 Sabrina J. Ussery, Shahryar Sarkani, Thomas Holzer Dissertation Topic Department of Engineering Management and Systems Engineering School of Engineering and Applied Science The George Washington University 1176 G Street NW Washington, DC 20052 1 Agile Requirements Engineering (RE) The lack of standard Requirements Engineering (RE) practices in Agile negatively impacts system quality, contributing to 24% of the causes for challenged or failed projects. • The 2015 CHAOS Standish Group report indicates Agile projects are 3x more likely to succeed than Waterfall projects due to increased customer collaboration and customer satisfaction. [2] • The Agile community claims that they do not really tackle requirements in a structured way, which may bring problems to the software organization responsible for software built following an Agile method. [1] • Though more successful in some respects, the Image source: [2] lack of stand RE practices in Agile contributes to 24% of the reasons for challenged or failed projects due to poor requirements quality (i.e., unclear or volatile). [2] 2 What is Agile? 3 Agile RE: As Is Requirements Requirements engineering (RE) refers to the process of defining, documenting and maintainingEngineering requirements. [5] Requirements Requirements Development Management Elicitation Priorities Specification Traceability Analysis Specifications Validation Configuration
    [Show full text]
  • Integrated Requirements Engineering: a Tutorial
    focusrequirements engineering1 Integrated Requirements Engineering: A Tutorial Ian Sommerville, Lancaster University efore developing any system, you must understand what the sys- tem is supposed to do and how its use can support the goals of the individuals or business that will pay for that system. This in- B volves understanding the application domain (telecommunica- tions, railways, retail banking, games, and so on); the system’s operational constraints; the specific functionality required by the stakeholders (the peo- ple who directly or indirectly use the system or the information it provides); and essential system characteristics such as The fundamental process performance, security, and dependability. Re- The RE process varies immensely depend- quirements engineering is the name given to a ing on the type of application being devel- structured set of activities that help develop oped, the size and culture of the companies in- this understanding and that document the sys- volved, and the software acquisition processes tem specification for the stakeholders and en- used. For large military and aerospace sys- gineers involved in the system development. tems, there is normally a formal RE stage in This short tutorial introduces the funda- the systems engineering processes and an ex- mental activities of RE and discusses how it tensively documented set of system and soft- has evolved as part of the software engineering ware requirements. For small companies de- process. However, rather than focus on estab- veloping innovative software products, the RE lished RE techniques, I discuss how the chang- process might consist of brainstorming ses- ing nature of software engineering has led to sions, and the product “requirements” might new challenges for RE.
    [Show full text]