Research Papers

This is a list of Research Papers and similar articles freely available on the internet that may be of interest to business analysts. I have not read all of them, but at a minimum I thought they looked interesting enough to link to for future reference by myself or others.
TitleYear PublishedDescriptionCategoryDate Added
(YYYY-MM-DD)
A Comparative Analysis of Business Analysis (BA) and Business Process Management (BPM) Capabilities2011By Paul Mathiesen, Wasana Bandara, Houra Delavari, Paul Harmon, and Kevin Brennan

Abstract:
Many initiatives to improve Business processes are emerging. The essential roles and contributions of Business Analyst (BA) and Business Process Management (BPM) professionals to such initiatives have been recognized in literature and practice. The roles and responsibilities of a BA or BPM practitioner typically require different skill-sets; however these differences are often vague. This vagueness creates much confusion in practice and academia. While both the BA and BPM communities have made attempts to describe their domains through capability defining empirical research and developments of Bodies of Knowledge, there has not yet been any attempt to identify the commonality of skills required and points of uniqueness between the two professions. This study aims to address this gap and presents the findings of a detailed content mapping exercise (using NVivo as a qualitative data analysis tool) of the International Institution of Business Analysis (IIBA®) Guide to the Business Analysis Body of Knowledge (BABOK® Guide) against core BPM competency and capability frameworks.
Business Process Management2013-11-08
A Comparison Between Five
Models of Software Engineering
2010A paper by Nabil Mohammed

Ali Munassar and A. Govardhan that provides quick overviews of five software development models and their respective strengths and weaknesses. The five models are: Waterfall, Iterative Development, V-Shaped Model, Spiral Model, and Extreme Programming.
Software Development Process Models2013-11-08
A Conceptual Model and Process for Client-driven Agile Requirements Prioritization2010A paper by Zornitza Racheva, Maya Daneva, Andrea Herrmann, and Roel J. Wieringa

Abstract —
Continuous customer-centric requirements reprioritization is essential in successfully performing agile software development. Yet, in the agile RE literature, very little is known about how agile reprioritization happens in practice. Generic conceptual models about this process are missing, which in turn, makes it difficult for both practitioners and researchers to reason about requirements decision-making at inter-iteration time. This paper presents a Grounded Theory study on agile requirements prioritization methods to yield a conceptual model for understanding the inter-iteration prioritization process in terms of inputs and outcomes. The latter is derived by using qualitative empirical data, published earlier by other authors. Such a conceptual model makes explicit the concepts that are used tacitly in different agile requirements prioritization methods and can be used for structuring future empirical investigations about this topic.
Agile, Requirements
Prioritization
2013-11-08
A Discipline of Description1998By M. A. Jackson

ABSTRACT:
Software engineers, and especially requirements engineers, are vitally concerned with describing the world. Description merits recognition as a discipline in its own right. In this talk some aspects of this putative discipline are briefly explored.
Requirements Definition and Specification2013-11-08
A Framework for Integrating Business Processes and Business Requirements2004A paper by Raman Kazhamiakin, Marco Pistore, and Marco Roveri

Abstract - Service-oriented architectures and Web service infrastructure provide the ideal framework for interconnecting organizations and for defining distributed business applications. The possibility to exploit business process definition and execution languages is particularly relevant for capturing the process-oriented nature of these applications. However, business processes by themselves are not enough to manage the changes and to allow an organization to continuously adapt its business model to the typical needs of distributed applications. To achieve this flexibility, it is of uttermost importance to link the business processes to the organizational strategy and to the business goals that motivate the need of these processes.

In this paper we propose a framework for representing strategies and goals of an organization in terms of business requirements. The framework allows to describe how an organizational strategy is operationalized into activities and implemented by business processes. It also allows to represent the assumptions on the interactions between the different business applications.
Finally, this framework allows for the usage of formal analysis techniques, in particular Model Checking, to pinpoint problems and to identify possible solutions in this domain.
Business Process Modelling2013-11-08
A Framework for Matching Requirements Engineering Techniques to Project Characteristics and Situation Changes2005A paper by Toshihiko Tsumaki and Tetsuo Tamai

Abstract - One of the most difficult jobs for requirements engineers is to select an appropriate RE method for a project at hand. Good engineers make good choice and have skills in applying the selected technique appropriately. Poor engineers usually have a narrow choice range limited by their training and biased by their experience. Once a requirements engineering technique that does not fit the current project is selected, the project is doomed to fail. In this paper, we propose a framework to characterize typical requirements engineering techniques and use it as a base for selecting appropriate techniques at the time of starting a project as well as at the time of recognizing a change in the project nature or encountering an obstacle in defining a suitable set of requirements.
Requirements Elicitation2013-11-08
A Framework for Project Management under Uncertainty2002De Meyer, Arnoud, Christoph H. Loch, and Michael T. Pich.

"A framework for project management under uncertainty." "Sloan Management Review", 43.2 (2002): 60-67.
Project Management2013-11-08
A Framework for the Requirements Engineering Process Development2005ABSTRACT:
The objectives of this research were, therefore, to investigate a theoretical ly sound and practically feasible framework which can provide constructive and productive solutions to the problems identified by combining the theories and technologies of advanced software engineering, requirements engineering, knowledge engineering, and decision support. The outcome of this is the A Framework for Requirements Engineering pRocess dEvelopment (FRERE), which consists of a requirements engineering knowledge base, methodologies for RE process development and RE techniques selection, RE process assessment models, and a prototype of the FRERE tool. The framework provides constructive methodologies, with the help of the requirements engineering knowledge base and process assessment models, to develop the most suitable RE process model and suitable RE techniques for the given software project. The FRERE tool is a knowledge-based decision support system which can advise the requirements engineers during the development of RE process. The case study conducted during the research has shown the feasibility of the framework.
Requirements Engineering2013-11-08
A FULL LIFE-CYCLE METHODOLOGY FOR STRUCTURED USE-CENTERED QUANTITATIVE USABILITY REQUIREMENTS SPECIFICATION AND USABILITY EVALUATION OF WEBSITES2009A dissertation by Guoqiang Hu (Auburn University)

Abstract: World Wide Web has gained its dominant status in the cyber information and services delivery world in recent years. But how to specify website usability requirements and how to evaluate and improve website usability according to its usability requirements specification are still big issues to all the stakeholders. To help solve this problem, we propose a website usability requirements specification and usability evaluation methodology that features a structured use-centered quantitative full life-cycle method.
Requirements Definition and Specification2013-11-08
A Literature Review and Classification of Selected Software Engineering Researches2012A paper by Ahmed Saleem Abbas, W. Jeberson, V.V. Klinsega from SHIATS, University, Department of Computer Science & Information Technology, IndiaRequirements Engineering2013-11-08
A Method for Navigating Interview-driven Software Requirements Elicitation Work: Effectiveness Evaluation of the Method from the Viewpoint of Efficiency2011A paper by Tatatoshi Yamanaka and Seiichi Komiya

Abstract - — A software development task is performed in accordance with requirements specification. Therefore, requirements elicitation work in order to prepare requirements specification is a very important task. However, it is very difficult to elicit user requirements for software development without omissions or errors, mainly because customers are often ignorant for software development technologies, and novice SEs do not have enough knowledge of the business contents for the software development. In order to solve this problem, the authors recognize requirements elicitation work as interview techniques, and are proposing a method to navigate interview-driven software requirements elicitation work conducted by SEs to customers so that SEs are able to elicit user requirements without omissions or errors. Then, the effectiveness of the proposed method was proven by conducting the experiment to compare completeness and accuracy of the elicited requirements. This paper discusses effectiveness of the proposed method from the viewpoint of efficiency of requirements elicitation work by conducting the comparative experiment in regards to the cases that the method proposed in the Reference was used and not used.
Requirements Elicitation2013-11-08
A Method for Service-Oriented Personalized Requirements Analysis2011By Huafeng Chen, Keqing He

ABSTRACT: The development of Web service has changed the process of software production, and requirements engineering becomes the key issue of service-oriented software engineering. Meantime, it reduces the degree of difficulty of software production, which facilitates end-users to customize software according to their personalized requirements. The paper proposes a method for service-oriented personalized requirements analysis, which is based on domain goal model and process model. The method can inform users of potential errors in requirements by detecting the correctness of requirements, which is driven by users’ personalized operations on goal models, and customize personalized processes to satisfy users’ requirements by reusing domain processes. The personalized processes are the basis for Web service discovery and composition.
Requirements Analysis and
Capture
2013-11-08
A New Maturity Model for Requirements Engineering Process: An Overview2012By Badariah Solemon, Shamsul Sahibuddin, and Abdul Azim Abdul Ghani

ABSTRACT: It is widely acknowledged that Requirements Engineering (RE) has an important implication for the overall success of software or system development projects. As more and more organizations consider RE as the principal problem areas in the projects, improving RE process therefore appears critical for future business success. Moreover, nowadays there are evidences that support improving RE process maturity can contributes to improved business performance. There exist generic Software Process Improvement (SPI) standards, specialised RE process improvement models as well as guidance and advices on RE. However, they suffer from various issues that limit their adoption by organizations that are interested to assess and improve their RE process capability. Therefore, the research presented in this paper proposes a new RE process improvement model. The model is built by adapting and expanding the structure of the continuous representation of the formal maturity framework Capability Maturity Model Integration for Development (CMMI-DEV) developed by the Software Engineering Institute (SEI) through three rounds of development and validation stages, which involved RE and CMMI expert panel in the software industry. This paper aims to provide an overview on what, why and how we build the maturity model for RE. The intention is to provide a foundation for future development in the area of RE process improvement.
Requirements Engineering2013-11-08
A New Methodology for Process Modeling of Workflows2012By Sabah Al-Fedaghi, Rashid Alloughani, Mohammed Al Sanousi

ABSTRACT: Workflow-based systems are typically said to lead to better use of staff and better management and productivity. The first phase in building a workflow-based system is capturing the real-world process in a conceptual representation suitable for the following phases of formalization and implementation. The specification may be in text or diagram form or written in a formal language. This paper proposes a flow-based diagrammatic methodology as a tool for workflow specification. The expressiveness of the method is appraised though its ability to capture a workflow-based application. Here we show that the proposed conceptual diagrams are able to express situations arising in practice as an alternative to tools currently used in workflow systems. This is demonstrated by using the proposed methodology to partial build demo systems for two government agencies.
Business Process Modelling2013-11-08
A project lifecycle perspective on stakeholder influence strategies in global projects2010By Kirsi Aaltonen and Jaakko Kujala

Summary: Global projects affect and are affected by multiple stakeholders with differing interests and demands. Recently, there has been increased pressure for global projects to be more environmentally and socially responsible. A project creates a dynamic context for stakeholder management and stakeholder behavior because the project moves through different phases during its lifecycle. By adopting a lifecycle perspective on secondary stakeholders’ behavior, we develop a set of propositions that increase our understanding of the potential of secondary stakeholders to influence the project management’s decision making during the different phases of the project lifecycle. Ultimately, a better understanding of secondary stakeholders’ influence behavior during the project lifecycle enables the use of more effective project stakeholder management approaches.
Stakeholder Management2013-11-08
A Proposal of a Process Model for Requirements Elicitation in Information Mining Projects2012By D. Mansilla, M. Pollo-Cattaneo, P. Britos, and R. García-Martínez

Abstract:

A problem addressed by an information mining project is transforming existing business information of an organization into useful knowledge for decision making. Thus, the traditional software development process for requirements elicitation cannot be used to acquire required information for information mining process. In this context, a process of requirements gathering for information mining projects is presented, emphasizing the following phases: conceptualization, business definition and information mining process identification.
Requirements Elicitation2013-11-08
A Rational Design Process: How and Why to Fake It1986By David L. Parnas and Paul C. ClementsSoftware Development Process Models2013-11-08
A Reference Model for Requirements & Specifications2000By Carl A. Gunter, Elsa L. Gunter, Michael Jackson and Pamela Zave

ABSTRACT: The authors define a reference model for applying formal methods to the development of user requirements and their reduction to a behavioral system specification. The approach focuses on the shared phenomena that define the interface between the system and environment.
Requirements Definition and Specification2013-11-08
A Review of Risk Management in Different Software Development Methodologies2012By Haneen Hijazi, Thair Khdour and Abdulsalam Alarabeyyat

ABSTRACT
Different software development methodologies exist. Choosing the methodology that best fits a software project depends on several factors. One important factor is how risky the project is. Another factor is the degree to which each methodology supports risk management. Indeed, the literature is rich in such studies that aim at comparing the currently available software development process models from different perspectives. In contrast, little effort has been spent in purpose of comparing the available process models in terms of its support to risk management. In this paper, we investigate the state of risk and risk management in the most popular software development process models (i.e. waterfall, v-model, incremental development, spiral, and agile development). This trend in such studies is expected to serve in several aspects. Technically, it helps project managers adopt the methodology that best suits their projects. From another side, it will make a way for further studies that aim at improving the software development process.
Software Development Process Models2013-11-08
A Review of the Impact of Requirements on Software Project Development Using a Control Theoretic Model2010By Anthony White

ABSTRACT: Software projects have a low success rate in terms of reliability, meeting due dates and working within assigned budgets with only 16% of projects being considered fully successful while Capers Jones has estimated that such projects only have a success rate of 65%. Many of these failures can be attributed to changes in requirements as the project progresses. This paper reviews several System Dynamics models from the literature and analyses the model of Andersson and Karlsson, showing that this model is uncontrollable and unobservable. This leads to a number of is-sues that need to be addressed in requirements acquisition.
Requirements Engineering2013-11-08
A Spiral Model of Software Development and Enhancement1988The paper in which Barry Boehm discussed in detail the Spiral Model that had been developed at TRW.Software Development Process Models2013-11-08
A Survey of Semantic Wikis for Requirements Engineering2009By Bart Hoenderboom and Peng Liang

ABSTRACT: Nowadays, semantic wikis are used in software development. In requirements engineering process, semantic wikis are used as lightweight and semantic/social-web based collaboration platforms. This paper first makes a survey on existing semantic wikis and their candidate features, which can be interesting in requirements engineering. Secondly, specific semantic wikis for requirements engineering are analyzed/compared based on the features identified in the first step. We conclude this paper with promising features which are provided by semantic wikis, and can be useful for requirements engineering.
Requirements Engineering2013-11-08
A Systematic Review of RE-specific Wikis for Distributed Requirements Engineering2011By Han Lai, Rong Peng, Dong Sun, Fei Shao, Yousong Liu, and YuZe Ni

