Software Requirements Management through the Lenses of People, Organizational and Technological Dimensions

Software Requirements Management through the Lenses of People, Organizational and Technological Dimensions

Fernando Paulo Belfo (Instituto de Contabilidade e Administração de Coimbra, Instituto Politécnico de Coimbra, Coimbra, Portugal)
Copyright: © 2012 |Pages: 15
DOI: 10.4018/jwp.2012070104
OnDemand PDF Download:
No Current Special Offers


The inadequate specification of requirements remains being indicated as one of the main reasons for the failure of software development projects. A possible explanation for this failure is that requirements management tends to overvalue the technology side of requirements. However, the requirements management depends on other important issues beyond technology which are sometimes neglected. Good requirements are only assured by the right balance of three dimensions: people, organization and technology. Through the lens of each of these three dimensions, this paper reviews significant literature, identifying some of the key issues and concerns about the management of software requirements, particularly the software requirements specification. Major software quality attributes, like clearness, completeness, correctness, understandability, verifiability or validity, consistency and feasibility, are used to analyse several important facets of software requirements management. Implications for future research are discussed.
Article Preview

1. Introduction

According to the 2009 survey of the Standish Group, in 2008 about one-third of information technology projects were successful, about a quarter were canceled before completion and the remaining 44 percent had significant problems, including a serious delay, budget exceeded or reduction of features or functionality previously planned. Usual problems with IT projects are frequently related to the software requirements (SR).

This report outlines some laws evidencing some success factors. One of this laws is the “law of the two faces”. It underlines that users may be the best friend and worst enemy of IT projects. It is very important to promote an ecosystem for users that enables the detailed explanation of business processes to the IT experts. Another law is the “law of the long-tailed monster” which firstly states that, there is a tendency to build too much of what is not needed, and, secondly, not enough of what is really needed. Also, the longer a project goes on, the more probability there is that a key person will leave. The “law of the empty chair” draws our attention to the devastating consequences when one of the best persons leaves the IT project. At last, the “law of the fools” stands that a fool with a tool is still a fool. By one hand, it suggests the importance of having the right tool for a problem, and not using always a hammer to solve problems that are not necessarily a nail. On the other hand, having the right tool is not always enough, but the skill to use it makes the difference between success or failure (Standish Group, 2009). These laws, and the success factors behind them, highlight some of the most important causes that explains the failure or the success on developing a significant number of IT projects. Also, they evidence that sometimes, the deficiency at requirements specification is especially explained by non-technical reasons rather than causes of technical nature.

Requirements engineering (RE) is the branch of software engineering concerned with the functions and constraints of software systems that helps to accomplish the objectives of the real-world (Zave, 1997). On the other hand, the main outcome of RE is the requirements specification (RS) which is a short statement of the requirements to be fulfilled by the software (Hofmann & Lehner, 2001; IEEE, 1998a). From an user perspective, a requirement can be defined as “a condition or capability needed by a user to solve a problem or achieve an objective”. From the system side, it may be defined as “a condition or capability that must be met or possessed by a system or system component to satisfy a contract, standard, specification, or other formally imposed document” (IEEE, 1998b).

The complexity of requirements engineering is huge. Requirements engineering is becoming accepted as a set of processes that operates on different levels (Aurum & Wohlin, 2005b). One of main difficulties of requirements engineering is the heterogeneity of the topics usually considered part of requirements. Among other topics, it may be considered the tasks that must be completed, the problems that must be solved, the solutions to problems, the ways of contributing to knowledge or types of system. This complicates the construction of a possible organization scheme (Zave, 1997). Usual practical approaches of requirements specification mostly focus on objects, functions and states (Hochmüller, 1997). However, this is not sufficient. Complementary perspectives of requirements are needed, considering among other different angles of the problem, like the economy, the time, the performance or human facets. Several studies evidences the need of using alternative approaches to analyze the requirements (Hochmüller, 1997; Hochmuller, 2007; Paech & Kerkow, 2004; Zave, 1997). Another perspective about requirements management is suggested at this article. It proposes the adoption of the lenses coming from the dimensions proposed by the Orlikowski´s model to shed light the complexity of requirements specification.

Complete Article List

Search this Journal:
Open Access Articles: Forthcoming
Volume 14: 2 Issues (2022): Forthcoming, Available for Pre-Order
Volume 13: 2 Issues (2021): 1 Released, 1 Forthcoming
Volume 12: 2 Issues (2020)
Volume 11: 2 Issues (2019)
Volume 10: 2 Issues (2018)
Volume 9: 2 Issues (2017)
Volume 8: 1 Issue (2016)
Volume 7: 2 Issues (2015)
Volume 6: 4 Issues (2014)
Volume 5: 4 Issues (2013)
Volume 4: 4 Issues (2012)
Volume 3: 4 Issues (2011)
Volume 2: 4 Issues (2010)
Volume 1: 4 Issues (2009)
View Complete Journal Contents Listing