Experiences with a Requirements Object Model

Abstract

[Context and motivation] Experiences in working with customers in the software development community have shown that the language used to talk about requirements is inconsistent. Because of this inconsistency, projects are struggling to develop products that meet the organizations’ goals. [Question/problem] An inconsistent terminology leads to barriers to communication, which increases both the cost and length of time of development. In addition, the artifacts of requirements planning efforts are often ill-defined, and the team creates products that are not aligned with the organization’s goals. [Principal ideas/results] As an attempt at resolving this inconsistent terminology and its fallout, this paper outlines the need for a common language. We propose a solution in the form of a Requirements Object Model (ROM) and study the use of the ROM in the requirements efforts on three software development projects. [Contribution] Evidence from these three projects demonstrates that the adoption of a common terminology leads to improved communication among project teams, and as a result, alignment about the business objectives for software development projects was achieved.