Abstract: The wiki, which allows users to collaboratively create online contents in a flexible and simple manner, is among Web 2.0 technologies that have attracted a significant amount of interest. A lot of practitioners and researchers committed to extending wiki’s features to support requirements engineering activities.
This paper presents a survey of these methods and their corresponding tools. The aim is to provide references to support distributed requirement engineering research in industry and research communities, and identify the research directions. As a result, we identified the available wiki tools which are developed specifically for supporting requirements engineering (RE) activities (namely RE-specific wiki tools). Furthermore, we drew out the features of generic wikis and RE-specific wikis, whose aim were to support requirements engineering activities, and evaluated their adaptability. In addition, we analyzed the literatures of the RE-specific wikis’ application.
Based on the above findings, we discussed future research directions about how to promote RE-specific wikis to support collaborative requirements engineering from representation, agreement, specification and application dimensions.
Requirements Definition and Specification2013-11-08
A View of 20th and 21st Century Software Engineering2006by Barry BoehmRequirements Engineering2013-11-08
Agile Requirements Engineering Practices: An Empirical Study2008By Lan Cao and Balasubramaniam RameshAgile2013-11-08
An Approach to Automate Requirements Elicitation and Specification2003A paper by Neil W. Kassel and Brian A. Malloy

Abstract - This paper presents an approach to partially automate the requirements elicitation and specification processes. Because human interaction is of vital importance in requirements elicitation, it is almost impossible and impractical to fully automate the elicitation process. Our approach, combined with other established techniques, will increase the probability that the customer states real and nearly complete requirements.
We have developed a prototype tool to support our approach, which can be used independently or jointly by customers, users, software engineers, and domain experts. The ultimate goal of our approach is to demonstrate the potential for this automated tool to improve the requirements elicitation and specification processes.
Requirements Elicitation2013-11-08
An Exploration into the Process of Requirements Elicitation: A Grounded Approach2010NOTE: The link is a download link, not a view link, to the PDF.

By Suranjan Chakraborty, Saonee Sarker, and Suprateek Sarker

Abstract: Requirements elicitation (RE) is a critical phase in information systems development (ISD), having significant impacts on software quality and costs. While it has remained a key topic of interest for IS researchers, a review of the existing literature suggests that there are very few studies examining how the social process associated with RE unfolds. Prior literature acknowledges that this process involves collaboration between RE participants (e.g., user-reps and systems analysts) where knowledge regarding the system requirements is shared, absorbed, and co- constructed, such that shared mental models of the requirements can form. However, collaboration and knowledge sharing within the RE process has been characterized as tenuous in the literature, given that the groups of RE participants bring very different kinds of knowledge into this activity, and trust among the two parties cannot be guaranteed at any point. Despite acknowledgement of the tenuous nature of RE, we are not aware of research that has attempted to present an integrated view of how collaboration, knowledge transfer, and trust influence the RE process. Using data from two different organizations and adopting a grounded approach, this study presents an integrative process model of RE.
The study’s findings suggest that RE is composed of four different collaborative states. The study elaborates on the four states, and identifies important factors that tend to trigger transitions from one state to another.
Requirements Elicitation2013-11-08
Analysis of Requirement Engineering Processes, Tools/Techniques and Methodologies2013By Tousif ur Rehman, Muhammad Naeem Ahmed Khan, Naveed Riaz

Abstract:

Requirement engineering is an integral part of the software development lifecycle since the basis for developing successful software depends on comprehending its requirements in the first place. Requirement engineering involves a number of processes for gathering requirements in accordance with the needs and demands of users and stakeholders of the software product. In this paper, we have reviewed the prominent processes, tools and technologies used in the requirement gathering phase. The study is useful to perceive the current state of the affairs pertaining to the requirement engineering research and to understand the strengths and limitations of the existing requirement engineering techniques.
The study also summarizes the best practices and how to use a blend of the requirement engineering techniques as an effective methodology to successfully conduct the requirement engineering task. The study also highlights the importance of security requirements as though they are part of the nonfunctional requirement, yet are naturally considered fundamental to secure software development.
Requirements Engineering2013-11-08
Are you biting off more than you can chew? A case study on causes and effects of overscoping in large-scale software engineering2012A paper by Elizabeth Bjarnason, Krzysztof Wnuk, and Björn Regnell

This paper reports on findings from a case study aimed at understanding over-scoping in large-scale, market-driven software development projects, and how agile requirements engineering practices may affect this situation.
Project Management2013-11-08
Aspects of the Stakeholder Concept and their Implications for Information Systems Development1999By Athanasia Pouloudi

Abstract: This paper considers the use of the stakeholder concept in the information systems literature and compares it with current concerns in the strategic management literature, where the concept originates. In information systems, the notion of stakeholder has been used in many different ways, which, however, tend to reflect a primarily descriptive or instrumental perspective.The paper reviews these approaches and argues for a more thorough understanding of the stakeholder concept as information systems development has become more complex. In particular, the case for a more holistic view of stakeholders in information systems is made, reflecting the current multi-faceted concerns of information systems development. This holistic view, more evident in some recent approaches to the study of information systems stakeholders, is expected to contribute not only in addressing organizational and cultural issues of information systems projects, but also to encourage a more ethical approach to information systems development.
Stakeholder Management2013-11-08
Assessing the quality of use case descriptions2007A paper by Keith Thomas Phalp, Jonathan Vincent, and Karl Cox

Abstract - 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.
Requirements Definition and Specification2013-11-08
Assisting Novice Analysts in Developing Quality Conceptual Models with UML2006An article by By Narasimha Bolloju and Felix S.K. Leung

Knowing the kinds of modeling errors they are most likely to produce helps prepare novice analysts for developing quality conceptual models.
Requirements Definition and Specification2013-11-08
Benefits of DfX in Requirements Engineering2011By Jari Lehto, Janne Harkonen, Harri Haapasalo, Pekka Belt, Matti Mottonen, Pasi Kuvaja

ABSTRACT: Information and communications technology (ICT) companies have realised how acknowledging the needs of both internal and external customers is a necessity for successful requirements engineering. Design for X (DfX) is a potential management approach for coordinating & communicating requirements emerging from both internal functions and external supply chain partners. This article studies the potential of DfX for improved requirements engineering. Qualitative interviews are utilised to analyse how different organisations implement the concept, including designers’ actual work, methods & tools, and organisational aspects. The results include viewing DfX as means to achieve relevant competitive goals, and describing how different companies organise these activities, together with their benefits for modern ICT companies. This study highlights how the DfX concept can be used to manage, prioritise and to better communicate.
Requirements Engineering2013-11-08
Binary Priority List for Prioritizing Software Requirements2010A paper by Thomas Bebensee, Inge van de Weerd, and Sjaak Brinkkemper

Abstract - Product managers in software companies are confronted with a continuous stream of incoming requirements. Due to limited resources they have to make a selection of those that can be implemented. However, few prioritization techniques are suitable for prioritizing larger numbers of requirements. Binary Priority List (BPL) is a binary search based technique for prioritizing requirements.
Academics and practitioners have referred to it in previous works. However, it has not been described and researched in broad detail. This paper introduces BPL, examines how it can be used for prioritizing requirements and assesses its prioritization process quality by comparing it to another prioritization technique. A facilitating tool was developed and applied in two small Dutch product software companies. The paper demonstrates that the technique can be successfully used to prioritize requirements and is especially suitable for a medium amount of low-level requirements.
Requirements Prioritization2013-11-08
Business Value Is not only Dollars - Results from Case Study Research on Agile Software Projects2010A paper by Zornitza Racheva, Maya Daneva, Klaas Sikkel, and Luigi Buglione

Abstract - Business value is a key concept in agile software development. This paper presents results of a case study on how business value and its creation is perceived in the context of agile projects. Our overall conclusion is that the project participants almost never use an explicit and structured approach to guide the value creation throughout the project. Still, the application of agile methods in the studied cases leads to satisfied clients. An interesting result of the study represents the fact that the agile process of many projects differs significantly from what is described in the agile practitioners’ books as best practices. The key implication for research and practice is that we have an incentive to pursue the study of value creation in agile projects and to complement it by providing guidelines for better client’s involvement, as well as by developing structured methods that will enhance the value-creation in a project.
Agile2013-11-08
Communication Analysis: a Requirements Engineering Method for Information Systems2009By Sergio España, Arturo González, and Óscar Pastor

Abstract: Developing Information Systems (ISs) is a hard task for which Requirements Engineering (RE) offers a good starting point. IS's can be viewed as a support for organisational communication. Therefore, we argue in favour of communication-oriented RE methods. This paper presents Communication Analysis, a method for IS development and computerisation. The focus is put on requirements modelling techniques. Two novel techniques are described; namely, Communicative Event Diagram and Communication Structures. These are based on sound theory, they are accompanied by prescriptive guidelines (such as unity criteria) and they are illustrated by means of a practical example.
Requirements Definition and Specification2013-11-08
Data-centric Business Process Modelling: A Comparison of Methods2012A Master's Thesis by W.L.M. van de CrommertBusiness Process Modelling2013-11-08
Deriving Specifications from Requirements1995By Michael Jackson and Pamela Zave

ABSTRACT: A requirement is a desired relationship among phenomena of the environment of a system, to be brought about by the hardware/software machine that will be constructed and installed in the environment. A specification describes machine behaviour sufficient to achieve the requirement. A specification is a restricted kind of requirement: all the environment phenomena mentioned in a specification are shared with the machine; the phenomena constrained by the specification are controlled by the machine; and the specified constraints can be determined without reference to the future. Specifications are derived from requirements by reasoning about the environment, using properties that hold independently of the behaviour of the machine. These ideas, and some associated techniques of description, are illustrated by a simple example.
Requirements Definition and Specification2013-11-08
Discovering System Requirements1996This is a 1996 report by Sandia National Laboratory on Discovering System Requirements written by A. Terry Bahill, Bo Bentz, and Frank F. Dean.Requirements Elicitation2013-11-08
Do we
Know Enough about Requirements Prioritization in Agile Projects: Insights from a Case Study
2010A paper by Zornitza Racheva, Maya Daneva, Klaas Sikkel, Roel Wieringa and Andrea Herrmann

Abstract—: Requirements prioritization is an essential mechanism of agile software development approaches. It maximizes the value delivered to the clients and accommodates changing requirements. This paper presents results of an exploratory cross-case study on agile prioritization and business value delivery processes in eight software organizations. We found that some explicit and fundamental assumptions of agile requirement prioritization approaches, as described in the agile literature on best practices, do not hold in all agile project contexts in our study. These are (i) the driving role of the client in the value creation process, (ii) the prevailing position of business value as a main prioritization criterion, (iii) the role of the prioritization process for project goal achievement. This implies that these assumptions have to be reframed and that the approaches to requirements prioritization for value creation need to be extended.
Requirements Prioritization2013-11-08
Effective Communication in Requirements Elicitation: A Comparison of Methodologies2002By Jane Coughlan and Robert D. Macredie

ABSTRACT: The elicitation or communication of user requirements comprises an early and critical but highly error-prone stage in system development. Socially-oriented methodologies provide more support for user involvement in design than the rigidity of more traditional methods, facilitating the degree of user-designer communication and the ‘capture’ of requirements. A more emergent and collaborative view of requirements elicitation and communication is required to encompass the user, contextual and organisational factors. From this accompanying literature in communication issues in requirements elicitation, a four-dimensional framework is outlined and used to appraise comparatively four different methodologies seeking to promote a closer working relationship between users and designers. The facilitation of communication between users and designers is subject to discussion of the ways in which communicative activities can be ‘optimised’ for successful requirements gathering, by making recommendations based on the four dimensions to provide fruitful considerations for system designers.
Requirements Elicitation2013-11-08
Effective Requirements Development - A Comparison of Requirements Elicitation techniques2006A paper by Zheying Zhang

ABSTRACT: Requirements engineering process is a human endeavor. People who hold a stake in a project are involved in the requirements engineering process. They are from different backgrounds and with different organizational and individual goals, social positions, and personalities. They have different ways to understand and express the knowledge, and communicate with others. The requirements development processes, therefore, vary widely depending on the people involved. In order to acquire quality requirements from different people, a large number of methods exist. However, because of the inadequate understanding about methods and the variability of the situations in which requirements are developed, it is difficult for organizations to identify a set of appropriate methods to develop requirements in a structured and systematic way. The insufficient requirements engineering process forms one important factor that cause the failure of an IT project.
Requirements Elicitation2013-11-08
Effectiveness
of Elicitation Techniques in Distributed Requirements Engineering
2002By Wesley James Lloyd, Mary Beth Rosson and James D. Arthur

ABSTRACT: Software development teams are often geographically distributed from their customers and end users. This
creates significant communication and coordination challenges that impact the effectiveness of requirements engineering. Travel costs, and the local availability of quality technical staff increase the demand for effective
distributed software development teams.

This research reports an empirical study of how groupware can be used to aid distributed requirements engineering for a software development project. Six groups of seven to nine members were formed and divided into separate remote groups of customers and engineers. The engineers conducted a requirements analysis and produced a software requirements specification (SRS) document through distributed interaction with the remote customers.

We present results and conclusions from the research including: an analysis of factors that effected the quality
of the Software Requirements Specification document written at the conclusion of the requirements process and
the effectiveness of requirements elicitation techniques which were used in a distributed setting for requirements
gathering.
Requirements Elicitation2013-11-08
Elicitation Technique Selection: How Do Experts Do It?2003By Ann M. Hickey and Alan M. Davis

ABSTRACT: Requirements elicitation techniques are methods used by analysts to determine the needs of customers and users, so that systems can be built with a high probability of satisfying those needs. Analysts with extensive experience seem to be more successful than less experienced analysts in uncovering the user needs. Less experienced analysts often select a technique based on one of two reasons: (a) it is the only one they know, or (b) they think that a technique that worked well last time must surely be appropriate this time. This paper presents the results of in-depth interviews with some of the world's most experienced analysts. These results demonstrate how they select elicitation techniques based on a variety of situational assessments.
Requirements Elicitation2013-11-08
Eliciting security requirements with misuse cases2005A paper by Guttorm Sindre and Andreas L. Opdahl

Abstract - Use cases have become increasingly common during requirements engineering, but they offer limited support for eliciting security threats and requirements. At the same time, the importance of security is growing with the rise of phenomena such as e-commerce and nomadic and geographically distributed work. This paper presents a systematic approach to eliciting security requirements based on use cases, with emphasis on description and method guidelines. The approach extends traditional use cases to also cover misuse, and is potentially useful for several other types of extra-functional requirements beyond security.
Requirements Elicitation2013-11-08
Engineering and Software2010By Michael Jackson

