Please use this identifier to cite or link to this item:
|Title:||Small-Scale Classification Schemes: A Field Study of Requirements Engineering|
|Keywords:||classification schemes;conceptual design;cooperative work;coordination;requirements engineering;requirements specification;small-scale classification|
|metadata.dc.relation.ispartof:||Computer Supported Cooperative Work (CSCW): Vol. 13, No. 1|
|Series/Report no.:||Computer Supported Cooperative Work (CSCW)|
|Abstract:||Small-scale classification schemes are used extensively in the coordination of cooperative work. This study investigates the creation and use of a classification scheme for handling the system requirements during the redevelopment of a nation-wide information system. This requirements classification inherited a lot of its structure from the existing system and rendered requirements that transcended the framework laid out by the existing system almost invisible. As a result, the requirements classification became a defining element of the requirements-engineering process, though its main effects remained largely implicit. The requirements classification contributed to constraining the requirements-engineering process by supporting the software engineers in maintaining some level of control over the process. This way, the requirements classification provided the software engineers with an important means of discretely balancing the contractual aspect of requirements engineering against facilitating the users in an open-ended search for their system requirements. The requirements classification is analysed in terms of the complementary concepts of boundary objects and coordination mechanisms. While coordination mechanisms focus on how classification schemes enable cooperation among people pursuing a common goal, boundary objects embrace the implicit consequences of classification schemes in situations involving conflicting goals. Moreover, the requirements specification focused on functional requirements and provided little information about why these requirements were considered relevant. This stands in contrast to the discussions at the project meetings where the software engineers made frequent use of both abstract goal descriptions and concrete examples to make sense of the requirements. This difference between the written requirements specification and the oral discussions at the meetings may help explain software engineers' general preference for people, rather than documents, as their information sources.|
|Appears in Collections:||JCSCW Vol. 13 (2004)|
Files in This Item:
There are no files associated with this item.
Items in DSpace are protected by copyright, with all rights reserved, unless otherwise indicated.