Using quality models in software package selection

The growing importance of commercial off-the-shelf software packages requires adapting some software engineering practices, such as requirements elicitation and testing, to this emergent framework. Also, some specific new activities arise, among which selection of software packages plays a prominent role. All the methodologies that have been proposed recently for choosing software packages compare user requirements with the packages' capabilities. There are different types of requirements, such as managerial, political, and, of course, quality requirements. Quality requirements are often difficult to check. This is partly due to their nature, but there is another reason that can be mitigated, namely the lack of structured and widespread descriptions of package domains (that is, categories of software packages such as ERP systems, graphical or data structure libraries, and so on). This absence hampers the accurate description of software packages and the precise statement of quality requirements, and consequently overall package selection and confidence in the result of the process. Our methodology for building structured quality models helps solve this drawback.Peer ReviewedPostprint (published version

Toward the Design and Implementation of Traceability Engineering Tool Support

Requirements of a system keep on changing based on the need of stakeholders or the system developers, making requirement engineering an important aspect in software development. This develops a need for appropriate requirement change management. The importance of requirements traceability is defining relationships between the requirements and artefacts extracted by the stakeholder during the software development life-cycle and gives vital information to encourage software understanding. In this paper, we have concentrated on developing a tool for requirement traceability that can be used to extend the requirement elicitation and identification of system-wide qualities using the notion of quality attribute scenarios to capture the non-functional requirements. It allows us to link the functional and non-functional requirements of the system based on the quality attribute scenarios template proposed by the Carnegie Mellon Software Engineering Institute (SEI). Apart from this, the paper focuses on tracing the functional and non-functional requirements of the system using the concept of requirement traceability matrix

Requirements engineering in software product line engineering

The final publication is available at Springer via http://dx.doi.org/10.1007/s00766-013-0189-0Many attempts have been made to increase the productivity and quality of software products based on software reuse. Software product line practice is one such approach, one that focuses on developing a family of products which have a majority of features in common. Hence, there are numerous requirements that are common across the family, but others are unique to individual products. Traditional requirements engineering methods were conceived to deal with single product requirements and are usually not flexible enough to address the needs arising from reusing requirements for a family of products. There is also the additional burden of correctly identifying and engineering both product-line-wide requirements and product-specific requirements as well as evolving them. Therefore, in this special issue, we want to highlight the importance and the role of requirements engineering for product line development as well as to provide insights into the state of the art in the field.Insfrán Pelozo, CE.; Chastek, G.; Donohoe, P.; Sampaio Do Prado Leite, JC. (2014). Requirements engineering in software product line engineering. Requirements Engineering. 19(4):331-332. doi:10.1007/s00766-013-0189-0S331332194Clements P, Northrop LM (2001) Software product lines: practices and patterns. Addison-Wesley, BostonDerakhshanmanesh M, Fox J, Ebert J (2012) Adopting feature-centric reuse of requirements assets: an industrial experience report. First international workshop on requirements engineering practices on software product line engineering, Salvador, BrazilKuloor C, Eberlein A (2002) Requirements engineering for software product lines, proceedings of the 15th international conference on software and systems engineering and their applications (ICSSEA’02), Paris, FranceNorthrop LM, Clements P (2013) A framework for software product line practice. Software engineering institute. http://www.sei.cmu.edu/productlines/tools/framework/index.cfm . Accessed 22 July 2013Yu Y, Lapouchnian A, Liaskos S, Mylopoulos J, Leite JCSP (2008) From Goals to High-Variability Software Design. Foundations of Intelligent Systems, 17th International Symposium Proceedings. ISMIS 2008. Springer Lecture Notes in Computer Science, 4994: 1–1

Assessment of 3D viewers for the display of interactive documents in the learning of graphic engineering