ABSTRACT: Abstract Software development has long aspired to merit the status of a professional engineering discipline like those of the established engineering branches. This paper discusses this aspiration with particular reference to software-intensive or computer-based systems. Some opportunities are pointed out for learning important lessons from the established branches. These lessons stem above all from the highly specialised nature of traditional engineering practice. They centre on the crucial distinction between radical and normal design, the content of normal design practice, and the social and cultural infrastructures that make effective specialisation possible.
Requirements Engineering2013-11-08
Engineering and Software Engineering2010By Michael Jackson

ABSTRACT: Abstract. The phrase ‘software engineering’ has many meanings. One central meaning is the reliable development of dependable computer-based systems, especially those for critical applications. This is not a solved problem. Failures in software development have played a large part in many fatalities and in huge economic losses. While some of these failures may be attributable to programming errors in the narrowest sense—a program’s failure to satisfy a given formal specification—there is good reason to think that most of them have other roots. These roots are located in the problem of software engineering rather than in the problem of program correctness. The famous 1968 conference was motivated by the belief that software development should be based on “the types of theoretical foundations and practical disciplines that are traditional in the established branches of engineering.” Yet after forty years of currency the phrase ‘software engineering’ still denotes no more than a vague and largely unfulfilled aspiration. Two major causes of this disappointment are immediately clear. First, too many areas of software development are inadequately specialised, and consequently have not developed the repertoires of normal designs that are the indispensable basis of reliable engineering success. Second, the relationship between structural design and formal analytical techniques for software has rarely been one of fruitful synergy: too often it has defined a boundary between competing dogmas, at which mutual distrust and incomprehension deprive both sides of advantages that should be within their grasp. This paper discusses these causes and their effects. Whether the common practice of software development will eventually satisfy the broad aspiration of 1968 is hard to predict; but an understanding of past failure is surely a prerequisite of future success.

Requirements Engineering2013-11-08
Examining Expectations About User Involvement in Software Development and Factors That Influence High-Quality User Involvement2013A thesis by Amrita Shinde and Jim Buchan at the Auckland University of Technology.Requirements Elicitation2013-11-08
Exploring the Role of the Project Sponsor2001By Lynn Crawford and Christine Brett

Abstract:

Despite the general acceptance of a project sponsor role in the management of projects, the actual role and responsibilities of the project sponsor are often unclear and in fact differ considerably across organisations. As with the majority of project management roles, there is considerable variation in definition and often considerable confusion as to the sponsor’s role and how the sponsor may contribute to or effect the project’s outcome.

This paper explores the definition and role of the project sponsor, identifying where the role is most likely to be of use, and providing guidance, based on literature review, survey data and interviews, for definition of the role.
Project Management2013-11-08
Extending Agile Methods: Postmortem Reviews as Extended Feedback2003By Torgeir Dingsøyr and Geir Kjetil Hanssen

Abstract

Agile software development methods, such as Extreme Programming, focus on informal learning mechanisms like pair programming. Yet powerful methods, new knowledge that is gained in a project will not spread rapidly in an organisation if knowledge and experience is not externalised. We propose to combine a lightweight externalisation method: postmortem reviews with agile methods to strengthen the overall learning, and suggest how this can be done. We use practical experience from an Extreme Programming development project, and from conducting postmortem analysis in several companies in our discussion.
Agile2013-11-08
Extending Extreme Programming User Stories to Meet ISO 9001 Formality Requirements2011By Malik Qasaimeh and Alain Abran

Abstract: For software organizations needing ISO 9001 certification, including those that have adopted agile methodologies, it is important that their software life cycle processes be able to manage the requirements imposed by this certification standard. However, the user stories in the XP agile methodology do not provide auditors with enough evidence that certain steps and activities have been performed in compliance with ISO 9001. This paper proposes an extension to the user story, based on four sub processes related to the CMMI-DEV model: 1) identification of the source of the user story; 2) categorization of the non-functional requirements; 3) identification of the user story relationships; and 4) prioritization of the user stories. These sub processes are aligned with the XP release planning phase, and enhance the ability of user stories to accumulate the information that is mandatory for achieving ISO 9001 certification.
Agile2013-11-08
Four Dark Corners of Requirements Engineering1996By Michael Jackson and Pamela Zave

ABSTRACT: Research in requirements engineering has produced an extensive body of knowledge, but there are four areas in which the foundation of the discipline seems weak or obscure. This paper shines some light in the "four dark corners," exposing problems and proposing solutions. We show that all descriptions involved in requirements engineering should be descriptions of the environment. We show that certain control information is necessary to sound requirements engineering, and we explain the close association between domain knowledge and refinement of requirements. Together these conclusions explain the precise nature of requirements, specifications, and domain knowledge, as well as the precise nature of the relationships among them. They establish minimum standards for what information should be represented in a requirements language. They also make it possible to determine exactly what it means for requirements engineering to be successfully completed.
Requirements Definition and Specification2013-11-08
Goal-Oriented Requirements Engineering: A Guided Tour2001By Axel van Lamsweerde

ABSTRACT: Goals capture, at dizerent levels of abstraction, the various objectives the system under consideration should achieve. Goal-oriented requirements engineering is concerned with the use of goals for eliciting, elaborating, structuring, specifying, analyzing, negotiating, documenting, and modifying requirements. This area has received increasing attention over the past few years. The paper reviews various research efforts undertaken along this line of research. The arguments in favor of goal orientation are first briefly discussed. The paper then compares the main approaches to goal modeling, goal specification and goal-based reasoning in the many activities of the requirements engineering process. To make the discussion more concrete, a real case study is used to suggest what a goal-oriented requirements engineering method may look like. Experience with such approaches and tool support are briefly discussed as well.
Requirements Engineering2013-11-08
Guide to the User Requirements Definition Phase - Revision 11995By the European Space Agency Board for Software Standardization and Control

This document is one of a series of guides to software engineering produced by the Board for Software Standardisation and Control (BSSC), of the European Space Agency. The guides contain advisory material for software developers conforming to ESA's Software Engineering Standards, ESA PSS-05-0. They have been compiled from discussions with software engineers, research of the software engineering literature, and experience gained from the application of the Software Engineering Standards in projects.
Requirements Definition and Specification2013-11-08
Hidden Skills that Support Phased and Agile Requirements Engineering2003A paper by Ben Kovitz

Abstract - Phased development does requirements engineering in one or a small number of extended phases occurring early in a project. Agile development also does requirements engineering, but in thousands of small conversations spread throughout the development lifecycle. Each depends on subtly different skills and expertise to perform its practices — agile development depending heavily on ability to change working code, phased development depending heavily on foresight. This paper surveys the special skills that each style of requirements engineering depends on in order to promise and deliver.
Requirements Engineering2013-11-08
How Do Real Options Concepts Fit in Agile Requirements Engineering?2010A paper by Zornitza Racheva and Maya Daneva

Abstract — Agile requirements engineering is driven by creating business value for the client and heavily involves the client in decision-making under uncertainty. Real option thinking seems to be suitable in supporting the client’s decision making process at inter-iteration time. This paper investigates the fit between real option thinking and agile requirements engineering. We first look into previously published experiences in the agile software engineering literature to identify (i) ‘experience clusters’ suggesting the ways in which real option concepts fit into the agile requirements process and (ii) ‘experience gaps’ and under-researched agile requirements decision-making topics which require further empirical studies.
Furthermore, we conducted a cross-case study in eight agile development organizations and interviewed 11 practitioners about their decision-making process. The results suggest that options are almost always identified, reasoned about and acted upon. They are not expressed in quantitative terms, however, they are instead explicitly or implicitly taken into account during the decision-making process at inter-iteration time.
Agile2013-11-08
How Much
Language is Enough? Theoretical and Practical Use of the Business Process
Management Notation
2008By Michael Zur Muehlen and Jan Recker

ABSTRACT: The Business Process Modeling Notation (BPMN) is an increasingly important industry standard for the graphical representation of business processes. BPMN offers a wide range of modeling constructs, significantly more than other popular languages. However, not all of these constructs are equally important in practice as business analysts frequently use arbitrary subsets of BPMN. In this paper we investigate what these subsets are, and how they differ between academic, consulting, and general use of the language. We analyzed 120 BPMN diagrams using mathematical and statistical techniques. Our findings indicate that BPMN is used in groups of several, well-defined construct clusters, but less than 20% of its vocabulary is regularly used and some constructs did not occur in any of the models we analyzed. While the average model contains just 9 different BPMN constructs, models of this complexity have typically just 4-5 constructs in common, which means that only a small agreed subset of BPMN has emerged. Our findings have implications for the entire ecosystems of analysts and modelers in that they provide guidance on how to reduce language complexity, which should increase the ease and speed of process modeling.
Business Process Modelling2013-11-08
Managing the Development of Large Software Systems1970This paper by Winston W. Royce is the most frequency cited source of "The Waterfall Model". However, if you read the paper, you will see it does not describe "The Waterfall Model" as it is commonly understood at all.Software Development Process Models2013-11-08
Modeling Software Architectures in the Unified Modeling Language2002By Nenad Medvidovic, David S. Rosenblum, Jason E. Robbins and David F. Redmiles

ABSTRACT: The Unified Modeling Language (UML) is a family of design notations that is rapidly becoming a de facto standard software design language. UML provides a variety of useful capabilities to the software designer, including multiple, inter-related design views, a semiformal semantics expressed as a UML meta model, and an associated language for expressing formal logic constraints on design elements. However, UML currently lacks support for capturing and exploiting certain architectural concerns whose importance has been demonstrated through the research and practice of software architectures. In particular, UML lacks direct support for modeling and exploiting architectural styles, explicit software connectors, and local and global architectural constraints. This paper presents two strategies for supporting such architectural concerns within UML. One strategy involves using UML “as is,” while the other incorporates useful features of existing architecture description languages (ADLs) as UML extensions. We discuss the applicability, strengths, and weaknesses of the two strategies. The strategies are applied on three ADLs that, as a whole, represent a broad cross-section of present-day ADL capabilities.
Software Modelling2013-11-08
Next Generation Requirements Engineering2012By John Favaro, Hans-Peter de Koning, Rudolf Schreiner and Xavier Olive

ABSTRACT: Establishing and managing a ―good‖ set of requirements is one of the critical success factors for any space system project, and for the development of any complex product in general. The NextGenRE project sponsored by the European Space Agency has developed an innovative approach featuring the use of semantic wiki technology to enable users to specify structured, semantically-rich requirements associated with canonical system designs in OMG SysML. Reuse of requirements through templates is supported, as well as semantic reasoning to check properties such as consistency and coherence among requirements. The approach is entirely model-based, allowing tight integration of the requirements engineering and design processes and opening the way to the application of model checking and simulation techniques. The new approach is being validated alongside an existing space project.
Requirements Engineering2013-11-08
On Non-Functional Requirements in Software Engineering2009By Lawrence Chung and Julio Cesar Sampaio do Prado Leite

Abstract: Essentially a software system’s utility is determined by both its functionality and its non-functional characteristics, such as usability, flexibility, performance, interoperability and security. Nonetheless, there has been a lop-sided emphasis in the functionality of the software, even though the functionality is not useful or usable without the necessary non-functional characteristics.
In this chapter, we review the state of the art on the treatment of non-functional requirements (hereafter, NFRs), while providing some prospects for future directions.
Requirements Definition and Specification2013-11-08
On the Similarity between Requirements and Architecture2008By Remco C. de Boer and Hans van Vliet

Abstract

Many would agree that there is a relationship between requirements engineering and software architecture. However, there have always been different opinions about the exact nature of this relationship. Nevertheless, all arguments have been based on one overarching notion: that of requirements as problem description and software architecture as the structure of a software system that solves that problem, with components and connectors as the main elements.

Recent developments in the software architecture field show a change in how software architecture is perceived. There is a shift from viewing architecture as only structure to a broader view of ‘architectural knowledge’ that emphasizes the treatment of architectural design decisions as first-class entities. From this emerging perspective we argue that there is no fundamental distinction between architectural decisions and architecturally significant requirements. This new view on the intrinsic relation between architecture and requirements allows us to identify areas in which closer cooperation between the architecture and requirements engineering communities would bring advantages for both.

Key words: Software architecture, requirements, architectural knowledge
Requirements Engineering2013-11-08
PAORE: Package Oriented Requirements Elicitation2003By Junzo Kato, Motoshi Saeki, Atsushi Ohnishi, Morio Nagata, Haruhiko Kaiya, Seiichi Komiya, Shuichiro Yamamoto, Hisayuki Horai and Kenji Watahiki


ABSTRACT: We propose a new requirements elicitation method in such a domain of ERP, CRM, and SCM by using specifications of several existing package software. We have analyzed the requirements elicitation processes of experienced analysts in a specific domain, and found that they clarify requirements by referring the specifications of existing packages that seem to be satisfied with customer’s needs. This process can be formulated into two sub-processes: 1) package selection, where an analyst compares the customer’s needs with functions/non-functions of packages and selects the suitable candidates of packages; and 2) requirements evolution, where he examines the selected packages with his customer and an approved part of specifications of packages are added into their requirements. The proposed method, called PAORE (PAckage Oriented Requirements Elicitation method)is designed based on the analysis. We applied this method to a simple but realistic example of Web-based Sales Supporting System and assessed it.
Requirements Elicitation2013-11-08
Partnering for Project Success: Project Manager and Business Analyst Collaboration2011NOTE: This isn't a research paper and thus breaks the normal rules of what is in this section. But this white paper was written by some eminent authors and is of a non-commercial nature, so I thought it fit well within this section.

By Barbara Carkenord, CBAP, Chris Cartwright, PMP, Robin Grace, CBAP, Larry Goldsmith, PMP, Elizabeth Larson, PMP, CBAP, Jen Skrabak, PMP, and Cornelis (Kees) Vonk, PMP

Introduction: In recent years, organizations have come to understand the critical importance of projects to drive business results, which has led to the widespread acceptance of the profession of project management and the emergence in its own right of the profession of business analysis. These developments have prompted project sponsors, team leads, and team members to consider how these two professions fit into the project framework. Unclear roles and responsibilities, confusion over job titles, and differing organizational expectations for project management and business analysis roles can create confusion and conflict that contributes to less successful project outcomes. For project managers, there may be a perception that business analysts are collecting requirements without effective coordination. There is a fear of being left “out of the loop” and that the business analyst may create unrealistic expectations among project stakeholders regarding project commitments. For business analysts, there may be a perception that project managers do not understand the breadth and complexity of defining, analyzing, and managing requirements and are unwilling to fully investigate and address stakeholder needs.
As companies search for the optimal project leadership resource mix that provides maximum business value for funds invested, many are looking for guidance on the roles of the project manager (PM) and business analyst (BA) to provide effective and efficient project delivery.
Project Management2013-11-08
Postmortem: Never Leave a Project Without It2002By Andreas Birk, Torgeir Dingsøyr, and Tor Stålhane

