Learning requirements engineering within an engineering ethos

An interest in educating software developers within an engineering ethos may not align well with the characteristics of the discipline, nor address the underlying concerns of software practitioners. Education for software development needs to focus on creativity, adaptability and the ability to transfer knowledge. A change in the way learning is undertaken in a core Software Engineering unit within a university's engineering program demonstrates one attempt to provide students with a solid foundation in subject matter while at the same time exposing them to these real-world characteristics. It provides students with a process to deal with problems within a metacognitive-rich framework that makes complexity apparent and lets students deal with it adaptively. The results indicate that, while the approach is appropriate, student-learning characteristics need to be investigated further, so that the two aspects of learning may be aligned more closely

Requirements engineering and continuous deployment

This article summarizes the RE in the Age of Continuous Deployment panel at the 25th IEEE International Requirements Engineering Conference. It highlights two synergistic points (user stories and linguistic tooling) and one challenge (nonfunctional requirements) in fast-paced, agile-like projects, and recommends how to carry on the dialogue.Peer ReviewedPostprint (author's final draft

A framework for security requirements engineering

This paper presents a framework for security requirements elicitation and analysis, based upon the construction of a context for the system and satisfaction arguments for the security of the system. One starts with enumeration of security goals based on assets in the system. These goals are used to derive security requirements in the form of constraints. The system context is described using a problem-centered notation, then this context is validated against the security requirements through construction of a satisfaction argument. The satisfaction argument is in two parts: a formal argument that the system can meet its security requirements, and a structured informal argument supporting the assumptions expressed in the formal argument. The construction of the satisfaction argument may fail, revealing either that the security requirement cannot be satisfied in the context, or that the context does not contain sufficient information to develop the argument. In this case, designers and architects are asked to provide additional design information to resolve the problems

Towards a scope management of non-functional requirements in requirements engineering

Getting business stakeholders’ goals formulated clearly and project scope defined realistically increases the chance of success for any application development process. As a consequence, stakeholders at early project stages acquire as much as possible knowledge about the requirements, their risk estimates and their prioritization. Current industrial practice suggests that in most software projects this scope assessment is performed on the user’s functional requirements (FRs), while the non-functional requirements (NFRs) remain, by and large, ignored. However, the increasing software complexity and competition in the software industry has highlighted the need to consider NFRs as an integral part of software modeling and development. This paper contributes towards harmonizing the need to build the functional behavior of a system with the need to model the associated NFRs while maintaining a scope management for NFRs. The paper presents a systematic and precisely defined model towards an early integration of NFRs within the requirements engineering (RE). Early experiences with the model indicate its ability to facilitate the process of acquiring the knowledge on the priority and risk of NFRs

Rationale Management Challenges in Requirements Engineering

Rationale and rationale management have been playing an increasingly prominent role in software system development mainly due to the knowledge demand during system evaluation, maintenance, and evolution, especially for large and complex systems. The rationale management for requirements engineering, as a commencing and critical phase in software development life cycle, is still under-exploited. In this paper, we first survey briefly the state-of-the-art on rationale employment and applications in requirements engineering. Secondly, we identify the challenges in integrating rationale management in requirements engineering activities in order to promote further investigations and define a research agenda on rationale management in requirements engineering.

What If People Learn Requirements Over Time? A Rough Introduction to Requirements Economics

The overall objective of Requirements Engineering is to specify, in a systematic way, a system that satisfies the expectations of its stakeholders. Despite tremendous effort in the field, recent studies demonstrate this is objective is not always achieved. In this paper, we discuss one particularly challenging factor to Requirements Engineering projects, namely the change of requirements. We proposes a rough discussion of how learning and time explain requirements changes, how it can be introduced as a key variable in the formulation of the Requirements Engineering Problem, and how this induces costs for a requirements engineering project. This leads to a new discipline of requirements economics

Goal sketching: towards agile requirements engineering

This paper describes a technique that can be used as part of a simple and practical agile method for requirements engineering. The technique can be used together with Agile Programming to develop software in internet time. We illustrate the technique and introduce lazy refinement, responsibility composition and context sketching. Goal sketching has been used in a number of real-world development projects, one of which is described here