The purpose of this study is to determine which 3D viewers should be used for the display of interactive graphic engineering documents, so that the visualization and manipulation of 3D models provide useful support to students of industrial engineering (mechanical, organizational, electronic engineering, etc). The technical features of 26 3D visualization software programmes (viewers, publishers, 3D output formats) are examined, to select the three visualization configurations that best meet our needs at the Graphic Expression Department of the University of Burgos (Solidworks plus Solidworks eDrawings; Catia plus Catia eDrawings and 3DXML; several Computer-Aided Design software programmes plus Adobe Acrobat Pro Extended). These are compared using the Quality Function Deployment tool known as House of Quality. The House of Quality has enabled us to identify and quantify the importance attached by engineering teachers to each of their requirements for 3D viewers, and to identify and quantify the technical importance of each of the measurable features of these viewers

Requirements engineering for explainable systems

Information systems are ubiquitous in modern life and are powered by evermore complex algorithms that are often difficult to understand. Moreover, since systems are part of almost every aspect of human life, the quality in interaction and communication between humans and machines has become increasingly important. Hence the importance of explainability as an essential element of human-machine communication; it has also become an important quality requirement for modern information systems. However, dealing with quality requirements has never been a trivial task. To develop quality systems, software professionals have to understand how to transform abstract quality goals into real-world information system solutions. Requirements engineering provides a structured approach that aids software professionals in better comprehending, evaluating, and operationalizing quality requirements. Explainability has recently regained prominence and been acknowledged and established as a quality requirement; however, there is currently no requirements engineering recommendations specifically focused on explainable systems. To fill this gap, this thesis investigated explainability as a quality requirement and how it relates to the information systems context, with an emphasis on requirements engineering. To this end, this thesis proposes two theories that delineate the role of explainability and establish guidelines for the requirements engineering process of explainable systems. These theories are modeled and shaped through five artifacts. These theories and artifacts should help software professionals 1) to communicate and achieve a shared understanding of the concept of explainability; 2) to comprehend how explainability affects system quality and what role it plays; 3) in translating abstract quality goals into design and evaluation strategies; and 4) to shape the software development process for the development of explainable systems. The theories and artifacts were built and evaluated through literature studies, workshops, interviews, and a case study. The findings show that the knowledge made available helps practitioners understand the idea of explainability better, facilitating the creation of explainable systems. These results suggest that the proposed theories and artifacts are plausible, practical, and serve as a strong starting point for further extensions and improvements in the search for high-quality explainable systems

Characterizing the contribution of quality requirements to software sustainability

Most respondents considered modifiability as relevant for addressing both technical and environmental sustainability. Functional correctness, availability, modifiability, interoperability and recoverability favor positively the endurability of software systems. This study has also identified security, satisfaction, and freedom from risk as very good contributors to social sustainability. Satisfaction was also considered by the respondents as a good contributor to economic sustainability. Background Since sustainability became a challenge in software engineering, researchers mainly from requirements engineering and software architecture communities have contributed to defining the basis of the notion of sustainability-aware software. Problem Despite these valuable efforts, the assessment and design based on the notion of sustainability as a software quality is still poorly understood. There is no consensus on which sustainability requirements should be considered. Aim and Method To fill this gap, a survey was designed with a double objective: i) determine to which extent quality requirements contribute to the sustainability of software-intensive systems; and ii) identify direct dependencies among the sustainability dimensions. The survey involved different target audiences (e.g. software architects, ICT practitioners with expertise in Sustainability). We evaluated the perceived importance/relevance of each sustainability dimension, and the perceived usefulness of exploiting a sustainability model in different software engineering activities. Result

Requirements volatility in multicultural situational contexts

Requirements volatility refers to additions, deletions, and modifications of requirements during the system development life cycle. Different approaches in software development, including Agile and DevOps, have addressed requirements volatility by increasing user participation throughout the whole development process. In this paper, we analyse requirements volatility from a situational context angle with the aim to increase understanding of the role of culture and cultural diversity in a multicultural requirements elicitation process. Research on the situational context in Requirements Engineering (RE) is rather limited, despite the recognized importance of RE and requirements elicitation for improving the quality of the final system and software product. This paper builds on an extensive literature review demonstrating the importance of raising awareness and understanding of the role of culture and cultural diversity for requirements volatility, as one of the most significant situational factors in the requirements elicitation process, with the aim to improve the whole systems development process as well as the resulting products and services. The paper concludes with the presentation of the Requirements Cultural Volatility Framework which aims to reveal potential conflicts that may occur in requirements elicitation on a multiplicity of cultural dimensions, The framework proposes actions to be taken in order to address the conflicts and point out expected benefits on each dimension