In every software project, the team members gain new knowledge and experience that can benefit future projects and each member’s own professional development. Unfortunately, much of this knowledge remains unnoticed and is never shared between individuals or teams. Our experience with project postmortem analysis proves that it is an excellent method for knowledge management, which captures experience and improvement suggestions from completed projects and works even in small- and medium- size companies that cannot afford extensive KM investments.
Project Management2013-11-08
Problem Identification and Decomposition within the Requirements Generation Process2002By Ahmed S. Sidky, Rajat R. Sud, Shishir Bhatia and James D. Arthur

Abstract:

Only recently has the real importance of the requirements generation process and its requisite activities been recognized. That importance is underscored by the evolving partitions and refinements of the once all-encompassing (and somewhat mis-named) Requirements Analysis phase of the software development lifecycle. Continuing along that evolutionary line, we propose an additional refinement to the requirements generation model that focuses on problem identification and its decomposition into an associated set of user needs that drive the requirements generation process. Problem identification stresses the importance of recognizing and identifying the difference between a perceived state of the system and the desired one. We mention pre- and post-conditions that help identify and bound the “problem,” and then present some methods and techniques that assist in refining that boundary and also in recognizing essential characteristics of the problem. We continue by presenting a process by which the identified problem and its characteristics are decomposed and translated into a set of user needs that provide the basis for the solution description, i.e, the set of requirements. Finally, to place problem identification and decomposition in perspective, we present them within the framework of the Requirements Generation Model.
Requirements Analysis and
Capture
2013-11-08
Production of Large Computer Programs1954A paper by Herbert D. Benington.

Often said to be the first description ever of a Waterfall-like software development process.
Software Development Process Models2013-11-08
Requirement Ambiguity Not as Important as Expected -- Results of an Empirical Evaluation2013By Erik Jan Philippo, Werner Heijstek, Bas Kruiswijk, Michel R.V. Chaudron, and Daniel M. Berry

Abstract:

[Context and motivation] Requirement ambiguity is seen as an important factor for project success. However, empirical data about this relation are limited.
[Question/problem] We analyze how ambiguous requirements relate to the success of software projects. [Principal ideas/results] Three methods are used to study the relation between requirement ambiguity and project success. First, data about requirements and project outcome were collected for 40 industrial projects. We find that, based on a correlation analysis, that the level of ambiguity in the requirements for a project does not correlate with the project’s success. Second, using a root-cause analysis, we observe that ambiguity does not cause more defects during the test phase. Third, expert interviews were conducted to validate these results. This resulted in a framework that outlines factors influencing requirement-ambiguity risk.
[Contribution] Empirical data are presented about the relationship between requirement ambiguity and project success. A framework is created to describe nine factors that increase or mitigate requirement-ambiguity risk.
Requirements Definition and Specification2013-11-08
Requirements Analysis: Evaluating KAOS Models2010By Faisal Almisned, Jeroen Keppens

ABSTRACT: Wigmore’s charts and Bayesian networks are used to represent graphically the construction of arguments and to evaluate them. KAOS is a goal oriented requirements analysis method that enables the analysts to capture requirements through the realization of the business goals. However, KAOS does not have inbuilt mechanism for evaluating these goals and the inferring process. This paper proposes a method for evaluating KAOS models through the extension of Wigmore’s model with features of Bayesian networks.
Requirements Analysis and
Capture
2013-11-08
Requirements Are Slipping Through the Gaps - A Case Study on Causes & Effects of Communication Gaps in Large-Scale Software Development2011A paper by Elizabeth Bjarnason, Krzysztof Wnuk and Björn Regnell presented at the 2011 IEEE 19th International Requirements Engineering ConferenceRequirements Analysis and
Capture
2013-11-08
Requirements Engineering and Agile Software Development2003A paper by Frauke Paetsch, Dr. Armin Eberlein, and Dr. Frank Maurer

Abstract - This article compares traditional requirements engineering approaches and agile software development. Our paper analyzes commonalities and differences of both approaches and determines possible ways how agile software development can benefit from requirements engineering methods.
Requirements Engineering2013-11-08
Requirements Engineering-Based Conceptual Modelling2002By E Insfrán, O Pastor, R WieringaRequirements Engineering2013-11-08
Requirements engineering: making the connection between the software developer and customer2000By H. Saiediana, R. Daleb

Abstract

Requirements engineering are one of the most crucial steps in software development process. Without a well-written requirements specification, developer’s do not know what to build, user’s do not know what to expect, and there is no way to validate that the created system actually meets the original needs of the user. Much of the emphasis in the recent attention for a software engineering discipline has centered on the formalization of software specifications and their flowdown to system design and verification. Undoubtedly, the incorporation of such sound, complete, and unambiguous traceability is vital to the success of any project. However, it has been our experience through years of work (on both sides) within the government and private sector military industrial establishment that many projects fail even before they reach the formal specification stage. That is because too often the developer does not truly understand or address the real requirements of the user and his environment.

The purpose of this research and report is to investigate the key players and their roles along with the existing methods and obstacles in Requirements Elicitation. The article will concentrate on emphasizing key activities and methods for gathering this information, as well as offering new approaches and ideas for improving the transfer and record of this information. Our hope is that this article will become an informal policy reminder/guideline for engineers and project managers alike. The success of our products and systems are largely determined by our attention to the human dimensions of the requirements process. We hope this article will bring attention to this oft-neglected element in software development and encourage discussion about how to effectively address the issue.
Requirements Engineering2013-11-08
Requirements Engineering: The State of the Practice2003By Colin J. Neill and Phillip A. Laplante

ABSTRACT: Little contemporary data exists to document actual practices of software professionals for software requirements elicitation, requirements specification document development, and specification validation. This exploratory survey and its quantitative results offer opportunities for further interpretation and comparison.
Requirements Engineering2013-11-08
Requirements in the 21st Century: Current Practice & Emerging Trends2009By Sean Hansen, Nicholas Berente, and Kalle Lyytinen

Abstract: Requirements have remained one of the grand challenges in the design of software intensive systems. In this paper we review the main strands of requirements research over the past two decades and identify persistent and new challenges. Based on a field study that involved interviews of over 30 leading IT professionals involved in large and complex software design and implementation initiatives we review the current state-of-the-art in design requirements management. We observe significant progress in the deployment of modeling methods, tools, risk-driven design, and user involvement. We note nine emerging themes and challenges in the requirement management arena: 1) business process focus, 2) systems transparency, 3) integration focus, 4) distributed requirements, 5) layered requirements, 6) criticality of information architectures, 7) increased deployment of COTS and software components, 8) design fluidity and 9) interdependent complexity. Several research challenges and new avenues for research are noted in the discovery, specification, and validation of requirements in light of these requirements features.
Requirements Engineering2013-11-08
Review
of Requirements Management Issues in Software Development
2013By Muhammad Naeem Ahmed Khan, Muhammad Khalid, Sami ul Haq

Abstract:

A requirement is a capability to which a product or service should conform to. A meticulous consideration to requirements engineering acts as a backbone of software projects. Ambiguous and unrealistic requirements are major source of failure in the software-intensive systems. Requirements engineering processes are complex as most of the requirements engineering documentation is written in natural languages which are less formal and often distract the designers and developers. Requirements management is a continuous process throughout the project lifecycle and relates to documenting, analyzing, tracing and prioritizing requirements and then finally controlling changes.
The main issues related to requirements management are usually social, political and cultural. Software requirement engineers who gather the requirements generally consider that such issues are beyond the scope of their profession as they deem them within the project management ambit. In this study, we highlight the management issues that arise in the requirements engineering process and explore the possibilities to tackle them amicably. The study is supplemented with a critical review of the existing methodologies for resolving and managing software requirements.
Requirements Management2013-11-08
RiskREP: Risk-Based Security Requirements Elicitation and Prioritization2011By Andrea Herrmann, Ayse Morali, Sandro Etalle and Roel Wieringa

Abstract: 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. In this paper, we present a Risk-Based Requirements Prioritization method (RiskREP) that extends misuse case-based methods with IT architecture based risk assessment and countermeasure definition and prioritization. Countermeasure prioritization is linked to business goals to achieve and based on cost of countermeasures and their effectiveness in reducing risks. RiskREP offers the potential to elicit complete security countermeasures, but also supports the deliberate decision and documentation of why the security analysis is focused on certain aspects. We illustrate RiskREP by an application to an action case.
Requirements Elicitation2013-11-08
Scenario-based Requirements Engineering2003A mini-tutorial from Alistair Sutcliffe presented at the RE 2003 conference.

Abstract - This mini tutorial explains the concepts and process of scenario based requirements engineering. Definitions of scenarios are reviewed, with their informal and more formal representations, and roles in the requirements process. The relationships between scenarios, specifications and prototypes is explored, and set in the perspective of human reasoning about requirements. Methods for scenario based RE are described and one method, SCRAM, is covered in more depth. The tutorial concludes with a look forward to the future of scenario based RE and research directions.
Requirements Analysis and
Capture
2013-11-08
Self-Adaptability of Agile Software Processes: A Case Study on Post-Iteration Workshops2004By Outi Salo, Kari Kolehmainen, Pekka Kyllönen, Jani Löthman, Sanna Salmijärvi, and Pekka Abrahamsson

Abstract

None of the agile methods are claimed to fit all development situations. A team should attempt to adapt the methods and practices to fit their specific needs. For that reason agile principles call for self-reflection on a regular basis in order to identify where and how to make improvements. While some systematic approaches on how to execute this self-reflection process effectively have already been proposed, little empirical evidence currently exists. This paper reports empirical results based on a study where a project team conducted a self-reflection process called “post-iteration workshop” in order to improve and optimize the adopted practices in an XP project. Both qualitative and quantitative data were collected from four 1-2 hour workshops. The results show that with less than 4% effort it is possible to hold post-iteration workshops that significantly help to improve and optimize practices and enhance the learning and satisfaction of the project team.
Agile2013-11-08
Semantic Wiki aided Business Process Specification2009By Toufeeq Hussain, Rajesh Balakrishnan, and Amar Viswanathan

Abstract: This paper formulates a collaborative system for modeling business application. The system uses a Semantic Wiki to enable collaboration between the various stakeholders involved in the design of the system and translates the captured intelligence into business models which are used for designing a business system.
Business Process Modelling2013-11-08
Short Cycle Time Systems Development2004A paper by Richard Baskerville and Jan Pries-Heje on the factors that led to the development short-cycle systems development.Agile2013-11-08
Software Development Lifecycle Models2010By Nayan B. Ruparelia

ABSTRACT: This history column article provides a tour of the main software development life cycle (SDLC) models. (A lifecycle covers all the stages of software from its inception with requirements definition through to fielding and maintenance.) System development lifecycle models have drawn heavily on software and so the two terms can be used interchangeably in terms of SDLC, especially since software development in this respect encompasses software systems development. Because the merits of selecting and using an SDLC vary according to the environment in which software is developed as well as its application, I discuss three broad categories for consideration when analyzing the relative merits of SDLC models. I consider the waterfall model before the other models because it has had a profound effect on software development, and has additionally influenced many SDLC models prevalent today. Thereafter, I consider some of the mainstream models and finish with a discussion of what the future could hold for SDLC models.
Software Development
Process Models
2013-11-08
Some Findings Concerning Requirements in Agile Methodologies2009A paper by Pilar Rodríguez, Agustín Yagüe, Pedro P. Alarcón, and Juan Garbajosa

Abstract - Agile methods have appeared as an attractive alternative to conventional methodologies. These methods try to reduce the time to market and, indirectly, the cost of the product through flexible development and deep customer involvement. The processes related to requirements have been extensively studied in literature, in most cases in the frame of conventional methods. However, conclusions of conventional methodologies could not be necessarily valid for Agile; in some issues, conventional and Agile processes are radically different. As recent surveys report, inadequate project requirements is one of the most conflictive issues in agile approaches and better understanding about this is needed. This paper describes some findings concerning requirements activities in a project developed under an agile methodology. The project intended to evolve an existing product and, therefore, some background information was available. The major difficulties encountered were related to non-functional needs and management of requirements dependencies.
Agile2013-11-08
Some Notes on Models and Modelling2009By Michael Jackson

ABSTRACT: Analytical models are a fundamental tool in the development of computer-based systems of every kind: their essential purpose is to support human understanding and reasoning in development. To support reasoning, models must be substantially formal. The relationship between a formal model and its—typically—non-formal subject demands care: particular attention must be paid to the model interpretation, which maps its formal terms to the phenomena of the subject. An analytical model is to be regarded not as an assertion, but as a predicate within a larger logical structure of reasoning. Analogical models, such as databases, act as run-time surrogates for some parts of the problem world; in their design the properties of the model itself must be carefully distinguished from those of its subject. Some models may be informal: informal models have many legitimate uses, but cannot serve as a basis for formal reasoning.
Software Modelling2013-11-08
Stakeholder analysis in projects: Challenges in using current guidelines in the real world2008By Anna Lund Jepsen and Pernille Eskerod

Abstract: The authors of this paper investigated the usability of current guidelines regarding stakeholder analysis by letting four project managers apply the guidelines to their renewal projects. The project managers found several challenges in using the guidelines. Especially, the guidelines lack clarity regarding (a) how to identify stakeholders and determine their importance and (b) how to reveal stakeholders’ expectations. Further, the application revealed that the project manager may not have the skills or the resources required to carry out the tasks involved in making the necessary inquiries. Therefore, the stakeholder analysis may be based on superficial rather than deep knowledge. It seems that the current guidelines should be considered as a conceptual framework rather than instructions on how to do a real world stakeholder analysis.
Stakeholder Management2013-11-08
Stakeholder Identification in the Requirements Engineering Process1999By Helen Sharp, Anthony Finkelstein, and Galal Galal

Abstract: Adequate, timely and effective consultation of relevant stakeholders is of paramount importance in the requirements engineering process. However, the thorny issue of making sure that all relevant stakeholders are consulted has received less attention than other areas which depend on it, such as scenario-based requirements, involving users in development, negotiating between different viewpoints and so on. The literature suggests examples of stakeholders, and categories of stakeholder, but does not provide help in identifying stakeholders for a specific system. In this paper, we discuss current work in stakeholder identification, propose an approach to identifying relevant stakeholders for a specific system, and propose future directions for the work.
Stakeholder Management2013-11-08
Stakeholder Management in International Projects2010A dissertation by Kirsi Aaltonen

