Software Engineering 28 JAN, 2014

Applying Agile Requirements Engineering Approach for Re-engineering & Changes in existing Brownfield Adaptive Systems

Applying Agile Requirements Engineering Approach for Re-engineering & Changes in existing Brownfield Adaptive Systems

Requirements Engineering (RE) is a key activity in the development of software systems and is concerned with the identification of the goals of stakeholders and their elaboration into precise statements of desired services and behavior. The research describes an Agile Requirements Engineering approach for re-engineering & changes in existing Brownfield adaptive system. The approach has few modifications that can be used as a part of SCRUM development process for re-engineering & changes. The approach illustrates the re-engineering & changes requirements through introduction of GAP analysis & requirements structuring & prioritization by creating AS-IS & TO-BE models with 80 / 20 rule. An attempt to close the gap between requirements engineering & agile methods in form of this approach is provided for practical implementation.

💡 Research Summary

The paper addresses the challenge of managing requirements for the re‑engineering and evolution of existing brownfield adaptive systems—systems that are already in production and must be modified or extended. Traditional Requirements Engineering (RE) emphasizes comprehensive documentation, traceability, and upfront analysis, while agile methods such as Scrum focus on rapid feedback, iterative delivery, and flexibility to change. The authors argue that the dichotomy between these two paradigms creates a “gap” that hampers effective change management in legacy environments, where the existing architecture, data, and user practices must be respected.

To bridge this gap, the authors propose an Agile Requirements Engineering (Agile RE) approach that is embedded within the Scrum lifecycle. The method consists of five tightly coupled activities:

  1. AS‑IS Modeling – The current system is captured using UML diagrams (sequence, activity, data‑flow, etc.) to create a shared visual understanding among stakeholders and developers. This step surfaces hidden technical debt and clarifies the baseline from which changes will be derived.

  2. GAP Analysis – A systematic comparison between the AS‑IS model and a desired TO‑BE model identifies functional and non‑functional differences. Each gap is classified as either a “must‑have” (essential for compliance or core business) or a “nice‑to‑have,” and its impact on business value and technical effort is quantified.

  3. 80/20 Rule Application – Leveraging the Pareto principle, the identified gaps are split into “core” (the 20 % of requirements that deliver 80 % of value) and “auxiliary” groups. Core requirements are scheduled for the earliest sprints, while auxiliary items are placed in the product backlog for later consideration. This prioritization ensures that limited development resources are directed toward the most valuable changes first.

  4. Requirement Structuring & Prioritization – The MoSCoW technique (Must, Should, Could, Won’t) is combined with story‑point estimation to assign clear labels and effort estimates to each requirement. Teams perform the estimation during sprint‑planning meetings, fostering ownership and ensuring that the effort is realistic.

  5. Scrum Integration – The above activities are introduced in a “Sprint 0” (pre‑planning sprint) where the AS‑IS/TO‑BE models, GAP analysis, and initial backlog are produced. Subsequent sprints incorporate continuous refinement: during Sprint Review and Retrospective meetings, any newly discovered gaps or changes are fed back into the backlog, preserving traceability by embedding requirement IDs in the Definition of Done (DoD).

The authors highlight several benefits of this integrated approach. First, by aligning requirement discovery with business value (through the 80/20 rule), the risk of low‑impact work consuming sprint capacity is reduced. Second, the visual GAP analysis provides a concrete, shared artifact that mitigates misunderstandings common in pure agile environments where documentation is minimal. Third, the method retains the traceability and auditability required in regulated domains (e.g., finance, healthcare) without imposing heavyweight documentation overhead.

Although the paper does not present a full empirical case study, the authors suggest that the approach is especially suitable for sectors with strict compliance, security, or legacy‑system constraints, where incremental modernization is mandatory. They acknowledge two primary limitations: (a) the initial AS‑IS modeling and GAP analysis can be resource‑intensive, potentially offsetting some agile speed gains; and (b) the effectiveness of the 80/20 rule depends on accurate business‑value assessments from stakeholders, which may be subjective or evolve over time.

In conclusion, the proposed Agile RE framework offers a pragmatic bridge between traditional RE rigor and Scrum’s flexibility. By embedding systematic modeling, gap identification, and value‑driven prioritization into the agile cadence, the approach enables teams to manage change in complex brownfield systems more predictably, maintain traceability, and deliver high‑value functionality early in the development cycle.