Modelling the Strategic Alignment of Software Requirements using Goal Graphs

This paper builds on existing Goal Oriented Requirements Engineering (GORE) research by presenting a methodology with a supporting tool for analysing and demonstrating the alignment between software requirements and business objectives. Current GORE methodologies can be used to relate business goals to software goals through goal abstraction in goal graphs. However, we argue that unless the extent of goal-goal contribution is quantified with verifiable metrics and confidence levels, goal graphs are not sufficient for demonstrating the strategic alignment of software requirements. We introduce our methodology using an example software project from Rolls-Royce. We conclude that our methodology can improve requirements by making the relationships to business problems explicit, thereby disambiguating a requirement's underlying purpose and value.Comment: v2 minor updates: 1) bitmap images replaced with vector, 2) reworded related work ref[6] for clarit

Risk and Business Goal Based Security Requirement and Countermeasure Prioritization

Companies are under pressure to be in control of their assets but at the same time they must operate as efficiently as possible. This means that they aim to implement “good-enough security” but need to be able to justify their security investment plans. Currently companies achieve this by means of checklist-based security assessments, but these methods are a way to achieve consensus without being able to provide justifications of countermeasures in terms of business goals. But such justifications are needed to operate securely and effectively in networked businesses. In this paper, we first compare a Risk-Based Requirements Prioritization method (RiskREP) with some requirements engineering and risk assessment methods based on their requirements elicitation and prioritization properties. RiskREP extends misuse case-based requirements engineering methods with IT architecture-based risk assessment and countermeasure definition and prioritization. Then, we present how RiskREP prioritizes countermeasures by linking business goals to countermeasure specification. Prioritizing countermeasures based on business goals is especially important to provide the stakeholders with structured arguments for choosing a set of countermeasures to implement. We illustrate RiskREP and how it prioritizes the countermeasures it elicits by an application to an action case

Scope Management of Non-Functional Requirements

In order to meet commitments in software projects, a realistic assessment must be made of project scope. Such an assessment relies on the availability of knowledge on the user-defined project requirements and their effort estimates and priorities, as well as their risk. This knowledge enables analysts, managers and software engineers to identify the most significant requirements from the list of requirements initially defined by the user. In practice, this scope assessment is applied to the Functional Requirements (FRs) provided by users who are unaware of, or ignore, the Non-Functional Requirements (NFRs). This paper presents ongoing research which aims at managing NFRs during the software development process. Establishing the relative priority of each NFR, and obtaining a rough estimate of the effort and risk associated with it, is integral to the software development process and to resource management. Our work extends the taxonomy of the NFR framework by integrating the concept of the "hardgoal". A functional size measure of NFRs is applied to facilitate the effort estimation process. The functional size measurement method we have chosen is COSMICFFP, which is theoretically sound and the de facto standard in the software industry

A framework for the definition of metrics for actor-dependency models

Actor-dependency models are a formalism aimed at providing intentional descriptions of processes as a network of dependency relationships among actors. This kind of models is currently widely used in the early phase of requirements engineering as well as in other contexts such as organizational analysis and business process reengineering. In this paper, we are interested in the definition of a framework for the formulation of metrics over these models. These metrics are used to analyse the models with respect to some properties that are interesting for the system being modelled, such as security, efficiency or accuracy. The metrics are defined in terms of the actors and dependencies of the model. We distinguish three different kinds of metrics that are formally defined, and then we apply the framework at two different layers of a meeting scheduler system.Postprint (published version

A goal-oriented requirements modelling language for enterprise architecture

Methods for enterprise architecture, such as TOGAF, acknowledge the importance of requirements engineering in the development of enterprise architectures. Modelling support is needed to specify, document, communicate and reason about goals and requirements. Current modelling techniques for enterprise architecture focus on the products, services, processes and applications of an enterprise. In addition, techniques may be provided to describe structured requirements lists and use cases. Little support is available however for modelling the underlying motivation of enterprise architectures in terms of stakeholder concerns and the high-level goals that address these concerns. This paper describes a language that supports the modelling of this motivation. The definition of the language is based on existing work on high-level goal and requirements modelling and is aligned with an existing standard for enterprise modelling: the ArchiMate language. Furthermore, the paper illustrates how enterprise architecture can benefit from analysis techniques in the requirements domain

Revisiting the Core Ontology and Problem in Requirements Engineering

In their seminal paper in the ACM Transactions on Software Engineering and Methodology, Zave and Jackson established a core ontology for Requirements Engineering (RE) and used it to formulate the "requirements problem", thereby defining what it means to successfully complete RE. Given that stakeholders of the system-to-be communicate the information needed to perform RE, we show that Zave and Jackson's ontology is incomplete. It does not cover all types of basic concerns that the stakeholders communicate. These include beliefs, desires, intentions, and attitudes. In response, we propose a core ontology that covers these concerns and is grounded in sound conceptual foundations resting on a foundational ontology. The new core ontology for RE leads to a new formulation of the requirements problem that extends Zave and Jackson's formulation. We thereby establish new standards for what minimum information should be represented in RE languages and new criteria for determining whether RE has been successfully completed.Comment: Appears in the proceedings of the 16th IEEE International Requirements Engineering Conference, 2008 (RE'08). Best paper awar