Gameplay requirements are central to game development. In the business context of massive multiplayer online role-playing games (MMOGs) where game companies’ revenues rely on players' monthly subscriptions, gameplay is also recognized as the key to player retention. However, information on what gameplay requirements are and how practitioners 'engineer' them in real life is scarce. This exploratory study investigates how practitioners developing MMOGs reason about gameplay requirements and handle them in their projects. 12 practitioners from three leading MMOGs-producing companies were interviewed and their gameplay requirements documents were reviewed. The study’s most important findings are that in MMOG projects: (1) gameplay requirements are co-created with players, (2) are perceived and treated by practitioners as sets of choices and consequences, (3) gameplay is endless within a MMOG, and while gameplay requirements do not support any game-end goal, they do support a level-end goal, (4) 'paper-prototyping' and play-testing are pivotal to gameplay validation, (5) balancing the elements of the gameplay is an on-going task, perceived as the most difficult and labor-consuming, (6) gameplay happens both in-game and out-of-the game. We conclude with discussion on validity threats to our results and on implications for research and practice.

Brain injuries (BI) are recognized as a major public health issue. Many therapists include commercial motion-based videogames in their therapy sessions to help make rehabilitation exercises fun and engaging. Our initial exploratory work exposed a need for tools to help therapists make evidence-based decisions when choosing commercial motion-games for their patients who have had a BI. Targeting this need, we are gathering requirements for a case-based recommender (CBR) system that will act as a decision tool for therapists. In this paper, we describe our ongoing work as a case study that illustrates our multi-method approach of requirement elicitation for the CBR system. Our approach is comprised of four overlapping steps: (1) interviews with therapists, (2) onsite observations of therapy game sessions, (3) diary studies in which therapists record detailed information about game sessions, and (4) a user study of a CBR prototype interface. Leveraging direct interaction with end users (i.e., therapists), this case study demonstrates requirements gathering techniques to address needs of a special population (i.e., therapists who work with patients who had BIs) in a specialized context (i.e., inpatient rehabilitation using motion-based video games).

Requirements elicitation can be a challenging process in many systems. This challenge can be greater with a non-standard user population, such as visually impaired users. In this work, we report our experience and results of eliciting user requirements for a situation awareness indoor orientation system dedicated to the visually impaired. We elicited our initial system requirements through three different studies that focus on users along with orientation and mobility instructors. Also, we performed a knowledge elicitation through our studies to formulate our system’s situation awareness requirements.

Requirements Engineering (RE) involves eliciting, understanding, and capturing system requirements, which naturally involves much uncertainty. During RE, analysts choose among alternative requirements, gradually narrowing down the system scope, and it is unlikely that all requirements uncertainties can be resolved before such decisions are made. There is a need for methods to support early requirements decision-making in the presence of uncertainty. We address this need by describing a novel technique for early decision-making and tradeoff analysis using goal models with uncertainty. The technique analyzes goal satisfaction over sets of models that can result from resolving uncertainty. Users make choices over possible analysis results, allowing our tool to find critical uncertainty reductions which must be resolved. An iterative methodology guides the resolution of uncertainties necessary to achieve desired levels of goal satisfaction, supporting trade-off analysis in the presence of uncertainty.

Missing requirements are known to be among the major sources of software failure. Incompleteness often results from poor anticipation of what could go wrong with an over-ideal system. Obstacle analysis is a model-based, goal-anchored form of risk analysis aimed at identifying, assessing and resolving exceptional conditions that may obstruct the behavioral goals of the target system. The obstacle resolution step is obviously crucial as it should result in more adequate and more complete requirements. In contrast with obstacle identification and assessment, however, this step has little support beyond a palette of resolution operators encoding tactics for producing isolated countermeasures to single risks. In particular, there is no single clue to date as to where and how such countermeasures should be integrated within a more robust goal model. To address this problem, the paper describes a systematic technique for integrating obstacle resolutions as countermeasure goals into goal models. The technique is shown to guarantee progress towards a complete goal model; it preserves the correctness of refinements in the overall model; and keeps the original, ideal model visible to avoid cluttering the latter with a combinatorial blow-up of exceptional cases. To allow for this, the goal specification language is slightly extended in order to capture exceptions to goals seperately and distinguish normal situations from exceptional ones. The proposed technique is evaluated on a non-trivial ambulance dispatching system.