Lack of Attention to Singular (or Atomic) Requirements Despite Benefits for Quality, Metrics and Management

There are seemingly many advantages to being able to identify, document, test, and trace single or “atomic” requirements. Why then has there been little attention to the topic and no widely used definition or process on how to define atomic requirements? Definitions of requirements and standards focus on user needs, system capabilities or functions; some definitions include making individual requirements singular or without the use of conjunctions. In a few cases there has been a description of atomic system events or requirements. This work is surveyed here although there is no well accepted and used best practice for generating atomic requirements. Due to their importance in software engineering, quality and metrics for requirements have received considerable attention. In the seminal paper on software requirements quality, Davis et al. proposed specific metrics including the “unambiguous quality factor” and the “verifiable quality factor”; these and other metrics work best with a clearly enumerable list of single requirements. Atomic requirements are defined here as a natural language statement that completely describes a single system function, feature, need, or capability, including all information, details, limits, and characteristics. A typical user login screen is used as an example of an atomic requirement which can include both functional and nonfunctional requirements. Individual atomic requirements are supported by a system glossary, references to applicable industry standards, mock ups of the user interface, etc. One way to identify such atomic requirements is from use case or system event analysis. This definition of atomic requirements is still a work in progress and offered to prompt discussion. Atomic requirements allow clear naming or numbering of requirements for traceability, change management, and importance ranking. Further, atomic requirements defined in this manner are suitable for rapid implementation approaches (implementing one requirement at a time), enable good test planning (testing can clearly indicate pass or fail of the whole requirement), and offer other management advantages in project control

Requirements engineering for computer integrated environments in construction

