Article Preview
Top1. 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.