We address the challenge of requirements engineering for sociotechnical systems, wherein humans and organizations supported by technical artifacts such as software interact with one another. Traditional requirements models emphasize the goals of the stakeholders above their interactions. However, the participants in a sociotechnical system may not adopt the goals of the stakeholders involved in its specification. We motivate, Protos, a requirements engineering approach that gives prominence to the interactions of autonomous parties and specifies a sociotechnical system in terms of its participants' social relationships, specifically, commitments. The participants can adopt any goal they like, a key basis for innovative behavior, as long as they interact according to the commitments. Protos describes an abstract requirements engineering process as a series of refinements that seek to satisfy stakeholder requirements by incrementally expanding a specification set and an assumption set, and reducing requirements until all requirements are accommodated. We demonstrate this process via the London Ambulance System described in the literature.

When elaborating compliance requirements, analysts need to follow the cross references in the underlying legal texts and consider the additional information in the cited provisions. To enable easier navigation and handling of cross references, automation is necessary for recognizing the natural language patterns used in cross reference expressions (cross reference detection), and for interpreting these expressions and linking them to the target provisions (cross reference resolution). In this paper, we propose a solution for automated detection and resolution of legal cross references. We ground our work on Luxembourg's legislative texts, both for studying the natural language patterns in cross reference expressions and for evaluating the accuracy and scalability of our solution.

Most systems and business processes in organizations need to comply with more than one law or regulation. Different regulations can partially overlap (e.g., one can be more detailed than the other) or even conflict with each other. In addition, one regulation can permit an action whereas the same action in another regulation might be mandatory or forbidden. In each of these cases, an organization needs to take different strategies. This paper presents an approach to handle different situations when comparing and attempting to comply with multiple regulations as part of a goal-oriented modeling framework named LEGAL-URN. This framework helps organizations find suitable trade-offs and priorities when complying with multiple regulations while at the same time trying to meet their own business objectives. The approach is illustrated with a case study involving a Canadian health care organization that must comply with four laws related to privacy, quality of care, freedom of information, and care consent.

Software engineers build software systems in increasingly regulated environments, and must therefore ensure that software requirements accurately represent obligations described in laws and regulations. Prior research has shown that graduate-level software engineering students are not able to reliably determine whether software requirements meet or exceed their legal obligations and that professional software engineers are unable to accurately classify cross-references in legal texts. However, no research has determined whether software engineers are able to identify and classify important ambiguities in laws and regulations. Ambiguities in legal texts can make the difference between requirements compliance and non-compliance. Herein, we develop a ambiguity taxonomy based on software engineering, legal, and linguistic understandings of ambiguity. We examine how 17 technologists and policy analysts in a graduate-level course use this taxonomy to identify ambiguity in a legal text. We also examine the types of ambiguities they found and whether they believe those ambiguities should prevent software engineers from implementing software that complies with the legal text. Our research suggests that ambiguity is prevalent in legal texts. In 50 minutes of examination, participants in our case study identified on average 33.47 ambiguities in 104 lines of legal text using our ambiguity taxonomy as a guideline. Our analysis suggests (a) that participants used the taxonomy as intended: as a guide and (b) that the taxonomy provides adequate coverage (97.5%) of the ambiguities found in the legal text.

Software systems could be seen as a hierarchy of features which are evolving due to the dynamic of the working environments. The companies who build software thus need to make an appropriate strategy, which takes into consideration of such dynamic, to select features to be implemented. In this work, we propose an approach to facilitate such selection by providing a means to capture the uncertainty of evolution in feature models. We also provide two analyses to support the decision makers. The approach is exemplified in the Smart Grid scenario.

Security is an increasingly important quality facet in modern information systems and needs to be retained. Due to a constantly changing environment, long-living software systems "age" not by wearing out, but by failing to keep up-to-date with their environment. The problem is that requirements engineers usually do not have a complete overview of the security-related knowledge necessary to retain security of long-living software systems. This includes security standards, principles and guidelines as well as reported security incidents. In this paper, we focus on the identification of known vulnerabilities (and their variations) in natural-language requirements by leveraging security knowledge. For this purpose, we present an integrative security knowledge model and a heuristic method to detect vulnerabilities in requirements based on reported security incidents. To support knowledge evolution, we further propose a method based on natural language analysis to refine and to adapt security knowledge. Our evaluation indicates that the proposed assessment approach detects vulnerable requirements more reliable than other methods (Bayes, SVM, k-NN). Thus, requirements engineers can react faster and more effectively to a changing environment that has an impact on the desired security level of the information system.

