Requirements engineering with viewpoints

Abstract

The requirements engineering process involves a clear understanding of the requirements of the intended system. This includes the services required of the system, the system users, its environment and associated constraints. This process involves the capture, analysis and resolution of many ideas, perspectives and relationships at varying levels of detail. Requirements methods based on global reasoning appear to lack the expressive framework to adequately articulate this distributed requirements knowledge structure. The paper describes the problems in trying to establish an adequate and stable set of requirements and proposes a viewpoint-oriented requirements definition (VORD) method a s a means of tackling some of these problems. This method structures the requirements engineering process using viewpoints associated with sources of requirements. The paper describes VORD in the light of current viewpoint-oriented requirements approaches and shows how it improves on them. A simple example of a bank auto-teller system is used to demonstrate the method.

Diffusion of Open Source ERP Systems Development: How Users Are Involved

“…The prototypes are presented to various stakeholders to identify problems. This is consistent with the view that Kotonya and Sommerville (1998) give on the analysis and negotiation phase. However, Night Labs differ since they do not use prototypes.…”

“…All organizations use a systematic approach to analyze requirements and describe the context for requirements, but also to find out if they have developed legally ok requirements. This is consistent with one of the main activities in the analysis phase that Sommerville and Sawyer (1997), Kotonya and Sommerville (1998) as well as Wiegers (1999) chooses to emphasize, claiming that this are distinctive part of the analysis and negotiation phase in requirements management. It is common for developer to prioritize customer requirements in the projects they are involved in.…”

“…The community is also involved in validation of requirements, except in Project Open, which consistently excludes the community from the entire requirements management process. A common feature of organizations is that they perform the various activities in order to check whether they have got the requirements right, which is consistent with the view that Kotonya andSommerville (1998), andSailor (1990) describes as one characteristic of the validation phase. Table 4 provides an overview of how organizations deal with requirements validation.…”

“…All organizations are working continuously to cope with changes that occur during the requirements engineering process, which is consistent with the picture Kotonya and Sommerville (1998) give as necessary when dealing with requirements. This suggests that all organizations are aware of that the context of requirements is changing, as several authors point out (Davis, 2005;Eriksson, 2008;Kotonya and Sommerville, 1998).…”

Facets of Software Evolution

“…But it is, once again, quite unsatisfactory to define something by just focusing on the relationship between this still undefined something and some other well-defined class of objects. Moreover, focusing exclusively on functionality may lead to contradictions when separating the required functional properties from nonfunctional requirements that must also be met [10]. It will also be totally at odds with established architectural principles claiming that the architecture of the building has to consider amongst other things the construction material to be used.…”