Requirements Engineering in Agile Software Development

In all organization requirements engineering is applied at two different context levels: in the context of the product or service portfolio and in the context of projects. At the project context agile methods and techniques are often successfully establis

  • PDF / 635,267 Bytes
  • 23 Pages / 439.37 x 666.142 pts Page_size
  • 79 Downloads / 218 Views

DOWNLOAD

REPORT


Abstract

In all organization requirements engineering is applied at two different context levels: in the context of the product or service portfolio and in the context of projects. At the project context agile methods and techniques are often successfully established, although the discipline of requirements engineering often still is unattended. At the portfolio context agile techniques are hardly ever established thus leading to a culture clash between the portfolio and the project context. As requirements are the most important link of the chain from portfolios to projects, a solid and continuous agile approach in the discipline of requirements engineering from portfolio management level down into every single project is a key to open up unimagined potential for the organization. This article visualizes the forces behind agile techniques in requirements engineering, the “root causes” that interact and open up this potential. The understanding of these root causes enables individuals to implement the optimal version of agility in the organization.

1

Introduction

Agility is relevant. Many success stories and serious reports as the Chaos Manifest of the Standish Group1 prove that agile methods and techniques fundamental increase project success. However, the aim of any organization cannot just be the efficient completion of projects. Projects are organizational units with time

1

See www.standishgroup.com – CHAOS MANIFESTO, the Laws of CHAOS and the CHAOS 100 Best PM Practices, Copyright 2011, Standish Group. R. Grau Z€uhlke Engineering AG, Schlieren (Zuerich), Schweiz e-mail: [email protected] A. Maedche et al. (eds.), Software for People, Management for Professionals, DOI 10.1007/978-3-642-31371-4_6, # Springer-Verlag Berlin Heidelberg 2012

97

98

R. Grau

limitations which aim to achieve the organization’s targets. This might be an innovation designed to secure the future, produce SOMETHING to earn money or simply a plan to optimize the organization. So what really is requirements engineering in this context? Asking a 100 experts delivers 200 answers. The answer of this article is very simple: Requirements engineering is one out of many activities we need to create the SOMETHING. In the commercial world, this SOMETHING is typically a PRODUCT (such as a mobile phone, a car or commercial software), a benefit (such as a bank account, internet connection or Cloud service), a service (property management, consulting or customer services) or a mixture of all these things. The PRODUCT – I will use this term in what follows to refer to all of these options – is the subject of our actual endeavor. This is how we will make our money. So rather than simply creating a product, it is even better to create it with the lowest possible total cost of ownership (TCO). To be more precise now, requirements engineering is a TOOL which is used to create a product required by the market in a WAY that ensures that the brainstorming, production and distribution, i.e. the TCO, costs less than the proceeds. On closer examinat