Journal Article
Small-Scale Classification Schemes: A Field Study of Requirements Engineering
Fulltext URI
Document type
Text/Journal Article
Additional Information
Date
38047
Authors
Journal Title
Journal ISSN
Volume Title
Publisher
Springer
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.