Introducing requirements engineering: how to make a cultural change happen in practice

Abstract

Introducing requirements engineering appears to involve a cultural change in organizations. Such a cultural change requires that requirements are defined and managed systematically, not only from a technical point of view, but also from the customers' and users' points of view. This paper describes experiences gained from four Finnish organizations that have started to introduce requirements engineering to their product development. The goal of this study was to evaluate which factors support, and which prevent, a cultural change. Linking business goals to technical requirements via user needs and user requirements was one of the key improvement actions that supported cultural change. Eliciting needs directly from real users and representing user requirements in the form of use cases were also key activities. However, bringing about a change of culture was challenging because both managers and product development engineers held beliefs that prevented active user need elicitation and systematic user requirement documentation.

Implementing requirements engineering processes throughout organizations: success factors and challenges

“…The long-term view and close involvement with industrial projects allowed the researchers to study issues related to RE process implementation in depth and from the perspective of practice. This paper complements our previous research work [26,27] that focused on the early stages of RE process improvement. The experience report [26] describes the lessons learned in two Finnish organizations at the beginning of the improvement projects.…”

“…The main lesson learned was that introducing RE can require cultural change [26]. The second paper [27] describes the factors that support, and those that prevent, the success of cultural change. After these two papers, we continued research work and here, we report the findings of the later stages of RE process improvement focusing on the organization-wide implementation of RE practices.…”

A Security Ontology for Security Requirements Elicitation

“…sniffing tool (e.g., Wireshark 2 ), spoofing tool (e.g. Subterfuge 3 ), scan port tool (e.g., Nmap 4 ) and others. c) Treatment dimension: Security goal: a security goal defines what a stakeholder/organization hopes to achieve in the future in terms of security [27], it states the intention to counter threats and satisfy security criteria.…”

“…Among the challenges for security projects is the difficulty of expressing security requirements and producing exhaustive specifications. A requirement prescribes a condition judged necessary for the system [3]. Security Requirements Engineering (SRE) methods derive security requirements using specific concepts, borrowed from security engineering paradigms [4].…”

Combining Perceptions and Prescriptions in Requirements Engineering Process Assessment: An Industrial Case Study

“…However, we also wanted to evaluate TelSoft against best practices to uncover additional vulnerabilities and opportunities. The REGPG assessment [26] as described in Section 2.1 was chosen because prior empirical research showed it to be useful for RE process improvement (e.g., [53]). Additionally, the authors had access to an REGPG assessment tool [37] that simplified data collection, provided process guidance, ensured accurate calculation of requirements maturity, and automated report generation.…”