A Computer Integrated Environment (CIE) is the type of innovative integrated information system that helps to reduce fragmentation and enables the stakeholders to collaborate together in business. Researchers have observed that the concept of CIE has been the subject of research for many years but the uptake of this technology has been very limited because of the development of the technology and its effective implementation. Although CIE is very much valued by both industrialists and academics, the answers to the question of how to develop and how to implement it are still not clear. The industrialists and researchers conveyed that networking, collaboration, information sharing and communication will become popular and critical issues in the future, which can be managed through CIE systems. In order for successful development of the technology, successful delivery, and effective implementation of user and industry-oriented CIE systems, requirements engineering seems a key parameter. Therefore, through experiences and lessons learnt in various case studies of CIE systems developments, this book explains the development of a requirements engineering framework specific to the CIE system. The requirements engineering process that has been developed in the research is targeted at computer integrated environments with a particular interest in the construction industry as the implementation field. The key features of the requirements engineering framework are the following: (1) ready-to-use, (2) simple, (3) domain specific, (4) adaptable and (5) systematic, (6) integrated with the legacy systems. The method has three key constructs: i) techniques for requirements development, which includes the requirement elicitation, requirements analysis/modelling and requirements validation, ii) requirements documentation and iii) facilitating the requirements management. It focuses on system development methodologies for the human driven ICT solutions that provide communication, collaboration, information sharing and exchange through computer integrated environments for professionals situated in discrete locations but working in a multidisciplinary and interdisciplinary environment. The overview for each chapter of the book is as follows; Chapter 1 provides an overview by setting the scene and presents the issues involved in requirements engineering and CIE (Computer Integrated Environments). Furthermore, it makes an introduction to the necessity for requirements engineering for CIE system development, experiences and lessons learnt cumulatively from CIE systems developments that the authors have been involved in, and the process of the development of an ideal requirements engineering framework for CIE systems development, based on the experiences and lessons learnt from the multi-case studies. Chapter 2 aims at building up contextual knowledge to acquire a deeper understanding of the topic area. This includes a detailed definition of the requirements engineering discipline and the importance and principles of requirements engineering and its process. In addition, state of the art techniques and approaches, including contextual design approach, the use case modelling, and the agile requirements engineering processes, are explained to provide contextual knowledge and understanding about requirements engineering to the readers. After building contextual knowledge and understanding about requirements engineering in chapter 2, chapter 3 attempts to identify a scope and contextual knowledge and understanding about computer integrated environments and Building Information Modelling (BIM). In doing so, previous experiences of the authors about systems developments for computer integrated environments are explained in detail as the CIE/BIM case studies. In the light of contextual knowledge gained about requirements engineering in chapter 2, in order to realize the critical necessity of requirements engineering to combine technology, process and people issues in the right balance, chapter 4 will critically evaluate the requirements engineering activities of CIE systems developments that are explained in chapter 3. Furthermore, to support the necessity of requirements engineering for human centred CIE systems development, the findings from semi-structured interviews are shown in a concept map that is also explained in this chapter. In chapter 5, requirements engineering is investigated from different angles to pick up the key issues from discrete research studies and practice such as traceability through process and product modelling, goal-oriented requirements engineering, the essential and incidental complexities in requirements models, the measurability of quality requirements, the fundamentals of requirements engineering, identifying and involving the stakeholders, reconciling software requirements and system architectures and barriers to the industrial uptake of requirements engineering. In addition, a comprehensive research study measuring the success of requirements engineering processes through a set of evaluation criteria is introduced. Finally, the key issues and the criteria are comparatively analyzed and evaluated in order to match each other and confirm the validity of the criteria for the evaluation and assessment of the requirements engineering implementation in the CIE case study projects in chapter 7 and the key issues will be used in chapter 9 to support the CMM (Capability Maturity Model) for acceptance and wider implications of the requirements engineering framework to be proposed in chapter 8. Chapter 6 explains and particularly focuses on how the requirements engineering activities in the case study projects were handled by highlighting strengths and weaknesses. This will also include the experiences and lessons learnt from these system development practices. The findings from these developments will also be utilized to support the justification of the necessity of a requirements engineering framework for the CIE systems developments. In particular, the following are addressed. • common and shared understanding in requirements engineering efforts, • continuous improvement, • outputs of requirement engineering • reflections and the critical analysis of the requirements engineering approaches in these practices. The premise of chapter 7 is to evaluate and assess the requirements engineering approaches in the CIE case study developments from multiple viewpoints in order to find out the strengths and the weaknesses in these requirements engineering processes. This evaluation will be mainly based on the set of criteria developed by the researchers and developers in the requirements engineering community in order to measure the success rate of the requirements engineering techniques after their implementation in the various system development projects. This set of criteria has already been introduced in chapter 5. This critical assessment includes conducting a questionnaire based survey and descriptive statistical analysis. In chapter 8, the requirements engineering techniques tested in the CIE case study developments are composed and compiled into a requirements engineering process in the light of the strengths and the weaknesses identified in the previous chapter through benchmarking with a Capability Maturity Model (CMM) to ensure that it has the required level of maturity for implementation in the CIE systems developments. As a result of this chapter, a framework for a generic requirements engineering process for CIE systems development will be proposed. In chapter 9, the authors will discuss the acceptance and the wider implications of the proposed framework of requirements engineering process using the CMM from chapter 8 and the key issues from chapter 5. Chapter 10 is the concluding chapter and it summarizes the findings and brings the book to a close with recommendations for the implementation of the Proposed RE framework and also prescribes a guideline as a way forward for better implementation of requirements engineering for successful developments of the CIE systems in the future

A View of the Cardiovascular Device Industry

This record of study details the experience and the knowledge applied by an engineering doctoral candidate during two internships with two separate organizations in the cardiovascular device industry. The first internship was with an early startup company with a large focus in early research and design. The second was in a more mature organization with a focus in process control and increasing efficiencies. The startup company provided the appropriate dynamic for applying engineering design methods such as generating customer requirements, generating product functional requirements, building a quality function deployment, and proposing a basic high level design approach. With the mature company the focus was on investigating procedural inefficiencies through root cause analysis and mitigating the inefficiencies through integrated software solutions. The detailed accounts of these experiences provide a broad overview of the many challenges facing the cardiovascular device industry and the organizations involved. These accounts also illustrate the importance and value of engineering design principles and systems based engineering management in the industry