Requirements-driven approaches provide an effective mechanism for self-adaptive systems by reasoning over their runtime requirements models to make adaptation decisions. However, such approaches usually assume that the relations among alternative behaviours, environmental parameters and requirements are clearly understood, which is often simply not true. Moreover, they do not consider the influence of the current behaviour of an executing system on adaptation decisions. In this paper, we propose an improved requirementsdriven self-adaptation approach that combines goal reasoning and case-based reasoning. In the approach, past experiences of successful adaptations are retained as adaptation cases, which are described by not only requirements violations and contexts, but also currently deployed behaviours. The approach does not depend on a set of original adaptation cases, but employs goal reasoning to provide adaptation solutions when no similar cases are available. And case-based reasoning is used to provide more precise adaptation decisions that better reflect the complex relations among requirements violations, contexts, and current behaviours by utilizing past experiences. Our experimental study with an online shopping benchmark shows that our approach outperforms both requirements-driven approach and case-based reasoning approach in terms of adaptation effectiveness and overall quality of the system.

One of the surprising observations of traceability in practice is the under-utilization of existing trace links. Organizations often create links in order to meet compliance requirements, but then fail to capitalize on the potential benefits of those links to provide support for activities such as impact analysis, test regression selection, and coverage analysis. One of the major adoption barriers is caused by the lack of accessibility to the underlying trace data and the lack of skills many project stakeholders have for formulating complex trace queries. To address these challenges we introduce TiQi, a natural language approach, which allows users to write or speak trace queries in their own words. TiQi includes a vocabulary and associated grammar learned from analyzing NL queries collected from trace practitioners. It is evaluated against trace queries gathered from trace practitioners for two different project environments.

Just-in-time requirements management, characterized by lightweight representation and continuous refinement of requirements, fits many iterative and incremental development projects. Being lightweight and flexible, however, can cause wasteful and procrastinated implementation, leaving certain stakeholder goals not satisfied. This paper proposes traceability-enabled refactoring aimed at fulfilling more requirements fully. We make a novel use of requirements traceability to accurately locate where the software should be refactored, and develop a new scheme to precisely determine what refactorings should be applied to the identified places. Our approach is evaluated through an industrial study. The results show that our approach recommends refactorings more appropriately than a contemporary recommender. Keywords: requirements management; just-in-time requirements; traceability; refactoring;

Traceability among requirements artifacts (and beyond, in certain cases all the way to actual implementation) has long been identified as a critical challenge in industrial practice. Manually establishing and maintaining such traces is a high-skill, labour-intensive job. It is often the case that the ideal person for the job also has other, highly critical tasks to take care of, so offering semi-automated support for the management of traces is an effective way of improving the efficiency of the whole development process. In this paper, we present a technique to exploit the information contained in previously defined traces, in order to facilitate the creation and ongoing maintenance of traces, as the requirements evolve. A case study on a reference dataset is employed to measure the effectiveness of the technique, compared to other proposals from the literature.

App stores allow users to submit feedback for downloaded apps in form of star ratings and text reviews. Recent studies analyzed this feedback and found that it includes information useful for app developers, such as user requirements, ideas for improvements, user sentiments about specific features, and descriptions of experiences with these features. However, for many apps, the amount of reviews is too large to be processed manually and their quality varies largely. The star ratings are given to the whole app and developers do not have a mean to analyze the feedback for the single features.In this paper we propose an automated approach that helps developers filter,aggregate, and analyze user reviews. We use natural language processing techniques to identify fine-grained app features in the reviews. We then extract the user sentiments about the identified features and give them a general score across all reviews. Finally, we use topic modeling techniques to group fine-grained features into more meaningful high-level features. We evaluated our approach with 7 apps from the Apple App Store and Google Play Store and compared its results with a manually, peer-conducted analysis of the reviews. On average, our approach has a precision of 0.59 and a recall of 0.51. The extracted features were coherent and relevant to requirements evolution tasks. Our approach can help app developers to systematically analyze user opinions about single features and filter irrelevant reviews.

Natural language text sources have increasingly been used to develop new methods and tools for extracting and analyzing requirements. To validate these new approaches, researchers rely on a small number of trained experts to perform a labor-intensive manual analysis of the text. The time and resources needed to conduct manual extraction, however, has limited the size of case studies and thus the generalizability of results. To begin to address this issue, we conducted three experiments to evaluate crowdsourcing a manual requirements extraction task to a larger number of untrained workers. In these experiments, we carefully balance worker payment and overall cost, as well as worker training and data quality to study the feasibility of distributing requirements extraction to the crowd. The task consists of extracting descriptions of data collection, sharing and usage requirements from privacy policies. We present results from two pilot studies and a third experiment to justify applying a task decomposition approach to requirements extraction. Our contributions include the task decomposition workflow and three metrics for measuring worker performance. The final evaluation shows a 60% reduction in the cost of manual extraction with a 16% increase in extraction coverage.

