Karl Cox

B-SCP: A requirements analysis framework for validating strategic alignment of organizational IT based on strategy, context, and process

Abstract Ensuring that organizational IT is in alignment with and provides support for an organizations business strategy is critical to business success. Despite this, business strategy and strategic alignment issues are all but ignored in the requirements engineering research literature. We present B-SCP, a requirements engineering framework for organizational IT that directly addresses an organizations business strategy and the alignment of IT requirements with that strategy. B-SCP integrates the three themes of strategy, context, and process using a requirements engineering notation for each theme. We demonstrate a means of cross-referencing and integrating the notations with each other, enabling explicit traceability between business processes and business strategy. In addition, we show a means of defining requirements problem scope as a Jackson problem diagram by applying a business modeling framework. Our approach is illustrated via application to an exemplar. The case example demonstrates the feasibility of B-SCP, and we present a comparison with other approaches.

Validating strategic alignment of organizational IT requirements using goal modeling and problem diagrams

Ensuring that organizational IT is in alignment with and provides support for an organizations business strategy is critical to business success. We present an integrated approach to requirements engineering for organizational IT. To help validate IT-business strategy alignment, we propose a single model according to Jacksons problem diagram framework to encompass both business strategy and system requirements. We use an organizational strategy analysis technique to deconstruct business strategy. Strategy is then modeled using a goal-oriented requirements engineering notation; a framework for modeling an organizations business strategy proposed by the Business Rules Group is used to construct the goal model. We use Jacksons context diagrams to represent both business and IT domain context. Our approach is illustrated via application to an exemplar, constructed from a variety of sources in the literature describing Seven-Eleven Japan.

Evaluating guidelines for reporting empirical software engineering studies

BackgroundSeveral researchers have criticized the standards of performing and reporting empirical studies in software engineering. In order to address this problem, Jedlitschka and Pfahl have produced reporting guidelines for controlled experiments in software engineering. They pointed out that their guidelines needed evaluation. We agree that guidelines need to be evaluated before they can be widely adopted.AimThe aim of this paper is to present the method we used to evaluate the guidelines and report the results of our evaluation exercise. We suggest our evaluation process may be of more general use if reporting guidelines for other types of empirical study are developed.MethodWe used a reading method inspired by perspective-based and checklist-based reviews to perform a theoretical evaluation of the guidelines. The perspectives used were: Researcher, Practitioner/Consultant, Meta-analyst, Replicator, Reviewer and Author. Apart from the Author perspective, the reviews were based on a set of questions derived by brainstorming. A separate review was performed for each perspective. The review using the Author perspective considered each section of the guidelines sequentially.ResultsThe reviews detected 44 issues where the guidelines would benefit from amendment or clarification and 8 defects.ConclusionsReporting guidelines need to specify what information goes into what section and avoid excessive duplication. The current guidelines need to be revised and then subjected to further theoretical and empirical validation. Perspective-based checklists are a useful validation method but the practitioner/consultant perspective presents difficulties.Categories and Subject DescriptorsK.6.3 [Software Engineering]: Software Management—Software process.General TermsManagement, Experimentation.

The use and usefulness of the ISO/IEC 9126 quality standard

This paper reports an evaluation the utility of ISO/IEC 9126. ISO/IEC 9126 is an international standard intended to ensure the quality of all software-intensive products including safety-critical systems where lives are at risk if software components fail. Our evaluation exercise arose from an experiment that required a quality assessment of outputs of the design process. Although ISO/IEC 9126 is intended to support evaluation of intermediate software products, both the experimental subjects (158 final year computer science and engineering student) and experimenters found the standard was ambiguous in meaning, incomplete with respect to quality characteristics and overlapping with respect to measured properties. We conclude that ISO/IEC 9126 is not suitable for measuring design quality of software products. This casts serious doubts as to the validity of the standard as a whole.

Strategic alignment in requirements analysis for organizational IT: an integrated approach

We present an integrated approach to requirements engineering for organizational IT to help ensure IT-business strategy alignment. A single, unified model to enable validation of system requirements against business strategy is proposed. We use VMOST analysis to deconstruct business strategy. We then model strategy using a goal-oriented requirements engineering notation; this is done within the framework for modeling an organizations business strategy proposed by the Business Rules Group. We use Jacksons problem frames to represent business model context. Our approach is illustrated via an e-business case study of Seven-Eleven Japan taken from the literature.

Replicating the CREWS Use Case Authoring Guidelines Experiment