Abstract: Today’s international projects are implemented in institutionally demanding environments and executed by coalitions of stakeholders that have differing interests, objectives and socio-cultural backgrounds. Consequently, international projects are subject to the demands and pressures presented by external stakeholders such as community groups, local residents, landowners, environmentalists, regulatory agencies, and local and national governments. Despite the acknowledged importance of stakeholder management, project research still lacks both theoretical knowledge and empirical evidence concerning various project stakeholder related phenomena. The objective of this thesis is to contribute to project research by increasing the understanding of external project stakeholder behavior and a focal project’s stakeholder management activities in international projects. The primary theoretical perspective
used in this thesis is stakeholder theory, which is applied in the context of project stakeholder research.
Stakeholder Management2013-11-08
Supporting the Dynamic Reprioritization of Requirements in Agile Development of Software Products2008A paper by Zornitza Racheva, Maya Daneva, and Luigi Buglione

Abstract - Agile requirements engineering is the approach of choice for many software producers whose realities include highly uncertain requirements, use of new development technology, and clients willing to explore the ways in which an evolving product can help their business goals. From customer’s perspective, the activity of continuous requirements reprioritization forms the very core of today’s agile approaches. However, the freedom for clients to do so does not come for free.

This paper presents results of a literature review on agile requirements prioritization methods, derives a conceptual model for understanding the inter-iteration prioritization process in terms of inputs and outcomes, and identifies issues and solutions pertinent to agile prioritization The latter are derived from the authors’ experiences and by using empirical data, published earlier by other authors.
Requirements Prioritization2013-11-08
Techniques in Requirements Elicitation1993By Joseph A. Goguen and Charlotte Linde

ABSTRACT: This paper surveys and evaluates some techniques for eliciting requirements of computer-based systems, paying particular attention to how they deal with social issues. The methods surveyed include introspection, interviews, questionnaires, and protocol, conversation, interaction, and discourse analyses. Although they are relatively untried in Requirements Engineering, we believe there is much promise in the last three techniques, which grew out of ethnomethodology and sociolinguistics. In particular, they can elicit tacit knowledge by observing actual interactions in the workplace, and can also be applied to the system development process itself.
Requirements Elicitation2013-11-08
The agile requirements refinery: Applying SCRUM principles to software product management2010By Kevin Vlaanderen, Slinger Jansen, Sjaak Brinkkemper, and Erik Jaspers

Abstract:
Context: Although agile software development methods such as SCRUM and DSDM are gaining popularity, the consequences of applying agile principles to software product management have received little attention until now.

Objective: In this paper, this gap is filled by the introduction of a method for the application of SCRUM principles to software product management.

Method: A case study research approach is employed to describe and evaluate this method.

Results: This has resulted in the ‘agile requirements refinery’, an extension to the SCRUM process that enables product managers to cope with complex requirements in an agile development environment. A case study is presented to illustrate how agile methods can be applied to software product management.

Conclusions: The experiences of the case study company are provided as a set of lessons learned that will help others to apply agile principles to their software product management process.
Agile2013-11-08
The brave new world of design requirements2011A paper by Matthias Jarke, Pericles Loucopoulos, Kalle Lyytinen, John Mylopoulos and William Robinson


Abstract - Despite its success over the last 30 years, the field of Requirements Engineering (RE) is still experiencing fundamental problems that indicate a need for a change of focus to better ground its research on issues underpinning current practices.We posit that these practices have changed significantly in recent years. To this end we explore changes in software system operational environments, targets, and the process of RE. Our explorations include a field study, as well as two workshops that brought together experts from academia and industry. We recognize that these changes influence the nature of central RE research questions. We identify four new principles that underlie contemporary requirements processes, namely: (1) intertwining of requirements with implementation and organizational contexts, (2) dynamic evolution of requirements, (3) emergence of architectures as a critical stabilizing force, and (4) need to recognize unprecedented levels of design complexity. We recommend a re-focus of RE research based on a review and analysis of these four principles, and identify several theoretical and practical implications that flow from this analysis.
Requirements Engineering2013-11-08
The Challenges of Complex IT Projects2004Study Overview

This study, conducted by a group of Fellows of The Royal Academy of Engineering and British Computer Society (BCS), seeks to improve the understanding of how complex IT projects differ from other engineering projects, with a view to identifying ways to augment the successful delivery of IT projects. The findings and recommendations are derived from the extensive body of evidence collected, in both written and oral form, from more than 70 individuals, encompassing senior directors, managers, project managers and software engineers from the public and private sector, as well as academic experts.
Project Management2013-11-08
The Design and Improvement of a Software Project Management System Based on CMMI2012By Guoping Zhou and Weimin Shao

ABSTRACT: The paper researched and analyzed the characteristics, deficiencies and reasons of a management system of a software enterprise project to design a software project management system based on CMMI 1.2, thus helping the enterprise to improve development and management efficiency of software project and reduce the risks and costs on project development. It studied CMMI model version 1.3 which is recently released by SEI, analyzed its characteristics and told the difference between version 1.2 and version 1.3. In addition, an improvement proposal and a solution of the software project management system were given from multiple perspectives.
Project Management2013-11-08
The Inevitable Pain of Software Development: Why There is No Silver Bullet2003A paper by Daniel M. Berry that touches on the following models: Build & Fix, Waterfall, Structured Programming, Requirements Engineering, Extreme Programming, Rapid Prototyping, and a number of potential solutions for a "Silver Bullet" to software development, and why none of them are.Software Development
Process Models
2013-11-08
The Meaning of Requirements1997By Michael Jackson

ABSTRACT: We use the term requirements to denote what are often called functional requirements. Requirements are located in the environment, which is distinguished from the machine to be built. A requirement is a condition over phenomena of the environment. A specification is a restricted form of requirement, providing enough information for the implementer to build the machine (by programming it) without further environment knowledge.
To describe requirements appropriately we must fit our descriptions into an appropriate structure. This structure must respect the distinction between the machine and the environment, and the distinction between those environment properties that are given (indicative descriptions) and those that must be achieved by the machine (optative descriptions).
Formalisation is a fundamental problem of requirements engineering. Since most environments are parts of the physical world, and therefore informal, the formalisation task is inescapable. Some techniques are discussed for tackling this task. In particular, the use of designations is explained, and the distinction between definition and assertion. By using the smallest possible set of designated terms, augmented by appropriate definitions, the developer can create a narrow bridge between the environment and its descriptions in the requirements. In this way a sufficiently faithful approximation to the informal reality can be obtained.
Requirements Definition and Specification2013-11-08
The Name and Nature of Software Engineering2008By Michael Jackson

ABSTRACT: The nature of software engineering is discussed with particular reference to software-intensive application systems—those whose fundamental purpose is to bring about desired effects in a physical and human problem world by interaction with a programmed machine. Such systems bring together a problem world—which is typically composed of heterogeneous domains, most of which are non-formal—and the formal or semi-formal domain of the machine. A clean engineering separation of the two is rarely, if ever, possible; and attempts to treat the application problem world as an extension of the formal machine are obstructed by its non-formal nature. Software engineers have much to learn from the structure and practices of the established branches of engineering. We must learn from their treatment of formal analysis and reasoning, from their practice of intense specialisation, from their attention to particular instances no less than to general concerns, and—above all—from their reliance on normal artifact design and on normal design disciplines: both are the golden fruit of specialisation.
Requirements Engineering2013-11-08
The role of Comprehension in Requirements and Implications for Use Case Descriptions2011A paper by Keith Phalp, Anita Adlem, Sheridan Jeary, Jonathan Vincent and John Kanyaru

Abstract - Within requirements engineering it is generally accepted that in writing specifications (or indeed any requirements phase document), one attempts to produce an artifact which will be simple to comprehend for the user. That is, whether the document is intended for customers to validate requirements, or engineers to understand what the design must deliver, comprehension is an important goal for the author. Indeed, advice on producing ‘readable’ or ‘understandable’ documents is often included in courses on requirements engineering. However, few researchers, particularly within the software engineering domain, have attempted either to define or to understand the nature of comprehension and it’s implications for guidance on the production of quality requirements.
Therefore, this paper examines thoroughly the nature of textual comprehension, drawing heavily from research in discourse process, and suggests some implications for requirements (and other) software documentation. In essence, we find that the guidance on writing requirements, often prevalent within software engineering, may be based upon assumptions which are an oversimplification of the nature of comprehension. Hence, the paper examines guidelines which have been proposed, in this case for use case descriptions, and the extent to which they agree with discourse process theory; before suggesting refinements to the guidelines which attempt to utilise lessons learned from our richer understanding of the underlying discourse process theory. For example, we suggest subtly different sets of writing guidelines for the different tasks of requirements, specification and design.
Requirements Definition and Specification2013-11-08
Towards an Understanding of the Business Process Analyst: An Analysis of Competencies2012By Thembela Sonteya and Lisa Seymour

Abstract

The increase in adoption of business process management (BPM) and service oriented architecture (SOA) has created a high demand for qualified professionals with a plethora of skills. However, despite the growing amount of literature available on the topics of BPM and SOA, little research has been conducted around developing a detailed list of competencies required for SOA and BPM professionals. The purpose of this paper is to provide an analysis of the required competencies of the business process analyst. The new business process analyst role is seen as indispensable to the success of BPM and SOA projects. This qualitative research used data collected through semi-structured interviews and through subsequent thematic analysis; a business process analyst competency framework emerged. The findings show that the business analyst competencies form a foundation for the business process analyst role. Even more than the business analyst role, the business process analyst requires strong interpersonal competencies and strengths as well as both left brain (statistical) and right brain (emotional) thinking. Business and organisational knowledge is seen as important while technical competencies were considered the least important. Although this research is positioned in South Africa, where the availability of skills is a major challenge facing the establishment of the business process analyst role, the resultant framework should be useful for any information systems educators designing curriculum for this new role and for organisations hoping to employ these professionals.
Business Process Management2013-11-08
Towards Lightweight Requirements Documentation2010By Zheying Zhang, Mike Arvela, Eleni Berki, Matias Muhonen, Jyrki Nummenmaa, and Timo Poranen

Abstract: Most requirements management processes and associated tools are designed for document-driven software development and are unlikely to be adopted for the needs of an agile software development team. We discuss how and what can make the traditional requirements documentation a lightweight process, and suitable for user requirements elicitation and analysis. We propose a reference model for requirements analysis and documentation and suggest what kind of requirements management tools are needed to support an agile software process. The approach and the reference model are demonstrated in Vixtory, a tool for requirements lightweight documentation in agile web application development.
Agile2013-11-08
Toxic Concepts in Systems Analysis and Design: The Systems Development Lifecycle2010By Paul Ralph

ABSTRACT: This position paper argues that the the SystemsDevelopment Lifecycle is a Toxic Concept, i.e., an ideathat is both false and harmful. SDLC is defined and itscriticisms are summarized. A process theory, the SCIFramework, is suggested as an alternative.
Software Development
Process Models
2013-11-08
UML-Intensive Framework for Modeling Software Requirements2009By Dr. Darius Silingas, Prof. Rimantas Butleris

ABSTRACT: Investigation of software projects has shown that requirements analysis is one of the most problematic activities in software development. Textual requirements specifications are difficult to develop, understand, review, and maintain. Graphical modeling is widely recognized as a more effective analysis tool. Software industry has adopted UML (Unified Modeling Language) as de facto standard in software modeling. UML defines a powerful, but also difficult to learn, modeling toolkit: 13 types of diagrams, more than 100 inter-related metaclasses used as modeling concepts, and possibility to define custom extensions. Since UML doesn’t define modeling method, practitioners lack guidance on how to apply it efficiently to modeling software requirements, and apply it only fragmentally loosing many benefits that UML provides. In this paper, we present the analysis of modern requirements modeling techniques. Based on analysis results, we discuss how various domain and requirements analysis elements – semantic map of business concepts, lifecycles of business objects, business processes, business rules, system context diagram, use cases and their scenarios, constraints, and user interface prototypes – can be modeled using UML. We propose UML extensions and a practical UML-intensive framework necessary for concise requirements modeling. The application of this framework is demonstrated by modeling a case study – software system for library management – using customized MagicDraw UML environment. Our work is important for practitioners trying to adopt UML for requirements analysis and for scientists working on creating more detailed requirements analysis methods based on UML.
Software Modelling2013-11-08
Understanding the Customer:What Do We Know about Requirements Elicitation?2008An article by Oscar Dieste, Natalia Juristo, and Forrest ShullRequirements Elicitation2013-11-08
Using Satisfaction Arguments and Rich Traceability in Requirements Prioritisation2008By Praveen Kumar Motupally

DISSERTATION ABSTRACT:
Requirement Engineering (RE) is a distinct subset activity of Systems Engineering. Eliciting and Specifying requirements are the sub processes of RE. Eliciting and Specifying correct requirements, that meet the customer’s needs contributes to the project’s Quality and Success. However determining the “Candidate Requirements” is challenging for a number of reasons. Requirement Prioritisation helps to cope with this problem.
A number of Requirement Prioritisation methods exists. This dissertation aims to investigate a better prioritisation technique by subjectively assessing the “effort” between prioritising requirements with the Analytical Hierarchy Process (AHP) and prioritising “Satisfaction Arguments” (SA) with AHP and subjectively assessing the “effort” again.
The results of the experiment show a similar set of priorities produced by both attempts, however, the perceived effort of prioritising SAs is less compared with prioritising requirements with AHP due to “Propagation of Priorities”. The results of the experiment show that “Propagation of Priorities” is possible with both the approaches, however “Propagation of Priorities” was found to be bi-directional when prioritising SA with AHP and unidirectional when prioritising requirements with AHP.
Requirements Prioritization2013-11-08
Utilizing Business Process Models for Requirements Elicitation2003By Onur Demirörs, Çigdem Gencel and Ayça Tarhan

ABSTRACT: Acquisition of software intensive systems demands significant work on requirements prior to establishing the contract. The acquirer needs to understand the domain, needs, and constraints of the project clearly in order to make realistic size and effort estimates, and to have a solid foundation for defining contract requirements. In this study, an approach for requirements elicitation based on business processes is investigated. The approach proposes determination of requirements of a software intensive system to be acquired, according to the business objectives and base lining business processes. This study presents the implementation of the approach in a large innovative military application within the boundary of a project for Request for Proposal (RFP) preparation.
Requirements Elicitation2013-11-08
Value Creation by Agile Projects: Methodology or Mystery?2009A paper by Zornitza Racheva, Maya Daneva, and Klaas Sikkel

Abstract - Business value is a key concept in agile software development approaches. This paper presents results of a systematic review of literature on how business value is created by agile projects. We found that with very few exceptions, most published studies take the concept of business value for granted and do not state what it means in general as well as in the specific study context. We could find no study which clearly indicates how exactly individual agile practices or groups of those create value and keep accumulating it over time. The key implication for research is that we have an incentive to pursue the study of value creation in agile project by deploying empirical research methods.
Agile2013-11-08
What's Wrong with Requirements Specification? An Analysis of the Fundamental Failings of Conventional Thinking about Software Requirements, and Some Suggestions for Getting it Right2010By Tom Gilb