Novel envisioned systems face the risk of rejection by their target user community and the requirements engineer must be sensitive to the factors that will determine acceptance or rejection. Conventionally, technology acceptance is determined by perceived usefulness and ease-of-use, but in some domains, other factors play an important role. In healthcare systems, particularly, ethical and emotional factors can be crucial. In this paper we describe an approach to requirements discovery that we developed for such systems. We describe how we have applied our approach to a novel system to passively monitor users for signs of cognitive decline consistent with the onset of dementia. A key challenge was eliciting users’ reactions to emotionally-charged events before they experienced them. Our goal was to understand the range of users’ emotional responses and their values and motivations, by a combination of manual and automated text analysis of interview transcripts. The analysis enabled formulation of requirements that would maximise the likelihood of acceptance of the system. The problem was heightened by the fact that the key stakeholders were elderly people who represent a poorly-studied user constituency. We discuss the elicitation and analysis methodologies used, and our experience with tool support. We conclude by reflecting on the issues affect for RE and for technology acceptance.

Abstract: Natural language artifacts, such as requirements specifications, often explicitly state the security requirements for software systems. However, these artifacts may also imply additional security requirements that developers may overlook but should consider to strengthen the overall security of the system. The goal of this research is to aid requirements engineers in producing a more comprehensive and classified set of security requirements by (1) automatically identifying security-relevant sentences in natural language requirements artifacts, and (2) providing context-specific security requirements templates to help translate the security-relevant sentences into functional security requirements. Using machine learning techniques, we have developed a tool-assisted process that takes as input a set of natural language artifacts. Our process automatically identifies security-relevant sentences in the artifacts and classifies them according to the security objectives, either explicitly stated or implied by the sentences. We classified 10,963 sentences in six different documents from healthcare domain and extracted corresponding security objectives. Our manual analysis showed that 46% of the sentences were security-relevant. Of these, 28% explicitly mention security while 72% of the sentences are functional requirements with security implications. Using our tool, we correctly predict and classify 82% of the security objectives for all the sentences (precision). We identify 79% of all security objectives implied by the sentences within the documents (recall). Based on our analysis, we develop context-specific templates that can be instantiated into a set of functional security requirements by filling in key information from security-relevant sentences. Keywords: Security Requirements; Security Objectives; Natural Language Artifacts; Machine Learning;

Security requirements patterns represent reusable security practices that software engineers can apply to improve security in their system. Reusing best practices that others have employed could have a number of benefits, such as decreasing the time spent in the requirements elicitation process or improving the quality of the product by reducing product failure risk. Pattern selection can be difficult due to the diversity of applicable patterns from which an analyst has to choose. The challenge is that identifying the most appropriate pattern for a situation can be cumbersome and time-consuming. We propose a new method that combines an inquiry-cycle based approach with the feature diagram notation to review only relevant patterns and quickly select the most appropriate patterns for the situation. Similar to patterns themselves, our approach captures expert knowledge to relate patterns based on decisions made by the pattern user. The resulting pattern hierarchies allow users to be guided through these decisions by questions, which introduce related patterns in order to help the pattern user select the most appropriate patterns for their situation, thus resulting in better requirement generation. We evaluate our approach using access control patterns in a pattern user study.

Adaptive security systems aim to protect critical assets in the face of changes in their operational environment. We have argued that incorporating an explicit representation of the environment's topology enables reasoning on the location of assets being protected and the proximity of potentially harmful agents. This paper proposes to engineer topology aware adaptive security systems by identifying violations of security requirements that may be caused by topological changes, and selecting a set of security controls that prevent such violations. Our approach focuses on physical topologies; it maintains at runtime a live representation of the topology which is updated when assets or agents move, or when the structure of the physical space is altered. When the topology changes, we look ahead at a subset of the future system states. These states are reachable when the agents move within the physical space. If security requirements can be violated in future system states, a configuration of security controls is proactively applied to prevent the system from reaching those states. Thus, the system continuously adapts to topological stimuli, while maintaining requirements satisfaction. Security requirements are formally expressed using a propositional temporal logic, encoding spatial properties in Computation Tree Logic (CTL). The Ambient Calculus is used to represent the topology of the operational environment - including location of assets and agents - as well as to identify future system states that are reachable from the current one. The approach is demonstrated and evaluated using a substantive example concerned with physical access control.

A growing number of software systems is characterized by continuous evolution as well as by significant interdependence with other systems (e.g. services, apps). Such software ecosystems promise increased innovation power and support for consumer oriented software services at scale, and are characterized by a certain openness of their information flows. While such openness supports project and reputation management, it also brings some challenges to Requirements Engineering (RE) within the ecosystem. We report from a mixed-method study of IBM's CLM ecosystem that uses an open commercial development model. We analyzed data from from interviews within several ecosystem actors, participatory observation, and software repositories, to describe the flow of product requirements information through the ecosystem, how the open communication paradigm in software ecosystems provides opportunities for 'just-in-time' RE, as well as some of the challenges faced when traditional requirements engineering approaches are applied within such an ecosystem. More importantly, we discuss two tradeoffs brought about the openness in software ecosystems: i) allowing open, transparent communication while keeping intellectual property confidential within the ecosystem, and ii) having the ability to act globally on a long-term strategy while empowering product teams to act locally to answer end-users' context specific needs in a timely manner.

The quality of the SRS (Software Requirements Specification) is the key to the success of software development. The inspection for the verification and validation of SRS are widely practiced, however, the techniques of inspection are rather ad hoc, and largely depend on the knowledge and skill of the people. This article proposes RISDM (Requirements Inspection Systems Design Methodology) to design the RIS (Requirements Inspection System) to be conducted by a third-party inspection team. The RISDM includes a meta-model and design process of RIS, PQM (Pragmatic Quality Model) of SRS, and a technique to generate inspection question set based on the PQM and PBR (Perspective-Based Reading). We have been applying the RIS designed by the proposed RISDM to more than 140 projects of a wide variety of software systems in NTT DATA for five years. By analyzing the statistics from the experience, we discovered some key quality characteristics of SRS reveal strong correlation to the project cost and level of quality to be used for evaluating the maturity of the SRS and predicting the risk. Keyword- Requirements Inspection; Requirements Verification and Validation; SRS; Pragmatic Quality Model; Question Set; Risk Prediction;

Abstract—A key challenge during stakeholder meetings is that of presenting the requirements and conflicts to stakeholders in a way that fosters co-responsibility and co-ownership regarding the conflicts and their resolution. In this paper, we propose a jigsaw puzzle metaphor to make identified conflicts explicit as well as an associated method to utilise this metaphor during stakeholder meetings. The metaphor provides an easy to understand language for stakeholders from otherwise diverse backgrounds. It enables stakeholders to work with a well-understood concept - that of building a system from misshapen pieces. These characteristics foster communication and team work, which improve commitment of stakeholders in co-authoring of requirements and co-responsibility in conflict handling. The gamification of conflict resolution also promotes a relaxed environment, which in turn improves team cooperation and creativity. Our experience in three user studies demonstrates that the jigsaw puzzle indeed improves such co-responsibility and co-ownership when compared with typical text-based representations of requirements. Index Terms—Requirements, conflict, creativity, game, jigsaw puzzle, stakeholders, team work, communication, metaphor, visualization.

Requirements engineering (RE), framed as a creative problem solving process, plays a key role in innovating more useful and novel requirements and improving a software system's sustainability. Existing approaches, such as creativity workshops and feature mining from web services, facilitate creativity by exploring a search space of partial and complete possibilities of requirements. To further advance the literature, we support creativity from a combinational perspective, i.e., making unfamiliar connections between familiar possibilities of requirements. In particular, we propose a novel framework that extracts familiar ideas from the requirements and stakeholders' comments using topic modeling and applies part-of-speech tagging to obtain unfamiliar idea combinations. We apply our framework on two large open-source software systems and further report a human subject evaluation. The results show that our framework complements existing approaches by generating original and relevant requirements in an automated manner. Keywords - Requirements engineering; creativity; topic modeling; requirements elicitation

Software requirements specifications often focus on functionality and fail to adequately capture quality concerns such as security, performance, and usability. In many projects, quality-related requirements are either entirely lacking from the specification or intermingled with functional concerns. This makes it difficult for stakeholders to fully understand the quality concerns of the system and to evaluate their scope of impact. In this paper we present a data mining approach for automating the extraction and subsequent modeling of quality concerns from requirements, feature requests, and online forums. We extend our prior work in mining quality concerns from textual documents and apply a sequence of machine learning steps to detect quality-related requirements, generate goal graphs contextualized by project-level information, and ultimately to visualize the results. We illustrate and evaluate our approach against two industrial health-care related systems.

An industrial experience of the use of a method for discovering customer requirements with which to configure an off-the-shelf software package for implementation is reported. The method uses an adapted form of product variability model to provide common ground between the customer and supplier about requirements and capabilities. An associated decision support software tool guides the supplier and customer through a model-based walkthrough to discover new requirements, based on equivalent capabilities described in the product variability model. We applied the method in the work processes of the commercial provider of a software-based learning management system, and collected quantitative and qualitative data from supplier-customer interactions. Our first experienc-es with the method led to an increased exposure and expression of customer requirements in the customer-supplier dialogue, compared to the baseline dialogue during software package demonstrations. The paper also reports some first lessons learned to improve the method and adopt its use with other software supplier organizations.

Abstract—Estimating the size of a software system is a critical task due to the implications the estimation has in the management of the development project. There are some widely accepted estimation techniques: Function Points, Use Case Points and Cosmic Points, but these techniques can only be applied after the availability of a requirements specification. In this paper, we propose an approach to estimate the size of an application previous to its requirements specification by using the application language itself, captured by the Language Extended Lexicon (LEL). Our approach is based on Use Case Points and on a technique which derives Use Cases from the LEL. The proposed approach provides a measure of the application’s size earlier than the usual techniques, thus reducing the effort needed to apply them. An initial experiment was conducted to evaluate the proposal.

Government laws and regulations increasingly place requirements on software systems. Ideally, experts trained in law will analyze and interpret legal texts to inform the software requirements process. However, in small companies and development teams with short launch cycles, individuals with little or no legal training will be responsible for compliance. Two specific challenges commonly faced by non-experts are deciding if their system is covered by a law, and then deciding whether two legal requirements are similar or different. In this study, we assess the ability of laypersons, technical professionals, and legal experts to judge the similarity between legal coverage conditions and requirements. In so doing, we discovered that legal experts achieved higher rates of consensus more frequently than technical professionals or laypersons and that all groups had slightly greater agreement when judging coverage conditions than requirements, measured by Fleiss’ Κ. When comparing judgments between groups using a consensus-based Cohen’s Kappa, we found that technical professionals and legal experts exhibited consistently greater agreement than that found between laypersons and legal experts, and that each group tended towards different justifications, such as laypersons and technical professionals tendency towards categorizing different coverage conditions or requirements as equivalent if they believed them to possess the same underlying intent.

Abstract - Evaluating the multidimensional and dynamic nature of IT business value is a continuous challenge. This paper examines how system dynamics can be used in evaluating IT business value in a company level. We approach IT business value as a web of impacts, where benefits and sacrifices are ultimately evaluated against company earnings logic. This study is based on an action research and covers a pilot project within two co-operating companies. System dynamics was utilised to construct a value creation model for an existing Gaming Management System. This value creation modelling covered two dimensions: 1) structural evaluation of IT impacts with cause-and-effect models, 2) dynamic evaluation and simulation of value realisation over time. As a result, value creation modelling was able to provide a visual overview of how IT impacts were linked to business value through value paths, and how much and when value was realised. Value creation modelling enabled prototyping of value realisation that can provide value based insights for development activities like requirements elicitation and analysis. The examined approach proved its potential for providing a common language for technology and business parties, thus improving IT business alignment. Index Terms — IT business value, evaluation, system dynamics

We propose a modeling language for non-functional requirements (NFRs) that views NFRs as requirements over qualities, mapping a software-related domain to a quality space. The language is compositional in that it allows (recursively) complex NFRs to be constructed in several ways. Importantly, the language allows the definition of requirements about the quality of fulfillment of other requirements, thus capturing, among others, the essence of probabilistic and fuzzy goals as proposed in the literature. We also offer a methodology for systematically refining informal NFRs elicited from stakeholders, resulting in unambiguous, de-idealized, and measurable requirements. The proposal is evaluated with a requirements dataset that includes 370 NFRs crossing 15 projects. The results suggest that our framework can adequately handle and clarify NFRs generated in practice.

Quality requirements, an important class of non-functional requirements, are inherently difficult to elicit. Particularly challenging is the definition of good-enough quality. The problem cannot be avoided though, because hitting the right quality level is critical. Too little quality leads to churn for the software product. Excessive quality generates unnecessary cost and drains the resources of the operating platform. To address this problem, we propose to elicit the specific relationships between software quality levels and their impacts for given quality attributes and stakeholders. An understanding of each such relationship can then be used to specify the right level of quality by deciding about acceptable impacts. The quality-impact relationships can be used to design and dimension a software system appropriately and, in a second step, to develop service level agreements that allow re-use of the obtained knowledge of good-enough quality. This paper describes an approach to elicit such quality–impact relationships and to use them for specifying quality requirements. The approach has been applied with user representatives in requirements workshops and used for determining Quality of Service (QoS) requirements based the involved users’ Quality of Experience (QoE). The paper describes the approach in detail and reports early experiences from applying the approach.

Bankdata and Mjølner have cooperated in the development of a new feature for 12 Danish mobile banking apps. Bankdata is the main system provider and Mjølner is subcontractor. Different teams from Bankdata have collected requirements, developed the necessary backend and middleware software, and designed the user interface. One team from Mjølner has implemented the app feature. The cooperation between the teams was centered around design-level requirements. Our contribution is to describe and discuss a number of lessons learned regarding requirements representations, requirements tools, and cooperation process; we have faced challenges, which were amplified by our distributed teams set-up. We also briefly describe a number of initiatives we have launched recently to alleviate the problems and improve the handling of design-level requirements in our future cooperation.

To meet end-user performance expectations, precise performance requirements are needed during development and testing, e.g., to conduct detailed performance and load tests. However, in practice, several factors complicate performance requirements elicitation: lacking skills in performance requirements engineering, outdated or unavailable functional specifications and architecture models, the specification of the system's context, lack of experience to collect good performance requirements in an industrial setting with very limited time, etc. From the small set of available non-functional requirements engineering methods, no method exists that alone leads to precise and complete performance requirements with feasible effort and which has been reported to work in an industrial setting. In this paper, we present our experiences in combining existing requirements engineering methods into a performance requirements method called PROPRE. It has been designed to require no up-to-date system documentation and to be applicable with limited time and effort. We have successfully applied PROPRE in an industrial case study from the process automation domain. Our lessons learned show that the stakeholders gathered good performance requirements which now improve performance testing.

Requirements engineering (RE) is widely recognized as a crucial factor for the success of software projects. Therefore, companies often request assessments of RE processes and resulting artifacts to identify issues and improvement potential. However, industry claims that current assessment approaches do not always fulfill their needs regarding efficiency and effectiveness. Motivated by needs of both, companies asking for an assessment, and a company in the role of an assessor, we have developed a lightweight, tool-supported RE assessment approach. Apart from presenting the approach, we also discuss early experiences we gained from applying our assessment approach in real-world industrial projects.

Business rules represent constraints in a domain, which need to be taken into account either during the development or the usage of a system. Motivated by the knowledge reuse potentials when developing systems within the same domain, we studied business rules in a large software company. We interviewed 11 experienced practitioners on how they understand, capture, and use business rules. We also studied the role of business rules in requirements engineering in the host organization. We found that practitioners have a very broad perception for this term, ranging from flows of business processes to directives for calling external system interfaces. We identified 27 types of rules, which are typically captured as a free text in requirements documents and other project documentation. Practitioners stated the need to capture this tacit form of domain knowledge and to trace it to other artifacts as it impacts all activities in a software engineering project. We distill our results in 17 findings and discuss the implications for researchers and practitioners.

User experience (UX) is difficult to quantify and thus more challenging to require and guarantee. It is also difficult to gauge the potential impact on users’ lived experience, especially at the earlier stages of the development life cycle, particularly before hi fidelity prototypes are developed. We believe that the enrolment process is a major hurdle for e-government service adoption and badly designed processes might result in negative repercussions for both the policy maker and the different user groups involved; non-adoption and resentment are two risks that may result in low return on investment (ROI), lost political goodwill and ultimately a negative lived experience for citizens. Identity assurance requirements need to balance out the real value of the assets being secured (risk) with the user groups’ acceptance thresholds (based on a continuous cost-benefit exercise factoring in cognitive and physical workload). Sentire is a persona-centric requirements framework built on and extending the Volere requirements process with UX-analytics, reusable user behavioural models and simulated user feedback through calibrated personas. In this paper we present a story on how Sentire was adopted in the development of a national public-facing e-service. Daily journaling was used throughout the project and a custom built cloud-based CASE tool was used to manage the whole process. This paper outlines our experiences and lessons learnt.

Increasingly, small to medium software producing organisations are working together in collaboration networks to supply complex compositions of their products and services to customers. In this paper, we present a case study of two software companies that are evolving their partnership towards the creation of a software ecosystem. We investigate the impacts of their tightening partnership on software product management, with a focus on requirements engineering practices. We observe that the requirements definition and negotiation processes are directly affected by their fluid collaborative and competitive relationships. Power disputes, volatile roles and mismatches in release synchronisation are also aspects observed in the studied software ecosystem. We extract several observations from the case study that support small to medium software firms in making decisions within their software ecosystem.

