From inconsistency handling to non-canonical requirements management: A logical perspective

As a class of defects in software requirements specification, inconsistency has been widely studied in both requirements engineering and software engineering. It has been increasingly recognized that maintaining consistency alone often results in some other types of non-canonical requirements, including incompleteness of a requirements specification, vague requirements statements, and redundant requirements statements. It is therefore desirable for inconsistency handling to take into account the related non-canonical requirements in requirements engineering. To address this issue, we propose an intuitive generalization of logical techniques for handling inconsistency to those that are suitable for managing non-canonical requirements, which deals with incompleteness and redundancy, in addition to inconsistency. We first argue that measuring non-canonical requirements plays a crucial role in handling them effectively. We then present a measure-driven logic framework for managing non-canonical requirements. The framework consists of five main parts, identifying non-canonical requirements, measuring them, generating candidate proposals for handling them, choosing commonly acceptable proposals, and revising them according to the chosen proposals. This generalization can be considered as an attempt to handle non-canonical requirements along with logic-based inconsistency handling in requirements engineering.

Towards an understanding of the causes and effects of software requirements change: two case studies

Changes to software requirements not only pose a risk to the successful delivery of software applications but also provide opportunity for improved usability and value. Increased understanding of the causes and consequences of change can support requirements management and also make progress towards the goal of change anticipation. This paper presents the results of two case studies that address objectives arising from that ultimate goal. The first case study evaluated the potential of a change source taxonomy containing the elements ‘market’, ‘organisation’, ‘vision’, ‘specification’, and ‘solution’ to provide a meaningful basis for change classification and measurement. The second case study investigated whether the requirements attributes of novelty, complexity, and dependency correlated with requirements volatility. While insufficiency of data in the first case study precluded an investigation of changes arising due to the change source of ‘market’, for the remainder of the change sources, results indicate a significant difference in cost, value to the customer and management considerations. Findings show that higher cost and value changes arose more often from ‘organisation’ and ‘vision’ sources; these changes also generally involved the co-operation of more stakeholder groups and were considered to be less controllable than changes arising from the ‘specification’ or ‘solution’ sources. Results from the second case study indicate that only ‘requirements dependency’ is consistently correlated with volatility and that changes coming from each change source affect different groups of requirements. We conclude that the taxonomy can provide a meaningful means of change classification, but that a single requirement attribute is insufficient for change prediction. A theoretical causal account of requirements change is drawn from the implications of the combined results of the two case studies.

Eliciting Security Requirements and Tracing them to Design: An Integration of Common Criteria, Heuristics, and UMLsec

Building secure systems is difficult for many reasons. This paper deals with two of the main challenges: (i) the lack of security expertise in development teams, and (ii) the inadequacy of existing methodologies to support developers who are not security experts. The security standard ISO 14508 (Common Criteria) together with secure design techniques such as UMLsec can provide the security expertise, knowledge, and guidelines that are needed. However, security expertise and guidelines are not stated explicitly in the Common Criteria. They are rather phrased in security domain terminology and difficult to understand for developers. This means that some general security and secure design expertise are required to fully take advantage of the Common Criteria and UMLsec. In addition, there is the problem of tracing security requirements and objectives into solution design,which is needed for proof of requirements fulfilment. This paper describes a security requirements engineering methodology called SecReq. SecReq combines three techniques: the Common Criteria, the heuristic requirements editorHeRA, andUMLsec. SecReqmakes systematic use of the security engineering knowledge contained in the Common Criteria and UMLsec, as well as security-related heuristics in the HeRA tool. The integrated SecReq method supports early detection of security-related issues (HeRA), their systematic refinement guided by the Common Criteria, and the ability to trace security requirements into UML design models. A feedback loop helps reusing experiencewithin SecReq and turns the approach into an iterative process for the secure system life-cycle, also in the presence of system evolution.

Case-based analysis in user requirements modelling for knowledge construction

Context: Learning can be regarded as knowledge construction in which prior knowledge and experience serve as basis for the learners to expand their knowledge base. Such a process of knowledge construction has to take place continuously in order to enhance the learners’ competence in a competitive working environment. As the information consumers, the individual users demand personalised information provision which meets their own specific purposes, goals, and expectations. Objectives: The current methods in requirements engineering are capable of modelling the common user’s behaviour in the domain of knowledge construction. The users’ requirements can be represented as a case in the defined structure which can be reasoned to enable the requirements analysis. Such analysis needs to be enhanced so that personalised information provision can be tackled and modelled. However, there is a lack of suitable modelling methods to achieve this end. This paper presents a new ontological method for capturing individual user’s requirements and transforming the requirements onto personalised information provision specifications. Hence the right information can be provided to the right user for the right purpose. Method: An experiment was conducted based on the qualitative method. A medium size of group of users participated to validate the method and its techniques, i.e. articulates, maps, configures, and learning content. The results were used as the feedback for the improvement. Result: The research work has produced an ontology model with a set of techniques which support the functions for profiling user’s requirements, reasoning requirements patterns, generating workflow from norms, and formulating information provision specifications. Conclusion: The current requirements engineering approaches provide the methodical capability for developing solutions. Our research outcome, i.e. the ontology model with the techniques, can further enhance the RE approaches for modelling the individual user’s needs and discovering the user’s requirements.

A lightweight technique for assessing risks in requirements analysis

A simple and practical technique for assessing the risks, that is, the potential for error, and consequent loss, in software system development, acquired during a requirements engineering phase is described. The technique uses a goal-based requirements analysis as a framework to identify and rate a set of key issues in order to arrive at estimates of the feasibility and adequacy of the requirements. The technique is illustrated and how it has been applied to a real systems development project is shown. How problems in this project could have been identified earlier is shown, thereby avoiding costly additional work and unhappy users.

User-intimate requirements hierarchy resolution framework (UI-REF)

Abstract. This paper presents the User-Intimate Requirements Hierarchy Resolution Framework (UI-REF) based on earlier work (Badii 1997-2008) to optimise the requirements engineering process particularly to support userintimate interactive systems co-design. The stages of the UI- EF framework for requirements resolution-and-prioritisation are described. UI-REF has been established to ensure that the most-deeply-valued needs of the majority of stakeholders are elicited and ranked, and the root rationale for requirements evolution is trace-able and contextualised so as to help resolve stakeholder conflicts. UI-REF supports the dynamically evolving requirements of the users in the context of digital economy as under-pinned by online service provisioning. Requirements prioritisation in UI-REF is fully resolved while a promotion path for lower priority requirements is delineated so as to ensure that as the requirements evolve so will their resolution and prioritisation.

A lightweight technique for assessing risks in requirements analysis

A simple and practical technique for assessing the risks, that is, the potential for error, and consequent loss, in software system development, acquired during a requirements engineering phase is described. The technique uses a goal-based requirements analysis as a framework to identify and rate a set of key issues in order to arrive at estimates of the feasibility and adequacy of the requirements. The technique is illustrated and how it has been applied to a real systems development project is shown. How problems in this project could have been identified earlier is shown, thereby avoiding costly additional work and unhappy users.

Articulation of information requirements for personalised knowledge and construction

The quality of information provision influences considerably knowledge construction driven by individual users’ needs. In the design of information systems for e-learning, personal information requirements should be incorporated to determine a selection of suitable learning content, instructive sequencing for learning content, and effective presentation of learning content. This is considered as an important part of instructional design for a personalised information package. The current research reveals that there is a lack of means by which individual users’ information requirements can be effectively incorporated to support personal knowledge construction. This paper presents a method which enables an articulation of users’ requirements based on the rooted learning theories and requirements engineering paradigms. The user’s information requirements can be systematically encapsulated in a user profile (i.e. user requirements space), and further transformed onto instructional design specifications (i.e. information space). These two spaces allow the discovering of information requirements patterns for self-maintaining and self-adapting personalisation that enhance experience in the knowledge construction process.

Goal sketching: an agile approach to clarifying requirements

This paper describes a technique that can be used as part of a simple and practical agile method for requirements engineering. It is based on disciplined goal-responsibility modelling but eschews formality in favour of a set of practicality objectives. 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.

Conceptualising the requirements of CRM from an organisational perspective : a review of the literature

For an organisation to undertake a Customer Relationship Management (CRM) implementation program it needs to consider a multitude of requirements. Some authors have hinted at viewing CRM within a wider perspective than just  customer centric perspectives. The aim of this paper is to discuss the domain and conceptualise some of the requirements of CRM from an organisation’s point of view. However, CRM needs to be identified as the whole organisation, including its internal and external environments. Undertaking CRM in any organisation needs to be preceded by a sequence of stages. An organization needs to develop a roadmap outlining the path to become CRM centric. Therefore an organisation should address, or at least consider, a list of those factors at every stage of a CRM implementation program, for an implementation program to be effective. The main focus of literature in CRM has been customer centric. This paper, being the first stage of much wider research, will focus on the organisation and the internal environment. This paper will identify three information systems (IS) and information technology (IT) requirements in organisations that are integral parts of CRM. These need to achieve a level of synergy for successful CRM. To understand these three requirements (front-end systems, back-end systems, and datahandling technologies) in a CRM project is too great in magnitude at this early stage of the research. This paper begins to draw together the tenuous links between the three requirements of information systems (IS) and information technology (IT) systems. Writing this paper and shifting its focus towards requirements engineering, the author has realised that a whole area of literature has to be explored, because CRM is another IS implementation.

Influence of stakeholder communication on consensus making in requirements negotiation

Consensus building is essential in aligning multiple stakeholder viewpoints which are commonly emerging during the process of requirements elicitation, analysis and validation [15]. In fact, agreement among diverse groups of stakeholders is deemed prerequisite to establishing project cooperation and collaboration. While individuals frequently rank the importance of their personal goals over the goals of an organisation, having an appropriate strategy for finding common ground among individuals is crucial to any project's success. This paper therefore explores factors that influence the consensus making process and develops a model that helps with understanding the role of consensus specifically during the elicitation phase of the Requirements Engineering process.

Creativity, requirements and perspectives

Is there room for more creativity in information systems? This article grew out of an AWRE'04 panel discussion on creativity in requirements engineering, and the impact of requirements engineering on creativity in systems engineering and systems use. Both panel and article were motivated by the goal of identifying a framework for understanding creativity in a larger context and thus establishing a potential structure for future research. The authors' research backgrounds differ widely and, at times, our views conflict occasionally, quite sharply. We make underlying world views - our own and those of relevant disciplines - explicit; identify the paradox caused by the need to be functionally creative while leaving room for creativity in successive stages; and argue for a multi paradigm framework for resolving this paradox.

GUITAR: An ontology-based automated requirements analysis tool

Combining goal-oriented and use case modeling has been proven to be an effective method in requirements elicitation and elaboration. However, current requirements engineering approaches generally lack reliable support for automated analysis of such modeled artifacts. To address this problem, we have developed GUITAR, a tool which delivers automated detection of incorrectness, incompleteness and inconsistency between artifacts. GUITAR is based on our goal-use case integration meta-model and ontologies of domain knowledge and semantics. GUITAR also provides comprehensive explanations for detected problems and can suggest resolution alternatives.