ABSTRACT: We know many of our IT projects fail and disappoint. The poor state of requirements methods and practice is frequently stated as a factor for IT project failure. In this paper, I discuss what I believe is the fundamental cause: we think like programmers, not engineers and managers. We do not concentrate on value delivery, but instead on functions, on use-cases and on code delivery. Further, management is not taking its responsibility to make things better. In this paper, ten practical key principles are proposed, which aim to improve the quality of requirements specification.
Requirements Definition and Specification2013-11-08
Wiki Supported Collaborative Requirements Engineering2008By David Ferreira and Alberto Rodrigues da Silva

ABSTRACT: The high number of unsuccessful IT projects, due to the inconsistent and ambiguous requirements specifications, justifies the proposal of new socio-technical approaches to overcome these software quality issues. To address these problems it is required a platform that simultaneously fosters stakeholders’ involvement to capture their tacit knowledge, but also to enforce Requirements Engineering best practices. In this paper, we present our approach for enhancing the quality and rigor of requirements specifications by combining emergent Web 2.0 concepts with CASE tools for requirements specification and validation. This approach provides a flexible platform for collaborative Requirements Engineering: non-technical stakeholders are assisted during the elicitation process and requirements engineers benefit from the seamlessly integration with a broader CASE tool.
Requirements Engineering2013-11-08
Wiki-Based Stakeholder Collaboration in Requirements Engineering2007By Björn Decker, Eric Ras, Jörg Rech, Pascal Jaubert, and Marco Rieth

ABSTRACT: Wikis offer a flexible platform for asynchronous collaborative support of active stakeholder participation in requirements engineering.
Requirements Engineering2013-11-08
Requirements engineering tools: Capabilities, survey and assessment2012Context: There is a significant number of requirements engineering (RE) tools with different features and prices. However, existing RE tool lists do not provide detailed information about the features of the tools that they catalogue. It would therefore be interesting for both practitioners and tool developers to be aware of the state-of-the-art as regards RE tools.
Objective: This paper presents the results of a survey answered by RE tool vendors. The purpose of the survey was to gain an insight into how current RE tools support the RE process by means of concrete capabilities, and to what degree.
Results: The 38 participants sent back their answers. Most tools are delivered under a proprietary license, and their licenses are not free. A growing number of them facilitate Web access. Moreover, requirements elicitation exemplifies the best supported category of features in this study, whereas requirements modeling and management are the most badly supported categories.
Conclusion: The RE process seems to be well covered by current RE tools, but there is still a certain margin for amelioration, principally with regard to requirements modeling, open data model and data integration features. These subjects represent areas for improvement for RE tool developers. Practitioners might also obtain useful ideas from the study to be taken into account when selecting an appropriate RE tool to be successfully applied to their work.
Requirements Engineering2013-11-24
Better Requirements Decomposition Guidelines Can Improve Cost Estimation of Systems Engineering and Human Systems Integration2010By Kevin Liu, Ricardo Valerdi, and Phillip A. Laplante

Abstract
If program managers are to fund efforts to improve the quality of systems engineering and requirements decomposition in programs, they need a way to express the costs and benefits of their decisions. This paper details proposed updates to requirements decomposition guidelines that will help generate the “number of system requirements” input to the systems engineering cost model COSYSMO. The updated guidelines give better consideration of human systems integration and other nonfunctional requirements. They also incorporate the quantitative and qualitative feedback of sixteen experts who participated in a validation exercise.
Project Management2013-11-28
DeSyRe: Decomposition of Systems and their Requirements — Transition from System to Subsystem using a Criteria Catalogue and Systematic Requirements Refinement
2010A Dissertation by Birgit Penzenstadler

ABSTRACT: In software systems development, companies try to handle the increasing size and complexity of their systems by signing up different subcontractors for subsystems. For distributed development and smooth integration, a major challenge is to deduce subsystem specifications from system specifications in order to deliver them to the subcontractors. Thereby, thorough requirements engineering lays the basis for successful systems’ development in such a
divide-and-conquer approach in order to provide a subcontractor with all information they need.
Missing information within the subsystem requirements is the pitfall for successful distributed development, so that either the subsystem requirements do not fulfill the overall system requirements completely, or there is a mismatch between subsystems during integration due to inconsistencies between the specifications for the respective subsystems.
Consequently, the research objective of this work is to investigate how a requirements engineer can systematically derive subsystem requirements
specifications from system requirements specifications.
Requirements Analysis and Capture2013-11-28
Get your Requirements Stright - Storyboarding Revisited2009By Haesen, Luyten, and Coninx

ABSTRACT: Current user-centred software engineering (UCSE) approaches provide many techniques to combine know-how available in multidisciplinary teams. Although the involvement of various disciplines is beneficial for the user experience of the future application, the transition from a user needs analysis to a structured interaction analysis and UI design is not always straightforward. We propose storyboards, enriched by metadata, to specify functional and non-functional requirements. Accompanying tool support should facilitate the creation and use of storyboards. We used a meta-storyboard for the verification of storyboarding approaches.
Requirements Elicitation2014-02-05
GRIP: Get better Results from Interactive Prototypes2011By Jan Van den Bergh, Deepak Sahni, Mieke Haesen, Kris Luyten, Karin Coninx

ABSTRACT: Prototypes are often used to clarify and evaluate design alternatives for a graphical user interface. They help stakeholders to decide on different aspects by making them visible and concrete. This is a highly iterative process in which the prototypes evolve into a design artifact that is close enough to the envisioned result to be implemented. People with different roles are involved in prototyping. Our claim is that integrated or inter-operable tools help design information propagate among people while prototyping and making the transition more accurately into the software development phase. We make a first step towards such a solution by offering a framework, GRIP, in which such a tool should fit. We conducted a preliminary evaluation of the framework by using it to classify existing tools for prototyping and implementing a limited prototyping tool, GRIP-it, which can be integrated into the overall process.
Requirements Elicitation2014-02-05
MuiCSer: A Process Framework for Multi-Disciplinary User-Centred Software Engineering processes2008By Mieke Haesen, Karin Coninx, Jan Van den Bergh, and Kris Luyten

ABSTRACT: In this paper we introduce MuiCSer, a conceptual process framework for Multi-disciplinary User-centred Software Engineering (UCSE) processes. UCSE processes strive for the combination of basic principles and practices from software engineering and user-centred design approaches in order to increase the overall user experience with the resulting product. The MuiCSer framework aims to provide a common understanding of important components and associated activities of UCSE processes. As such, the conceptual framework acts as a frame of reference for future research regarding various aspects and concepts related to this kind of processes, including models, development artefacts and tools. We present the MuiCSer process framework and illustrate its instantiation in customized processes for the (re)design of a system. The conceptual framework has been helpful to investigate the role of members of a multi-disciplinary team when realizing artefacts in a model-based approach. In particular process coverage of existing artefact transformation tools has been studied.
Requirements Engineering2014-02-05
MUICSER: A MULTI-DISCIPLINARY USER-CENTERED SOFTWARE ENGINEERING PROCESS TO INCREASE THE OVERAL USER EXPERIENCE2008By Mieke Haesen, Kris Luyten, Karin Coninx, Jan Van den Bergh and Chris Raymaekers

ABSTRACT: In this paper we present an incremental and user-centered process to create suitable and usable user interfaces. Validation is done throughout the process by prototyping, the prototypes evolve from low-fidelity to the final user interface. Applications developed with this process are more likely to correspond to users’ expectations. Furthermore, the process takes into account the need for sustainable evolution often required by modern software configurations, by combining traditional software engineering with a user-centered approach. We think our approach is beneficial in its scope, since it considers evolving software beyond the deployment stage and supports a multi-disciplinary team.
Requirements Engineering2014-02-05
An Approach of Software Requirements Elicitation Based on the Model and Notation Business Process (BPMN)2014By Marcos A. Chiarello, Maria Cláudia F. P. Emer, and Adolfo Gustavo S. S. Neto

ABSTRACT: The high competitiveness between business organizations demands a constant innovation and evolution in their productive processes, requiring information systems to be produced and modified with the same swiftness. However, the software requirements elicitation, considered a critical step to the success of the software development, many times it is still done without an effective warranty of its alignment with the problems and needs inherent to the business. This work proposes the development of an approach for software requirements elicitation through the Model and Notation Business Process (BPMN). From the approach point of view of this problem, will be used a qualitative research, because focuses on conceptual issues, patterns, opinions expressed and their respectives analyzes and, from the point of view of technical procedures, it is based on case studies. The preliminary results of the studies indicate that its use is viable and can assist the result effectiveness of the software requirements elicitation.
Requirements Elicitation2014-02-05
Data-driven Requirements Modeling: Some Initial Results with i*2014By Aditya Ghose, Metta Santiputri, Ayu Saraswati, and Hoa Khanh Dam

ABSTRACT: Requirements acquisition is widely recognized as a hard problem, requiring significant investments in time and effort. Given the availability of large volumes of data and of relatively cheap instrumentation for data acquisition, this paper explores the prospect of data-driven model extraction in the context of i* models. The paper presents techniques for extracting dependencies from message logs, and for extracting task-dependency correlations from process logs. The preliminary empirical results are encouraging.
Requirements Elicitation2014-02-05
Predicting Requirements Changes by Focusing on the Social Relations2014By Takako Nakatani and Toshihiko Tsumaki

ABSTRACT: Software requirements are changed by various factors. Stakeholders that are analysed in traditional requirements engineering are mainly requesters or decision makers with regard to the requirements specifications. Such stakeholders are selected as intentional actors in the i* framework. The novel point of this paper is that we focus on the world of parties who are the environmental factors of the requirements of the intentional actors. Our purpose is to propose a method to predict requirements changes by focusing on the social relations. In this paper, we present our method and evaluate its effectiveness through a simulation of requirements changes.
Requirements Management2014-02-05
Requirements Elicitation Techniques: Comparative Study2013By Omar Isam Al Mrayat, Norita Md Norwawi, Nurlida Basir

ABSTRACT: Over the years, software development failures is really a burning issue, might be ascribed to quite a number of attributes, of which, no-compliance of users requirements and using the non suitable technique to elicit user requirements are considered foremost. In order to address this issue and to facilitate system designers, this study had filtered and compared user requirements elicitation technique, based on principles of requirements engineering. This comparative study facilitates developers to build systems based on success stories, making use of a optimistic perspective for achieving a foreseeable future. This paper is aimed at enhancing processes of choosing a suitable technique to elicit user requirements; this is crucial to determine the requirements of the user, as it enables much better software development and does not waste resources unnecessarily. Basically, this study will complement the present approaches, by representing a optimistic and potential factor for every single method in requirements engineering, which results in much better user needs, and identifies novel and distinctive specifications.
Requirements Elicitation2014-02-05
Agile Project Management Principles2014By Jan Juricek

ABSTRACT: This paper shows main agile principles. Agile approach is compared against standardized, eg. Waterfall oriented methodologies (also referenced as a product-based) with group of activities based on iterative and incremental development. The aim of this paper is to introduce the reader of basics agile principles and to define the pragmatic differences between the heavyweight waterfall methods, while agile is a global reaction to traditional approaches of delivering the solution or delivering the products by a standard flow: requirement – plan – delivery – acceptance. The agile principles are researched and aligned with the product-base, a waterfall model and standard project management methodologies such as PMBOK© and Prince2©.
Agile2014-02-05
Handbook of The Secure Agile Software Development Life Cycle2014University of Oulu, Finland

ABSTRACT: Software quality problems, wide impact vulnerabilities, phishing, botnets and criminal enterprise have proven that software and system security is not just an add-on despite past focus of the security industry.
Cloud computing introduces a whole ecosystem of clients, services and infrastructure, where trust boundaries are moved even further into components, where physical location or even ownership is unknown. add-on security therefore becomes more futile than it ever was. There is no place where these
add-on components would reside.
Security, trust, dependability and privacy are issues that have to be considered over the whole life-cycle of the system and software development from gathering requirements to deploying the system in practice. Doing this does not only make us safer and secure but improves overall system quality and
development efficiency.
This book brings together experiences and results from security research done in liaison by the authors during the Cloud Software Program, each bringing in their own viewpoint. The chapters are standalone articles, which can be read in any order. With this book we hope to communicate forward the explicit and tacit knowledge we have accumulated with the hopes that readers of the book (such as you) might gain something from our experiences and in result make the kingdom of clouds a bit safer and trustworthier place for the common good of us all.
Agile2014-02-05
Agile Requirements Prioritization: What Happens in Practice and What Is Described in Literature2013By Zornitza Bakolova, Maya Daneva, Andrea Herrmann and Roel Wieringa

ABSTRACT: Agile software development consists of a multitude of iterations in between which the decision what requirements to implement is re-evaluated by a process of requirements re-prioritization. In 2010, Racheva,Daneva, Herrmann, and Wieringa (2010a) examined 22 different Requirements Prioritization (RP) methods and extracted an abstracted, conceptual model of of the RP process from a generic perspective. Four months later, Racheva, Daneva, and Herrmann (2010b) present an improved version of this model based on a case study among 11 practitioners of companies that follow agile methodologies. The paper discussed in this method description (Bakalova, Daneva, Herrmann, & Wieringa, 2011) presents the same improved version of this model.
Agile2014-02-05
On the Current Measurement Practices in Agile Software Development2013By Taghi Javdani ,Hazura Zulzalil , Abdul Azim Abd Ghani, Abu Bakar Md Sultan

ABSTRACT: Agile software development (ASD) methods were introduced as a reaction to traditional software development methods. Principles of these methods are different from traditional methods and so there are some different processes and activities in agile methods comparing to traditional methods. Thus ASD methods require different measurement practices comparing to traditional methods. Agile teams often do their projects in the simplest and most effective way so, measurement practices in agile methods are more important than traditional methods, because lack of appropriate and effective measurement practices, will increase risk of project. The aims of this paper are investigation on current measurement practices in ASD methods, collecting them together in one study and also reviewing agile version of Common Software Measurement International Consortium (COSMIC) publication.
Agile2014-02-05
Existing but not Explicit - The User Perspective in Scrum Projects in Practice2013By Åsa Cajander, Marta Larusdottir and Jan Gulliksen

ABSTRACT: Agile software development processes are becoming more common, but this does not mean that the user perspective in the development is catered for. It has its challenges to integrate the users’ aspects in Scrum projects in practice. In order to better understand these challenges we have interviewed IT professionals using Scrum focusing on four different areas: responsibility for the user perspective, emphasis on usability and user experience through documentation, usability activities with users and the organisational and contextual settings for emphasizing the user perspective. Results show that the responsibility for the user perspective is unclear in Scrum projects, and that often the user perspective is neither discussed nor described in the projects. However, the user perspective is often present through informal feedback used to understand the context of use and inform design for example. Finally the paper presents implications for working with the user perspective in Scrum projects .
Agile2014-02-05
Agile Project Dynamics: A System Dynamics Investigation of Agile Software Development Methods2013By Firas Glaiel , Allen Moulton , Stuart Madnick

ABSTRACT: While Agile software development has many advocates, acceptance in the government and defense sectors has been limited. To address questions of meanings to the term “Agile,” we examine a range of Agile methods practiced and develop a framework of seven characteristics, which we call the Agile Genome. We gain insight into the dynamics of how Agile development compares to classic “waterfall” approaches by constructing a System Dynamics model for software projects. The Agile Project Dynamics (APD) model captures each of the Agile genes as a separate component of the model and allows experimentation with combinations of practices and management policies. Experimentation with the APD model is used to explore how different genes work in combination with one another to produce both positive and negative effects. The extensible design of the APD model provides the basis for further study of Agile methods and management practices.
Agile2014-02-05
Toward the Integration of Traditional and Agile Approaches2013By Hung-Fu Chang and Stephen C-Y. Lu

ABSTRACT: The agile approach uses continuous delivery, instead of distinct procedure, to work closer with customers and to respond faster requirement changes. All of these are against the traditional plan driven approach. Due to agile method’s characteristics and its success in the real world practices, a number of discussions regarding the differences between agile and traditional approaches emerged recently and many studies intended to integrate both methods to synthesize the benefits from these two sides. However, this type of research often concludes from observations of a development activity or surveys after a project. To provide a more objective supportive evidence of comparing these two approaches, our research analyzes the source codes, logs, and notes. We argue that the agile and traditional approaches share common characteristics, which can be considered as the glue for integrating both methods. In our study, we collect all the submissions from the version control repository, and meeting notes and discussions. By applying our suggested analysis method, we illustrate the shared properties between agile and traditional approaches; thus, different development phases, like implementation and test, can still be identified in agile development history. This result not only provides a positive result for our hypothesis but also offers a suggestion for a better integration.
Software Development Process Models2014-02-05
Analysing the Assumed Benefits of Software Requirements2013By Richard Ellis-Braithwaite

ABSTRACT: Often during the requirements engineering (RE) process, the value of a requirement is assessed, e.g., in requirement prioritisation, release planning, and trade-off analysis. In order to support these activities, this research evaluates Goal Oriented Requirements Engineering (GORE) methods for the description of a requirement’s value. Specifically, we investigate the goal-to-goal contribution relationship for its ability to demonstrate the value of a requirement, and propose that it is enriched with concepts such as correlation, confidence, and utility.
Requirements Engineering2014-02-05
The Illusion of Requirements in Software Development2012By Paul Ralph

ABSTRACT: It is widely accepted that understanding system requirements is important for software development project success. Put another way, it is widely acknowledged that failing to understand requirements is related to project failure. The idea that software artifacts generally have a set of discoverable, documentable requirements is entrenched in industry standards, development processes and educational curricula. More broadly, requirements are a fundamental component of the Rational Model of Design, the dominant view of how practitioners approach developing software and information systems. However, utilizing good requirements practices may not be a necessary or sufficient condition for project success. The purpose of this viewpoint is to explore the possibility of software projects with few or illusory requirements.
Requirements Engineering2014-02-05
Modelling the Strategic Alignment of Software Requirements using Goal Graphs2012By Richard Ellis-Braithwaite, Russell Lock, Ray Dawson, and Badr Haque

ABSTRACT: 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.
Requirements Engineering2014-02-05
An Application of Uncertain Reasoning to Requirements Engineering1999By Philip S. Barry and Kathryn Blackmond Laskey

ABSTRACT: This paper examines the use of Bayesian Networks to tackle one of the tougher problems in requirements engineering, translating user requirements into system requirements. The approach taken is to model domain knowledge as Bayesian Network fragments that are glued together to form a complete view of the domain specific system requirements. User requirements are introduced as evidence and the propagation of belief is used to determine what are the appropriate system requirements as indicated by user requirements. This concept has been demonstrated in the development of a system specification and the results are presented here.
Requirements Engineering2014-02-05
Influence of Context on Decision Making during Requirements Elicitation2012By Corentin BURNAY , Ivan JURETA and Stephane FAULKNER

ABSTRACT: Requirements engineers should strive to get a better insight into decision making processes. During elicitation of requirements, decision making influences how stakeholders communicate with engineers, thereby affecting the engineers’ understanding of requirements for the future information system. Empirical studies issued from Artificial Intelligence offer an adequate groundwork to understand how decision making is influenced by some particular contextual factors. However, no research has gone into the validation of such empirical studies in the process of collecting needs of the future system’s users. As an answer, the paper empirically studies factors, initially identified by AI literature, that influence decision making and communication during requirements elicitation. We argue that the context’s structure of the decision should be considered as a cornerstone to adequately study how stakeholders decide to communicate or not a requirement. The paper proposes a context framework to categorize former factors into specific families, and support the engineers during the elicitation process.
Requirements Elicitation2014-02-05
Requirements Engineering Methods: A Classification Framework and Research Challenges2012By Ivan J. Jureta

ABSTRACT: Requirements Engineering Methods (REMs) support Requirements Engineering (RE) tasks, from elicitation, through modeling and analysis, to validation and evolution of requirements. Despite the growing interest to design, validate and teach REMs, it remains unclear what components REMs should have. A classification framework for REMs is proposed. It distinguishes REMs based on the domain-independent properties of their components. The classification framework is intended to facilitate (i) analysis, teaching and extension of existing REMs, (ii) engineering and validation of new REMs, and (iii) identifying research challenges in REM design. The framework should help clarify further the relations between REM and other concepts of interest in and to RE, including Requirements Problem and Solution, Requirements Modeling Language, and Formal Method.
Requirements Engineering2014-02-05
Theory of Regulatory Compliance for Requirements Engineering2013By Ivan J. Jureta, Alberto Siena, John Mylopoulos, and Anna Perini

ABSTRACT: Regulatory compliance is increasingly being addressed in the practice of requirements engineering as a main stream concern. This paper points out a gap in the theoretical foundations of regulatory compliance, and presents a theory that states (i) what it means for requirements to be compliant, (ii) the compliance problem, i.e., the problem that the engineer should resolve in order to verify whether requirements are compliant, and (iii) testable hypotheses (predictions) about how compliance of requirements is verified. The theory is instantiated by presenting a requirements engineering framework that implements its principles, and is exemplified on a real-world case study.
Requirements Engineering2014-02-05
Problem Identification and Decomposition within the Requirements Generation Process2002By Ahmed S. Sidky, Rajat R. Sud, Shishir Bhatia and James D. Arthur

ABSTRACT: Only recently has the real importance of the requirements generation process and its requisite activities been recognized. That importance is underscored by the evolving partitions and refinements of the once all-encompassing (and somewhat miss-named) Requirements Analysis phase of the software development lifecycle. Continuing along that evolutionary line, we propose an additional refinement to the requirements generation model that focuses on problem identification and its decomposition into an associated set of user needs that drive the requirements generation process. Problem identification stresses the importance of recognizing and identifying the difference between a perceived state of the system and the desired one. We mention pre- and post-conditions that help identify and bound the “problem,” and then present some methods and techniques that assist in refining that boundary and also in recognizing essential characteristics of the problem. We continue by presenting a process by which the identified problem and its characteristics are decomposed and translated into a set of user needs that provide the basis for the solution description, i.e, the set of requirements. Finally, to place problem identification and decomposition in perspective, we present them within the framework of the Requirements Generation Model.
Requirements Analysis and Capture2014-02-05
Applying Mind Maps at Representing Software Requirements2013By José Antonio Ponqueli Contó, Wagner Fontes Godoy, Rodrigo Henrique Cunha Palácios, Elias Canhadas Genvigir, Alexandre L´Erario, André L. S. Domingues, José
Antônio Gonçalves, Alessandro Silveira Duarte, José Augusto Fabri

ABSTRACT: This paper proposes a generic model that uses mind maps in the representation of software requirements. In order to validate this proposal it was applied an experimental research method. A survey questionnaire was submitted to 10 software developers for evaluation.
Requirements Analysis and Capture2014-02-05
COMPARISON OF SIX PRIORITIZATION TECHNIQUES FOR SOFTWARE REQUIREMENTS2013By Manju Khari and Nikunj Kumar

ABSTRACT: There are many requirements prioritization techniques and selecting the most appropriate one is a decision problem in its own rights. This paper takes a closer look at the six requirement prioritization techniques and put them in a controlled experiment with the objective of understanding differences regarding ease of use, total time taken, scalability, accuracy, and total number of comparisons required to make decisions. These five criteria combined will indicate which technique is more suitable. The result from the experiment shows that Value oriented Prioritization (VOP) yields an accurate result, can scale up, and requires the least amount of time.
Requirements Prioritization2014-02-05
RSL-PL: A Linguistic Pattern Language for Documenting Software Requirements2013By David de Almeida Ferreira and Alberto Rodrigues da Silva

ABSTRACT: Software requirements are traditionally documented in natural language (NL). However, despite being easy to understand and having high expressivity, this approach often leads to well-known requirements quality problems. In turn, dealing with these problems warrants a significant amount of human effort, causing requirements development activities to be error-prone and time-consuming. This paper introduces RSL-PL, a language that enables the definition of linguistic patterns typically found in well-formed individual NL requirements, according to the field’s best practices. The linguistic features encoded within RSL-PL patterns enable the usage of information extraction techniques to automatically perform the linguistic analysis of NL requirements. Thus, in this paper we argue that RSL-PL can improve the quality of requirements specifications, as well as the productivity of requirements engineers, by mitigating the continuous effort that is often required to ensure requirements quality criteria, such as clearness, consistency, and completeness.
Requirements Definition and Specification2014-02-05
Getting the balance right between functional and non-functional requirements: the case of requirement specification in IT procurement2013By Björn Johansson and Markus Lahtinen

ABSTRACT: IT procurement represents a business process of high importance, including the ability to articulate requirements that the procurement deals with. Furthermore, specifying requirements is of importance for both procurer and potential supplier, as it functions as central contractual element between the two. The purpose of this article is two-fold: (i) to show how established terminology for requirement specification is represented in current call for bids for the procurement of IT; and (ii) to introduce an organizing framework that may assist procurers in actively addressing functional requirements and business requirements. Ten “call for bids” were examined from a Swedish national procurement database. From the analysis of the bids, it can be concluded that: (i) the call for bids displays a high degree of precision regarding hardware aspects, but less precision regarding software; (ii) supplier experience and competence is stressed, but rarely elaborated on in detail; and (iii) call for bids vagueness may be used as a lock-in opportunity for suppliers. From the discussion on this, a tentative procurement framework is suggested, aiming on increasing the logical transparency for the procurement of IT.
Requirements Definition and Specification2014-02-05
Providing value by prioritizing requirements throughout software product development: State of practice and suitability of prioritization methods2006By Laura Lehtola

THESIS: This thesis investigates how the prioritization and selection of requirements is organized during product development in software companies operating in the product business, and what the practical challenges involved are. In addition, the suitability of prioritization
methods from the requirements engineering literature to solve these challenges is discussed.
Requirements Prioritization2014-02-05
Are Your Requirements Complete?2005By Donald Firesmith

ABSTRACT: Good requirements have several useful properties, such as being consistent, necessary, and unambiguous. Another essential characteristic that is almost always listed is that ‘requirements should be complete.’ But just what does completeness mean, and how should you ensure that your requirements are complete? In this column, we will begin to address these two questions by looking at (1) the importance of requirements completeness, (2) the completeness of requirements models, (3) the completeness of various types of individual requirements, and (4) the completeness of requirements metadata. In next issue’s column, we will continue by addressing (5) the completeness of requirements repositories, (6) the completeness of requirements documents derived from such repositories of requirements, (7) the completeness of sets of requirements documents, (8) the completeness of requirements baselines, and finally (9) determining how complete is complete enough when using an incremental and iterative development cycle.
Requirements Analysis and Capture2014-02-07
Common Requirements Problems, Their Negative Consequences, and Industry Best Practices to Help Solve Them2007By Donald Firesmith

ABSTRACT: In this column, I summarize the 12 worst of the most common requirements engineering problems I have observed over many years working on and with real projects as a requirements engineer, consultant, trainer, and evaluator. I also list the negative consequences of these problems, and most importantly suggest some industry best practices that can help you avoid these problems, or at least fix them once they have raised their ugly heads. Although there is nothing really new here, these problems are well worth revisiting because they are still far too common, probably because the associated industry best practices are still far from being widely put into practice.
Requirements Analysis and Capture2014-02-07
Requirements Engineering Tasks2006By Donald Firesmith

ABSTRACT: Having well-engineered requirements is critical. This is not just due to their major positive impact on project costs (both development and life-cycle) and schedule, which are largely due to the extreme costs of fixing requirements defects once the system is built and fielded. Also critical is having well-engineered functional and quality requirements because of their positive impact on system acceptability by its many stakeholders.
Requirements Engineering2014-02-07
Quality Requirements Checklist2005By Donald Firesmith

ABSTRACT: On an individual requirement by requirement basis, quality requirements are typically much more important than functional requirements because they most strongly drive the architecture of software-intensive systems. Thus, it is how well the quality requirements are engineered and implemented that tends to determine the success or failure of mission critical systems. Yet, missing or poorly specified quality requirements can all too commonly be identified during effective evaluations of the requirements specifications and the resulting architectures. This column provides a short checklist for use during the engineering and evaluation of quality requirements to help the requirements team develop better quality requirements and to help evaluators of these requirements identify defects in the associated requirements specifications.
Requirements Analysis and Capture2014-02-07
Formalism, technique and rigour in Use Case Modelling2005By Bruce Anderson

ABSTRACT: Use case modelling is widely used as a technique for requirements gathering but does not always lead to clear agreement between users and developers, or to effective system development. This is often because the model does not have a clear role in a clear process, with a corresponding lack of agreed standards and techniques. Taking a considered approach and tailoring the available guidance to the situation at hand can produce more appropriate use cases that are more useful in the overall process. This paper outlines a sound approach in a context of ideas and technique, and discusses several common issues in use case modelling, with suggested resolutions.
Requirements Definition and Specification2014-02-07
Prioritizing Requirements2004By Donald Firesmith

