Disciplined or Agile?: Two Approaches for Handling Requirement Change Management

Disciplined or Agile?: Two Approaches for Handling Requirement Change Management

Danyllo Wagner Albuquerque (Federal University of Campina Grande, Brazil), Everton Tavares Guimarães (Pennsylvania State University, USA), Felipe Barbosa Araújo Ramos (Federal University of Campina Grande, Brazil), Antonio Alexandre Moura Costa (Federal Institute of Paraiba, Brazil), Alexandre Gomes (Federal University of Campina Grande, Brazil), Emanuel Dantas (Federal University of Campina Grande, Brazil), Mirko Perkusich (VIRTUS, Brazil) and Hyggo Almeida (Federal University of Campina Grande, Brazil)
DOI: 10.4018/978-1-7998-4165-4.ch007
OnDemand PDF Download:
No Current Special Offers


Software requirements changes become necessary due to changes in customer requirements and changes in business rules and operating environments; hence, requirements development, which includes requirements changes, is a part of a software process. Previous studies have shown that failing to manage software requirements changes well is a main contributor to project failure. Given the importance of the subject, there is a plethora of efforts in academia and industry that discuss the management of requirements change in various directions, ways, and means. This chapter provided information about the current state-of-the-art approaches (i.e., Disciplined or Agile) for RCM and the research gaps in existing work. Benefits, risks, and difficulties associated with RCM are also made available to software practitioners who will be in a position of making better decisions on activities related to RCM. Better decisions can lead to better planning, which will increase the chance of project success.
Chapter Preview

More recently, there is an increasing number of reported work on research topics such as identifying change causes (Bano et al., 2012), change taxonomies (Saher et al., 2017)(McGee & Greer, 2012) and requirement change process models (Bano et al., 2012). In what follows, the authors will describe some these works.

Key Terms in this Chapter

Agile Software Development: Agile Software Development or Agile Method is a discipline that studies a set of behaviors, processes, practices, and tools used to create products and their subsequent availability to end users.

Use Case: A use case is a methodology used in system analysis to identify, clarify and organize system requirements. The use case is made up of a set of possible sequences of interactions between systems and users in a particular environment and related to a particular goal. The method creates a document that describes all the steps taken by a user to complete an activity.

Requirement Management: Requirements management is a systematic approach to finding, documenting, organizing, and tracking the changing requirements of a system.

Planning Poker: Planning poker, also called Scrum poker, is a consensus-based, gamified technique for estimating, mostly used to estimate effort or relative size of development goals in software development.

Requirement: The software requirements are description of features and functionalities of the target system. Requirements convey the expectations of users from the software product. The requirements can be obvious or hidden, known or unknown, expected or unexpected from client’s point of view.

Requirement Change Management: Requirement change management is defined as a process of managing changing requirements during the requirements engineering process and system development. A requirement change management process in the organization not only improves the organizational processes but success and predictability of projects as well.

Disciplined Software Development: Disciplined (or Traditional) software development methodologies are based on pre-organized phases/stages of the software development lifecycle. Here the flow of development is unidirectional, from requirements to design and then to development, then to testing and maintenance.

User Story: User Story is a concise description of a user's need for the product (that is, a “requirement”) from that user's point of view. User Story seeks to describe this need in a simple and light way.

Complete Chapter List

Search this Book: