Year-end Sale % OFF 
Abstract
Desiderata is a general term for stakeholder needs, desires or preferences. Recent experiments demonstrate that presenting desiderata as templated requirements specifications leads to less creative solutions. However, these experiments do not establish how the presentation of desiderata affects design creativity. This study, therefore, aims to explore the cognitive mechanisms by which presenting desiderata as templated requirements specifications reduces creativity during software design. Forty-two software designers, organized into 21 pairs, participated in a dialog-based protocol study. Their interactions were transcribed and the transcripts were analyzed in two ways: (1) using inductive process coding and (2) using an a-priori coding scheme focusing on fixation and critical thinking. Process coding shows that participants exhibited seven categories of behavior: making design moves, uncritically accepting, rejecting, grouping, questioning, assuming and considering quality criteria. Closed coding shows that participants tend to accept given requirements and priority levels while rejecting newer, more innovative design ideas. Overall, the results suggest that designers fixate on desiderata presented as templated requirements specifications, hindering critical thinking. More precisely, requirements fixation mediates the negative relationship between specification formality and creativity.
Highlights
D IFFERENT organizations initiate new software projects in many different ways
Desiderata can be presented in many ways
Previous research showed that presenting desiderata as templated requirements specifications led to less creative designs
Summary
D IFFERENT organizations initiate new software projects in many different ways. For teams developing consumer applications and enterprise systems, the initiation process often seems to include: speaking with prospective users and other stakeholders about their needs, wants, preferences, etc.; synthesizing stakeholders’ opinions into some documents; determining the main features that the product will have; and creating mock-ups and diagrams illustrating the main features and user interfaces.These activities can be sequential, parallel, in different orders and performed by the same or different people. The more positivist side of requirements engineering (RE) research tends to assume that software projects have discoverable and documentable requirements, and that understanding these requirements is critical for designing good software systems [1], [2]. It seeks to elicit unambiguous, consistent, complete, feasible, traceable and verifiable requirements [3]. RE is about establishing a balance between the positivist approach where desiderata are considered as a singular truth embodied in the form of a formal specification, and the naturalistic approach where requirements are a product of the conflicts and contradictory viewpoints of the stakeholders involved (cf [25])
Sign-in/Register to view highlights & summary Talk to us
Join us for a 30 min session where you can share your feedback and ask us any queries you have
Schedule a callDisclaimer: All third-party content on this website/platform is and will remain the property of their respective owners and is provided on "as is" basis without any warranties, express or implied. Use of third-party content does not indicate any affiliation, sponsorship with or endorsement by them. Any references to third-party content is to identify the corresponding services and shall be considered fair use under The CopyrightLaw.