ABSTRACT: In this column, I address the often difficult task of prioritizing requirements so that the highest priority requirements can be implemented first as part of the scheduling of an incremental, iterative, and time-boxed development cycle. After defining the meaning of the term “priority”, the purpose and benefits of requirements prioritization are listed. This is followed by a brief discussion of the challenges and risks that a requirements team must face when prioritizing requirements. Then, various techniques for prioritizing requirements are identified, and finally a set of recommendations (including a recommended prioritization process) are made.
Requirements Prioritization2014-02-07
Specifying Good Requirements2003By Donald Firesmith

ABSTRACT: Many of the characteristics of properly specified requirements have been well known for many years, at least among professional requirements engineers. Yet most requirements specifications seen today in industry still include many poor-quality requirements. Far too many requirements are ambiguous, incomplete, inconsistent, incorrect, infeasible, unusable, and/or not verifiable (e.g., not testable). To combat this sad state of affairs, this column provides a questionnaire that can be used when specifying and technically evaluating requirements.
Requirements Definition and Specification2014-02-07
Modern Requirements Specification2003By Donald Firesmith

ABSTRACT: Requirements specification is the requirements engineering task during which analyzed requirements are properly documented for use by their intended audiences. Traditionally, this involved the requirements team using a word processing program to produce a single requirements specification document during an initial requirements phase of a project. However, trends in system development have made the numerous problems with this approach abundantly clear. Improvements in requirements tools have not only enabled better requirements management; they have also enabled the automatic generation of consistent, current, audience-specific requirements specifications that far better meet the needs of their individual audiences.
Requirements Definition and Specification2014-02-07
Requirements Engineering - Part 1 2002By Donald Firesmith

ABSTRACT: Because all other activities are influenced or driven by it, requirements engineering is arguably the most important activity performed during the development of software-intensive systems. Yet, there has been remarkably little standardization on what requirements engineering is and how it should be done beyond the growing de facto standard of using some kind of use case modeling for functional requirements. The first two articles of this column lay the foundation for my future columns on requirements engineering by defining the reusable requirements related process components of the OPEN Process Framework (OPF) and by providing you with an industry-standard terminology for organizing and communicating requirements engineering concepts.
Requirements Engineering2014-02-07
Requirements Engineering - Part 2 2002By Donald Firesmith

ABSTRACT: In my first column, I introduced the OPEN Process Framework (OPF), which provides an industry-standard terminology for organizing and communicating process engineering concepts. In it, I also introduced the reusable requirements engineering work products that are part of the OPF. This second article introduces the remaining reusable process components that are useful for requirements engineering: specifically, the requirements work units, the producers of the requirements work products that perform these work units, and the associated languages that are involved in requirements engineering.
Requirements Engineering2014-02-07
Repeatable Quality Assurance Techniques for Requirements Negotiations2003By Paul Grünbacher, Michael Halling, Stefan Biffl, Hasan Kitapci, and Barry W. Boehm

ABSTRACT: Many software projects fail because early life-cycle defects such as ill-defined requirements are not identified and removed. Therefore, quality assurance (QA) techniques for defect detection and prevention play an important role. The effectiveness and efficiency of QA approaches has been empirically evaluated. In this paper we discuss QA techniques optimized for requirements negotiations. In particular, we focus on negotiations using the EasyWinWin approach. We present (1) repeatable techniques for checking quality throughout negotiations as well as (2) role-oriented inspection techniques helping a project team to reduce unnecessary complexity and to mitigate risks stemming from defects in requirements negotiation results. We present the results of a thorough feasibility study we conducted to test our approach.
Requirements Analysis and Capture2014-02-07
Recommended Requirements Gathering Practices2002By Dr. Ralph R. Young

ABSTRACT: This article provides suggested conditions for performing requirements gathering and recommended requirements gathering practices. The author has conducted an extensive review of industry literature and combined this with the practical experiences of a set of requirements analysts who have supported dozens of projects. The sidebar on page 10 summarizes a set of recommended requirements gathering practices. Involving customers and users throughout the development effort results in a better understanding of the real needs. Requirements activities should be performed throughout the development effort, not just at the beginning of a project.
Requirements Elicitation2014-02-07
Stakeholder Analysis in the Context of the Lean Enterprise2003A Thesis by Ignacio Grossi

This thesis combines three different areas of study that are very active nowadays: Lean Enterprises, Stakeholder Theory, and Social Networks. Elements from these three research areas have been articulated to produce a methodology that allows for the analysis of stakeholder systems. In order to successfully apply lean enterprise principles and practices the study of the way in which stakeholders are structured along the extended enterprise is an indispensable first step. In a similar manner, stakeholder management practices require the identification of the most salient stakeholders together with their motivations to participate in the enterprise's value creation efforts. Original frameworks and methodologies for stakeholder systems analysis are presented in this thesis. Several qualitative, quantitative and systematic techniques have been developed that allow for the characterization and mapping of stakeholder networks. Among them are models for stakeholder systems representation, a process for the identification of stakeholders, a method to determine their salience and relationships relevance, and several stakeholder network metrics. Also is proposed and demonstrated the use of Dependency Structure Matrix technique for the analysis of stakeholder networks structural and functional characteristics. Some of these methodologies rely on known theories and practices such as social network analysis techniques and other graph theoretic concepts although their combination and further development provide an original set of tools for the analysis of stakeholder systems. All these methodologies were applied to a real case enterprise scenario. The stakeholder system of a relatively small space application enterprise was analyzed and characterized. Several important(cont.) conclusions were derived from this enterprise's stakeholder analysis, demonstrating the capabilities and adequacy of the methods and techniques proposed.
Stakeholder Management2014-03-13
Does the Prioritization Technique Affect Stakeholders Selection of Essential Software Product Feature?2012By Hans Christian Benestad and Jo E. Hannay

Context: To select the essential, non-negotiable product features is a key skill for stakeholders in software projects. Such selection relies on human judgment, possibly supported by structured prioritization techniques and tools. Goal: Our goal was to investigate whether certain attributes of prioritization techniques affect stakeholders’ threshold for judging product features as essential. The four investigated techniques represent four combinations of granularity (low, high) and cognitive support (low, high). Method: To control for robustness and masking effects when investigating in the field, we conducted both an artificial experiment and a field experiment using the same prioritization techniques. In the artificial experiment, 94 subjects in four treatment groups indicated the features (from a list of 16) essential when buying a new cell phone. In the field experiment, 44 domain experts indicated the software product features that were essential for the fulfillment of the project’s vision. The effects of granularity and cognitive support on the number of essential ratings were analyzed and compared between the experiments. Result: With lower granularity, significantly more features were rated as essential. The effect was large in the general experiment and extreme in the field experiment. Added cognitive support had medium effect, but worked in opposite directions in the two experiments, and was not statistically significant in the field experiment. Implications: Software projects should avoid taking stakeholders’ judgments of essentiality at face value. Practices and tools should be designed to counteract biases and to support the conscious knowledge-based elements of prioritizing.
Requirements Prioritization2014-07-06
Evaluating the Practical Use of Different Measurement Scales in Requirements Prioritization2006By Lena Karlsson, Martin Host, Bjorn Regnell

ABSTRACT
The importance of prioritising requirements is widely recognised. A number of different techniques for prioritising requirements have been proposed, some based on an ordinal scale, others on a ratio scale. Some measurement scales provide more information than others, i.e. the ratio scale is richer than the ordinal scale. This paper aims to investigate the differences between the scales used in prioritisation. This is important since techniques using a richer scale tend to be more time-consuming and complex to use. Thus, there is a trade-off between simple techniques only providing ranks and complex techniques providing information about the relative distance between requirements priorities. The paper suggests an approach to measure the skewness of the ratio distribution and a way to use the cost-value approach on ordinal scale data. Four different empirical data sets were used to verify the suggested approaches. The skewness measure seems feasible to determine in which cases the ratio scale is valuable. It indicates that some of our subjects tend to use the extreme values of the scale while others are more modest. The cost-value approach based on ordinal scale data also seems feasible. The requirements selection decisions based on ordinal scale data agree substantially with the decisions based on ratio scale data.
Requirements Prioritization2014-07-06
Evolving Prioritization for Software Product Management2007A Thesis by Patrik Berander

This thesis primarily focuses on evolving the current body of knowledge in relation to release planning in general and requirements prioritization in particular. The research is carried out by performing qualitative and quantitative studies in industrial and academic environments with an empirical focus. Each of the presented studies has its own focus and scope while together contributing to the research area. Together they answer questions about why and how requirements prioritization should be conducted, as well as what aspects should be taken into account when making decisions about the content of products.
The primary objective of the thesis is to give guidelines on how to evolve requirements prioritization to better facilitate decisions regarding the content of software products. This is accomplished by giving suggestions on how to perform research to evolve the area, by evaluating current approaches and suggest ways on how these can be improved, and by giving directions on how to align and focus future research to be more successful in development of decision-support approaches. This means that the thesis solves problems with requirements prioritization today, and gives directions and support on how to evolve the area in a successful way.
Requirements Prioritization2014-07-06
Prioritization of Stakeholder Needs in Software Engineering2004A Thesis by Patrik Berander

In this thesis, the area of prioritization of software products is
investigated in detail and a number of studies where prioritizations
are performed in both process and product settings are presented.
It is shown that it is possible to use prioritization techniques com-
monly used in product development also when prioritizing
improvement issues in a software company. It is also shown that
priorities between stakeholders of a software process sometimes
differ, just as they do when developing software products. The the-
sis also presents an experiment where different prioritization tech-
niques are evaluated with regard to ease of use, time consumption,
and accuracy. Finally, an investigation of the suitability of students
as subjects when evaluating prioritization techniques is presented.
Requirements Prioritization2014-07-06
A Systematic Review of Software Requirements Prioritization2006A thesis by Kashif Ahmed Khan

ABSTRACT: Software engineering research has been, and still is criticised as being immature and unscientific due to lack of evaluation. However, software engineering community is now focusing more on empirical research and there is a movement to adopt approaches from other mature fields like medical science and one such approach is Systematic Reviews. One of the major activities within the requirements engineering process is to use requirements prioritization that helps to focus on the most important requirements. There are many prioritization techniques available to prioritize software requirements; still there is lack of evidence of which technique to prefer. The reasons could be the differences in contexts, measurement of variables and usage of data sets. In this thesis, the area of requirements prioritization has been systematically reviewed in order to assess what evidence regarding different prioritisation techniques exist. The results from different studies are contradictory in nature due to variations in study designs, research methodologies and choice of different dependent and context variables. Based on the results of the systematic review, a research framework has been proposed to provide the researchers with a common background for further research with in requirements prioritization area. The goal of the framework is to develop reliable knowledge base as well as help researchers conduct and report prioritization studies.
Requirements Prioritization2014-07-06
An evaluation of methods for prioritizing software requirements1997By Joachim Karlsson, Claes Wohlin, and Bjorn Regnell

Abstract:
This article describes an evaluation of six different methods for prioritizing software requirements. Based on the quality requirements for a telephony system, the authors individually used all six methods on separate occasions to prioritize the requirements. The methods were then characterized according to a number of criteria from a user’s perspective. We found the analytic hierarchy process to be the most promising method, although it may be problematic to scale-up. In an industrial follow-up study we used the analytic hierarchy process to further investigate its applicability. We found that the process is demanding but worth the effort because of its ability to provide reliable results, promote knowledge transfer and create consensus among project members.
Requirements Prioritization2014-07-06
Towards a Research Framework on Requirements Prioritization2006By Patrik Berander, Kashif Ahmed Khan, and Laura Lehtola

ABSTRACT
There exist a large number of approaches for prioritization of software requirements. Despite of several empirical studies, there is still a lack of evidence of which approaches that are to prefer, since different studies have resulted in different conclusions. Reasons may be due to differences in contexts, variables measured, and data sets used. This paper presents a research framework for studies about requirements prioritization, which aims to enable building a more consistent knowledge base and stronger evidence. The framework facilitates comparison, replication, and high-level analysis of prioritization approaches by proposing suitable variables to measure. The basis of the framework comes from a systematic review conducted on requirements prioritization techniques, and is further refined through literature studies of similar frameworks in related areas, and in a research workshop. The framework supports researchers in conducting and reporting prioritization studies, and supports
practitioners in getting information about different approaches
Requirements Prioritization2014-07-06
A Comparison of Nine Basic Techniques for Requirements Prioritization2010By Mikko Vestola

Abstract — Requirements prioritization is an important activity in software development. Numerous different techniques to prioritize requirements exist. In this paper, we focus on the following research questions: 1) What empirically studied requirements prioritization techniques are presented in the literature? 2) How easy to use, accurate and scalable are these techniques? Total of nine basic requirements prioritization techniques were identified: 1) Numeral assignment technique, 2) Analytic hierarchy process (AHP), 3) Hierarchy AHP, 4) Minimal spanning tree, 5) Cumulative voting (CV), 6) Hierarchical cumulative voting (HCV), 7) Priority groups, 8) Binary priority list (BPL), 9) Bubble sort. The techniques are presented and analyzed based on the empirical studies from the literature. The results indicate that none of the techniques can be considered the best one. The best prioritization technique depends on the situation (e.g. number of requirements used or desired results scale). This study also reveals that there are several problems with the existing empirical studies, which make it hard to compare their results to each other. Therefore, this paper also presents recommended practices for future empirical studies about requirements prioritization
techniques.
Requirements Prioritization2014-07-06
Anticipating Requirements Changes – Using Futurology in Requirements Elicitation2012By João Pimentel, Emanuel Santos, Jaelson Castro, and Xavier Franch

Abstract - It is well known that requirements changes in a later phase of software developments is a major source of software defects and costs. Thus, the need of techniques to control or reduce the amount of changes during software development projects. We advocate the use of foresight methods as a valuable input to requirements elicitation, with the potential to decrease the number of changes that would be required after
deployment, by anticipating them. In this paper we define a process for using a foresight method, namely Futures Wheel, for requirements elicitation. To illustrate the use of this approach, we perform a case study using a route planning system.
Requirements Elicitation2015-05-18
Towards Anticipating Requirements Changes through Studies of the Future2011By Pimentel, Santos, Castro, and Franch

Abstract— Whilst it is considered a good practice to focus Requirements Engineering on current stakeholder needs, the high costs implied by requirements changes and the emergence of the Autonomic Computing paradigm raised the need for dealing with issues that are not currently requirements but that may come to be in the future. This work shows how foresight techniques can be used for requirements elicitation, and discusses the impacts of studying the future to that requirements engineering activity. In particular, it addresses the use of the Futures Wheel method to enrich goal models.
Requirements Elicitation2015-05-18

Leave a Reply

Your email address will not be published. Required fields are marked *