Use cases have become an important toolin software engineering. There has been much focus on the diagramnotation but relatively little on use-case descriptions. As partof a welcome and important research project into the use of scenariosin requirements engineering, the CREWS (Co-operative RequirementsEngineering With Scenarios, an EU funded ESPRIT project 21903)team has proposed a set of guidelines for writing use-case descriptions.This paper describes the replication of a CREWS project experimentthat suggests CREWS use-case authoring guidelines improve thecompleteness of use-case descriptions. Our results show thatthe CREWS guidelines do not necessarily improve the use-casedescriptions, only that the subjects implemented varying numbersof guidelines in their use-case descriptions. Subjects in thecontrol group implemented a significant percentage of the guidelinesby `chance. To further justify our results, we also apply adifferent marking scheme to compare with the CREWS approach.The results from the alternative marking approach show that therewas no significant difference between the qualities of the use-casedescriptions across the various groups.

Improving the quality of use case descriptions: empirical assessment of writing guidelines

Use cases are the main requirements vehicle of the UML and are used widely to specify systems. Hence, the need to write clear and accurate use case descriptions has a significant impact for many practitioners. However, many have pointed to weaknesses in the support offered to those writing use cases, and a number of authors advocate the use of rules in the composition and structuring of use case descriptions. These rules constrain the user, by only allowing certain grammatical constructions, typically guiding the structure or the style of the description For example, the CREWS research project pioneered Use Case Authoring Guidelines, suggesting that the adoption of such guidelines improved resulting use case descriptions. Replication of CREWS studies appeared to confirm the view that use case descriptions were improved through the application of guideline sets, but also noted that learning such rules presented a significant overhead. Hence, a leaner set of guidelines (the CP rules) was developed.This paper describes empirical work to assess the utility of these two sets of writing guidelines (CREWS and CP). In particular, descriptions are assessed against a set of established criteria—a use case quality description checklist, which the authors described in a previous paper.Our findings suggest that the leaner set of guidelines performs at least as well in terms of their ability to produce clear and accurate (comprehensible) descriptions. Hence, that a tractable set of rules may prove applicable to the industrial context, which could lead to effective validation of use cases.

Evaluating guidelines for empirical software engineering studies

Background. Several researchers have criticized the standards of performing and reporting empirical studies in software engineering. In order to address this problem, Andreas Jedlitschka and Dietmar Pfahl have produced reporting guidelines for controlled experiments in software engineering. They pointed out that their guidelines needed evaluation. We agree that guidelines need to be evaluated before they can be widely adopted. If guidelines are flawed, they will cause more problems that they solve.Aim. The aim of this paper is to present the method we used to evaluate the guidelines and report the results of our evaluation exercise. We suggest our evaluation process may be of more general use if reporting guidelines for other types of empirical study are developed.Method. We used perspective-based inspections to perform a theoretical evaluation of the guidelines. A separate inspection was performed for each perspective. The perspectives used were: Researcher, Practitioner/Consultant, Meta-analyst, Replicator, Reviewer and Author. Apart from the Author perspective, the inspections were based on a set of questions derived by brainstorming. The inspection using the Author perspective reviewed each section of the guidelines sequentially. Results. The question-based perspective inspections detected 42 issues where the guidelines would benefit from amendment or clarification and 8 defects.Conclusions. Reporting guidelines need to specify what information goes into what section and avoid excessive duplication. Software engineering researchers need to be cautious about adopting reporting guidelines that differ from those used by other disciplines. The current guidelines need to be revised and the revised guidelines need to be subjected to further theoretical and empirical validation. Perspective-based inspection is a useful validation method but the practitioner/consultant perspective presents difficulties.

Deriving requirements from process models via the problem frames approach

Jacksons problem frames is an approach to describing a recurring software problem. It is presumed that some knowledge of the application domain and context has been gathered so that an appropriate problem frame can be determined. However, the identification of aspects of the problem, and its appropriate framing is recognised as a difficult task. One way to describe a software problem context is through process modelling. Once contextual information has been elicited, and explicitly described, an understanding of what problems need to be solved should emerge. However, this use of process models to inform requirements is often rather ad hoc; the traceability from business process to software requirement is not always as straightforward as it ought to be. Hence, this paper proposes an approach for deriving and contextualising software requirements through use of the problem frames approach from business process models. We apply the approach on a live industrial e-business project in which we assess the relevance and usefulness of problem frames as a means of describing the requirements context. We found that the software problem did not always match easily with Jacksons five existing frames. Where no frame was identified, however, we found that Jacksons problem diagrams did couch the requirements in their right context, and thus application of the problem frames approach was useful. This implies a need for further work in adapting a problem frames approach to the context of e-business systems.

Assessing the quality of use case descriptions

Use cases have, for some years, been a popular approach to specification, as part of the Unified Modelling Language (UML). However, a number of authors have pointed to weaknesses with the approach, particularly in terms of the support offered to the writer of the use case description. This paper describes a Use Case Description Quality Checklist that acts as a check on the quality of the written description. The checklist is derived from theories of text comprehension, taken from the Discourse Processing community. The checklist approach has a number of benefits. First, the approach can be used to derive, or examine further, use case guidelines. That is, by considering whether such guidelines are likely to result in desirable qualities within the resulting description, one is able to make an informed judgement about the utility of those guidelines. Second, one can test for the desirable quality features in existing descriptions, thus enabling empirical validation. Third, as a minimum, the quality features can themselves be used as a checklist for the examination, and revision, of use case descriptions. To demonstrate applicability, the paper reports upon the use, and success, of the approach on an industrial case study.