Sustainability is one of the main driving forces in our society. IT can also contribute to sustainable development, which goes beyond the energy consumed to produce and run the software product. Software is normally part of a wider context, social-technical systems, whose development can have a significant impact on the sustainability of its surroundings. A particular type of system with considerable sustainability impact are procurement systems. They normally affect the three pillars of sustainability: social, economic and environmental. This paper describes an experience on using goal modelling to incorporate sustainability into the procurement system of a large multinational energy company. The study highlights the advantages and challenges of introducing sustainability into private procurement systems, as well as the suitability of the technique for such a purpose. We believe this experience and its resulting model can be useful to other companies wishing to implement sustainable procurement processes.

State-of-the-art in Requirements Engineering offers many frameworks and techniques to enable requirements engineers in their work. However, for critical systems there are gaps in state-of-the-art, and these can result in dire consequences, potentially putting lives in danger and damage infrastructure and threaten the environment. A well known technique used to help requirements engineers to understand safety hazards situations in the context of safety-critical software is Fault Tree Analysis (FTA). This technique is a good one to decompose hazards identified in the system context into events that may put the system functionalities in risk. However, FTA does not offer a protocol of how to derive safety functional requirements from fault trees. In this paper we present a case study adopting a protocol to help requirements engineers to derive safety functional requirements from FTA. The proposed protocol was based on a study performed in a Brazilian company in the area of electronic medical devices. The development of prototype of a low cost insulin infusion pump, which is a critical system, offered the basis to propose and test a protocol to derive safety functional requirements from FTA. During the case study we collected evidences that help us to discuss if FTA is sufficient to guide software engineers to implement the corresponding control software and also if FTA offers enough information to help requirements engineers to derive safety functional requirements.

Using natural language is still a common form of writing software requirements. Tools and techniques to improve the quality of natural language requirements may give better results than attempts to convince industry to use something else. We have combined natural language requirements with tool support using boilerplates and domain ontologies, enabling detection of ambiguities and incompleteness in requirements. This paper reports on a case study where requirement analysts used the developed tool to analyze requirements for a safety-critical control system. The experience showed that people were able to use the tool to develop a domain ontology and apply boilerplates to describe requirements in a structured way, yielding requirements readable for humans and analyzable for the tool. The tool support improved the quality of requirements by reducing ambiguities and inconsistent use of terminology, removing redundant requirements, and improving partial and unclear requirements.

In the modern automotive industry, feature models have been widely used as a domain-specific requirements model, which can capture commonality and variability of a software product line through a set of features. Product variants can thus be configured by selecting different sets of features from the feature model. For feature-oriented requirements validation, the variability of feature sets often makes the hidden flaws such as behavioral inconsistencies of features, hardly to avoid. In this paper, we present an approach to feature-oriented requirements validation for automotive systems w.r.t both functional behaviors and non-functional properties. Our approach first starts with the behavioral specification of features and the associated requirements by following a restricted use case modeling approach, and then formalizes such specifications by using a formal yet literate language for analysis. We demonstrate the applicability of our approach through an industrial application of a vehicle locking-unlocking system.

Product knowledge plays an important role in identifying the requirements of the desired variant and configuring the existing product to the present needs of a customer. The success of a product-based business depends to a great extent on how efficiently and accurately the existing product knowledge is utilized for customization needs. Oftentimes however, product knowledge resides with few key individuals in an organization. In the absence of their involvement, project teams may redevelop product features unnecessarily, resulting in an effort overhead. Such overdependence poses a risk to projects. To identify the requirements for the variants accurately and efficiently, we need to have a thorough knowledge of the existing product features. In this paper, we discuss our work on representing product knowledge and reusing it in a Requirements Engineering (RE) exercise for a large project involving product customization. We present our experience from using the configurator for requirements gap analysis and customizations.

The importance of using formal methods and techniques for verification of requirements in the automotive industry has been greatly emphasized with the introduction of the new ISO26262 standard for road vehicles functional safety. The lack of support for formal modeling of requirements still represents an obstacle for the adoption of the formal methods in industry. This paper presents a case study that has been conducted in order to evaluate the difficulties inherent to the process of transforming the system requirements from their traditional written form into semi-formal notation. The case study focuses on a set of non-structured functional requirements for the Electrical and Electronic (E/E) systems inside heavy road vehicles, written in natural language, and reassesses the applicability of the extended Specification Pattern System (SPS) represented in a restricted English grammar. Correlating this experience with former studies, we observe that, as previously claimed, the concept of patterns is likely to be generally applicable for the automotive domain. Additionally, we have identified some potential difficulties in the transformation process, which were not reported by the previous studies and will be used as a basis for further research.