Book

Requirements Engineering for Software and Systems

Authors:

Abstract

As requirements engineering continues to be recognized as the key to on-time and on-budget delivery of software and systems projects, many engineering programs have made requirements engineering mandatory in their curriculum. In addition, the wealth of new software tools that have recently emerged is empowering practicing engineers to improve their requirements engineering habits. However, these tools are not easy to use without appropriate training. Filling this need, Requirements Engineering for Software and Systems, Second Edition has been vastly updated and expanded to include about 30 percent new material. In addition to new exercises and updated references in every chapter, this edition updates all chapters with the latest applied research and industry practices. It also presents new material derived from the experiences of professors who have used the text in their classrooms. Improvements to this edition include: • An expanded introductory chapter with extensive discussions on requirements analysis, agreement, and consolidation • An expanded chapter on requirements engineering for Agile methodologies • An expanded chapter on formal methods with new examples • An expanded section on requirements traceability • An updated and expanded section on requirements engineering tools • New exercises including ones suitable for research projects Following in the footsteps of its bestselling predecessor, the text illustrates key ideas associated with requirements engineering using extensive case studies and three common example systems: an airline baggage handling system, a point-of-sale system for a large pet store chain, and a system for a smart home. This edition also includes an example of a wet well pumping system for a wastewater treatment station. With a focus on software-intensive systems, but highly applicable to non-software systems, this text provides a probing and comprehensive review of recent developments in requirements engineering in high integrity systems.
... Requirements engineering (RE) encompasses various activities, which together lead to the production of quality software products [1]. RE is defined as the branch of engineering, which focuses on the real-world goals functionality, and constraints of systems and their relationship to the system-specific behavior, evolution, and family of the related system [2]. In RE, a requirements engineer can be assigned to any of the following activities: i) requirements elicitation/discovery, ii) requirements analysis and reconciliation, iii) requirements representation/modeling, iv) requirements verification and validation, or v) requirements management [1], [2]. ...
... RE is defined as the branch of engineering, which focuses on the real-world goals functionality, and constraints of systems and their relationship to the system-specific behavior, evolution, and family of the related system [2]. In RE, a requirements engineer can be assigned to any of the following activities: i) requirements elicitation/discovery, ii) requirements analysis and reconciliation, iii) requirements representation/modeling, iv) requirements verification and validation, or v) requirements management [1], [2]. This means that a requirements engineer is expected to perform several roles in software engineering such as system analyst, business system analyst, requirements analyst, functional architect, and software engineer [2], [3]. ...
... In RE, a requirements engineer can be assigned to any of the following activities: i) requirements elicitation/discovery, ii) requirements analysis and reconciliation, iii) requirements representation/modeling, iv) requirements verification and validation, or v) requirements management [1], [2]. This means that a requirements engineer is expected to perform several roles in software engineering such as system analyst, business system analyst, requirements analyst, functional architect, and software engineer [2], [3]. Thus, the scope of this research considers the 3245 requirements engineer to be information technology (IT) professionals who are described as either system analysts, requirements analysts, or software engineers. ...
Article
Full-text available
span lang="EN-US">Requirements engineers play an important role in the development of software products and services. The nature of requirements engineering (RE) is multifaceted and influences the quality, success, or failure of software products. In gathering software requirements, engineers commonly work in a team, particularly when dealing with the customers or modeling the requirements, hence the team behavior may influence the RE activities. The investigation of requirements engineers’ personality and their team behavior associated with RE activities is still an open area in which research is still developing. This study aims to investigate the personality and team behavior of requirements engineers involved in RE activities using a systematic literature review approach. We included 64 primary studies that addressed the association between personality and team behavior of requirements engineers on the effectiveness of RE activities. The result shows that among personality dimensions, extraversion and conscientiousness were found to be the predominant personality traits that positively affect RE activities. Furthermore, team behavior of requirements engineers such as flexibility, collaboration, creativity, innovation, and norms were discovered as factors that influence the RE process, performance, and success. The findings of this study contribute to the body of knowledge and practice of RE by providing empirical evidence on the influence of requirements engineers’ personality and team behavior on the effectiveness of RE activities.</span
... 1 End Users Shukla & Auriol, 2013;Lim et al., 2013;Hujainah et al., 2018); Pohl & Rupp, 2015); Hull et al., 2011;Chemuturi, 2013;Wiegers, 2009); Wieringa, 1996;Laplante, 2017;Sommerville, 2016) 1 Developers Kaiya et al., 2005;Bendjenna et al., 2012); Heikkila et al., 2015;Lim et al., 2013;Hujainah et al., 2018;Sadiq & Jain, 2013;Pohl & Rupp, 2015;Chemuturi, 2013;Wiegers, 2009;Wieringa, 1996 Hujainah et al., 2018;Hull et al., 2011;Sommerville, 2016 5 Requirements analysts Dos Santos et al., 2016;Hujainah et al., 2018;Wiegers, 2009 6 Financial Representatives Sadiq & Jain, 2013;6 Programmers Hujainah et al., 2018Wieringa, 1996;Laplante, 2017 7 Maintenance and service staff Hull et al., 2011;Laplante, 2017 7 Project managers Heikkila et al., 2015;Hujainah et al., 2018;Kukreja et al., 2012;Wiegers, 2009;Wieringa, 1996 8 Sales and Marketing Hujainah et al., 2018;Hull et al., 2011;Chemuturi, 2013;Wiegers, 2009 8 Business Engineer Hujainah et al., 20189 Government Hull et al., 2011Laplante, 20179 Testers Pohl & Rupp, 2015Wiegers, 2009 10 Organizational Standards Group Hull et al., 2011;Laplante, 2017 ...
... 1 End Users Shukla & Auriol, 2013;Lim et al., 2013;Hujainah et al., 2018); Pohl & Rupp, 2015); Hull et al., 2011;Chemuturi, 2013;Wiegers, 2009); Wieringa, 1996;Laplante, 2017;Sommerville, 2016) 1 Developers Kaiya et al., 2005;Bendjenna et al., 2012); Heikkila et al., 2015;Lim et al., 2013;Hujainah et al., 2018;Sadiq & Jain, 2013;Pohl & Rupp, 2015;Chemuturi, 2013;Wiegers, 2009;Wieringa, 1996 Hujainah et al., 2018;Hull et al., 2011;Sommerville, 2016 5 Requirements analysts Dos Santos et al., 2016;Hujainah et al., 2018;Wiegers, 2009 6 Financial Representatives Sadiq & Jain, 2013;6 Programmers Hujainah et al., 2018Wieringa, 1996;Laplante, 2017 7 Maintenance and service staff Hull et al., 2011;Laplante, 2017 7 Project managers Heikkila et al., 2015;Hujainah et al., 2018;Kukreja et al., 2012;Wiegers, 2009;Wieringa, 1996 8 Sales and Marketing Hujainah et al., 2018;Hull et al., 2011;Chemuturi, 2013;Wiegers, 2009 8 Business Engineer Hujainah et al., 20189 Government Hull et al., 2011Laplante, 20179 Testers Pohl & Rupp, 2015Wiegers, 2009 10 Organizational Standards Group Hull et al., 2011;Laplante, 2017 ...
... 1 End Users Shukla & Auriol, 2013;Lim et al., 2013;Hujainah et al., 2018); Pohl & Rupp, 2015); Hull et al., 2011;Chemuturi, 2013;Wiegers, 2009); Wieringa, 1996;Laplante, 2017;Sommerville, 2016) 1 Developers Kaiya et al., 2005;Bendjenna et al., 2012); Heikkila et al., 2015;Lim et al., 2013;Hujainah et al., 2018;Sadiq & Jain, 2013;Pohl & Rupp, 2015;Chemuturi, 2013;Wiegers, 2009;Wieringa, 1996 Hujainah et al., 2018;Hull et al., 2011;Sommerville, 2016 5 Requirements analysts Dos Santos et al., 2016;Hujainah et al., 2018;Wiegers, 2009 6 Financial Representatives Sadiq & Jain, 2013;6 Programmers Hujainah et al., 2018Wieringa, 1996;Laplante, 2017 7 Maintenance and service staff Hull et al., 2011;Laplante, 2017 7 Project managers Heikkila et al., 2015;Hujainah et al., 2018;Kukreja et al., 2012;Wiegers, 2009;Wieringa, 1996 8 Sales and Marketing Hujainah et al., 2018;Hull et al., 2011;Chemuturi, 2013;Wiegers, 2009 8 Business Engineer Hujainah et al., 20189 Government Hull et al., 2011Laplante, 20179 Testers Pohl & Rupp, 2015Wiegers, 2009 10 Organizational Standards Group Hull et al., 2011;Laplante, 2017 ...
Article
The attributes or criteria used in the requirements prioritization process become an essential reference in calculating priorities. Most of the techniques are used to increase the value impacting business success. On the contrary, there are limitations on cost, time, and resources for developing software. Therefore, the requirements prioritization process often requires collaboration from the perspectives involved. So far, the pattern and basis have not been seen in the criteria used in the requirements prioritization process. Consequently, there need to be other factors that become a reference so that the selection of criteria is appropriate. This study identifies criteria based on the categorized perspectives of requirements prioritization. A systematic literature review presents criteria for prioritizing requirements from multiple collaborative perspectives. Findings show that the criteria in requirements prioritization can be classified into beneficial and non-beneficial, where business value and development cost are the most frequently used criteria. Furthermore, the involvement of multiple perspectives in requirements prioritization focuses on the client’s and developer’s perspectives. The findings also reveal that some of the challenges in the requirements prioritization process are biases by stakeholders, reducing pairwise comparison, and scalability. In the future, it will be investigated whether the selection of criteria correlated with stakeholder perspectives will increase the accuracy of priorities. Thus, the contribution of this paper is to recommend criteria from stakeholders’ perspectives.
... Requirements engineering is part of engineering and focuses on the actual goals, functions, and constraints of a system [27]. It is the process of eliciting, analyzing, specifying, validating, and maintaining the requirements of a system [12,27]. ...
... Requirements engineering is part of engineering and focuses on the actual goals, functions, and constraints of a system [27]. It is the process of eliciting, analyzing, specifying, validating, and maintaining the requirements of a system [12,27]. It entails identifying stakeholders' needs; recognizing the context of the requirements; representing those requirements in an easily understandable manner; and negotiating, validating, documenting, and managing those requirements. ...
... Requirements engineering encompasses many sub-processes. The major five sub-processes are requirements elicitation, requirements analysis and negotiation, requirements specification, requirements validation, and requirements management [27][28][29][30][31]. ...
Article
Full-text available
Context: Ethics have broad applications in different fields of study and different contexts. Like other fields of study, ethics have a significant impact on the decisions made in computing concerning software artifact production and its processes. Hence, in this research, ethics is considered in the context of requirements engineering during the software development process. Objective: The aim of this paper is to discuss the investigation results regarding ethical problems of requirements engineering processes by taking sample software developing companies and exposing existing research gaps. Method: This research uses interviewing, focus group discussions, purposive sampling, and qualitative analysis research methods. Result: This research finds an absence of industry practices, professional responsibility code of conduct standards, and other guidelines within companies when integrating ethical concerns of software during requirements engineering. It also indicates that almost all companies have no identification methods and checking mechanisms for ethical concern considerations. Furthermore, the major identified ethical concerns are classified into six categories as requirements identification problems, quality-related problems, carrying out unpermitted activities, unwillingness to give requirements, knowledge gaps and lack of legal grounds/rules for accountability. Conclusion: From the findings of this research, it can be concluded that, in the case software companies, there is no specific method for identifying ethical concerns. Additionally, there are no standards and guidelines used within the companies. This implies the need to overcome the existing and emerging ethical issues of requirements engineering.
... In the beginning there are requirements: every software project starts with the elicitation, documentation and analysis of requirements (Van Lamsweerde, 2001;Macaulay, 2012;Laplante, 2017). As time is an important property in most systems, requirements for software systems frequently contain temporal aspects: from precedence relationships between activities or events to hard real-time thresholds between the detection of events to effectiveness of a reaction. ...
... More complex temporal requirements, like the one sketched above: either in natural language, in some form of general constraint language, in temporal logic. For systems with hard real-time requirements, different forms of representation of temporal constraints in temporal logics of varying levels of expressiveness and complexity are part of formal specification systems (Van Lamsweerde, 2001;Laplante, 2017). These languages typically require expert's training to use and comprehend. ...
... How can we check them, e.g., for contradictions, like we check other requirements formally? There is surprisingly little to be found apart from specialised approaches for (hard) real-time systems (Koymans, 1990;Maler et al., 2005) and general references to temporal logic (Alur and Henzinger, 1994;Van Lamsweerde, 2001;Laplante, 2017) and various forms of temporal automata these logics are mapped to (Wolper, 2000;Zhou et al., 2016). ...
... In the beginning there are requirements: every software project starts with the elicitation, documentation and analysis of requirements (Van Lamsweerde, 2001;Macaulay, 2012;Laplante, 2017). As time is an important property in most systems, requirements for software systems frequently contain temporal aspects: from precedence relationships between activities or events to hard real-time thresholds between the detection of events to effectiveness of a reaction. ...
... More complex temporal requirements, like the one sketched above: either in natural language, in some form of general constraint language, in temporal logic. For systems with hard real-time requirements, different forms of representation of temporal constraints in temporal logics of varying levels of expressiveness and complexity are part of formal specification systems (Van Lamsweerde, 2001;Laplante, 2017). These languages typically require expert's training to use and comprehend. ...
... How can we check them, e.g., for contradictions, like we check other requirements formally? There is surprisingly little to be found apart from specialised approaches for (hard) real-time systems (Koymans, 1990;Maler et al., 2005) and general references to temporal logic (Alur and Henzinger, 1994;Van Lamsweerde, 2001;Laplante, 2017) and various forms of temporal automata these logics are mapped to (Wolper, 2000;Zhou et al., 2016). ...
... Sani Umar g201706410@kfupm.edu.sa 1 Department of Information and Computer Science, KFUPM, Dhahran, Saudi Arabia (in the case the system being built is not for sale), all technical persons (e.g., development, test, maintenance, etc.), regulators (e.g., government agencies), and third parties who have interest in the system. It is worth noting that sometimes the customer is called the client (usually in the case of software systems) [3]. In this paper, the terms 'client' and 'customer' are used interchangeably. ...
... 2. A collection and an analysis of RE challenges faced by software practitioners with respect to organizations size and the proficiency of software practitioners. 3. Conducting a comparative analysis of the RE challenges faced in both worlds, academia and industry. ...
... 2. Collect RE challenges using questionnaires and interviews [5,[20][21][22][32][33][34]34,35]. 3. Identify RE challenges through the use of case studies [15][16][17][18][19]. ...
Article
Full-text available
Requirement engineering (RE) is the process of discovering stakeholders’ requirements and needs and documenting them in such a way that they can serve as the basis for all other system development activities. Despite recent advances in RE practices and tools, requirements engineers are still experiencing fundamental problems. Therefore, the identification and characterization of such challenges would help RE practitioners manage and overcome such difficulties allowing them to meet expected quality objectives. The main objective of this paper is to identify and compare RE challenges reported in the literature and in practice. To this aim, we have conducted a systematic mapping study to collect and analyze RE challenges in the literature. Furthermore, we have also conducted a questionnaire-based empirical investigation to collect and analyze RE challenges faced by IT practitioners working for 15 companies located in four different countries. Results show that the top challenges are the same in the literature and in practice. However, overall, our comparative study revealed a weak positive correlation between RE challenges in the literature and in practice (Spearman coefficient = 0.3061). This weak positive relationship indicates that some of the challenges found in the literature are not perceived by the participant to have a great impact on the practice. This may be due to the fact that solutions to (or guidelines to avoid) some of the identified challenges have been provided by the surveyed corporations.
... Due to the multiple actor interactions in the distributed ecosystem, functional and non-functional requirements are identified. The RE process comprises a set of activities to create consensus among stakeholders and establish a requirements document that satisfies stakeholder requirements [58]. Requirements elicitation focusses on constructing a model that derives its functions from earlier non-blockchain based SLV work, for example the MBM. ...
... Non-functional requirements, and public key cryptography, which lies at the heart of the core functions of ReSOLV. Laplante [58] states that the first requirement for development of a new system, is to develop a concise description of what it is supposed to do. Thus, the purpose of ReSOLV is to provide Software Piracy Prevention and Provenance (SPPP), using blockchain technology to validate user license entitlements, and to validate software integrity. ...
Preprint
Full-text available
This paper presents a method for a decentralised peer-to-peer software license validation system using cryptocurrency blockchain technology to ameliorate software piracy, and to provide a mechanism for software developers to protect copyrighted works. Protecting software copyright has been an issue since the late 1970's and software license validation has been a primary method employed in an attempt to minimise software piracy and protect software copyright. The method described creates an ecosystem in which the rights and privileges of participants are observed.
... SDLC Stages I Requirement Engineering: As the most important part of designing any software system [29], this involves requirement elicitation, requirement gathering, management and validation. According to Laplante [18] quoting another author known as Zave, "Requirement engineering is the branch of software engineering concerned with the real-world goals for, functions of, and constraints on software systems. It is also concerned with the relationship of these factors to precise specifications of software behaviour, and to their evolution over time and across software families.". ...
Thesis
Full-text available
Artificial Intelligence, in general, and especially its subfield, Natural language Processing (NLP), has made unrivalled progress recently in many areas of life, automating and enabling a lot of activities such as speech recognition, language translations, search engines (including text and image searches), text-generations, among others. Software engineering and Software Development Life Cycle (SDLC) is also not left out. Indeed, one of the most critical starting points of SDLC is the requirement engineering stage which, traditionally, has been dominated by business analysts. Unfortunately, these business analysts have always done the job not just in a monotonous way, but also in an error prone, tedious, time-consuming, resource-intensive, and inefficient manner, thus leading to poorly crafted works with lots of requirement creep and sometimes technical debts. This work, as a continuation of previous Requirement Engineering study focusing on classification of Functional and Non-functional Requirements, reviews both traditional SDLC and the latest techniques in Artificial Intelligence and NLP with emphasis on Requirement Engineering, Transformer, LLMs in general and BERT (Bidirectional Encoder Representations from Transformers) in particular. Some of the discussions are backed by previous experiments.
... Each requirement describes either what the system to be developed is expected to perform or any constraints on the system design and development (e.g., quality and platform constraints). Requirements engineering has been proposed as a branch of software engineering that promotes the application of well-known techniques, practices and methods for eliciting, documenting, and analysing requirements [4][5][6][7]. With requirements engineering, the goal is to maximise the quality of requirements that will affect the subsequent stages of software development. ...
Article
Full-text available
Many requirements engineering tools have been developed for gathering, documenting, and tracing requirements that can even be further processed for such purposes as analysis and transformation. In this study, we analysed 56 different requirements engineering tools for a comprehensive set of features that are categorised into multiple viewpoints (i.e., project management, specification, collaboration, customisation, interoperability, methodology, and user-support). The analysis results led to many interesting findings. Some of them are as follows: (i) the project planning and execution activities are rarely supported, (ii) multi-user access and versioning are highly supported, (iii) the most popular specification technique is natural languages, while precise specification via modeling languages is rarely supported, (iv) requirements analysis is rarely supported, (v) requirements transformation is considered for generating documents only, (vi) tool customisation via the tool integration and API support is highly popular, while customising the notation set is rarely supported, (vii) exchanging requirements is popular in such standards as ReqIF and Excel/CSV, while no single standard is accepted by all the tools, (viii) agile development is very common, while other methodologies (e.g., MDE and SPLE) are rarely supported, and (ix) user-guides, telephone, e-mail, and videos are the most preferred methods for user-support. The analysis results will be useful for different stakeholders including practitioners, tool vendors, and researchers.
... Each requirement describes either what the system to be developed is expected to perform or any constraints on the system design and development (e.g., quality and platform constraints). Requirements engineering has been proposed as the branch of software engineering, which promotes the application of well-known techniques, practices and methods for eliciting, documenting, and analysing requirements [4][5][6][7]. With requirements engineering, the goal is to maximise the quality of the requirements that will affect all subsequent stages of software development. ...
Preprint
Full-text available
Many requirements engineering tools have been existing for gathering, documenting and tracing requirements that can even be further processed for such purposes as analysis and transformation. In this study, we analysed 56 different requirements engineering tools for a comprehensive set of features that are categorised into multiple viewpoints (i.e., project management, specification, collaboration, customisation, interoperability, methodology, knowledge management). The analysis results led to many interesting findings. Some of them are as follows: (i) the project planning and execution activities are rarely supported, (ii) multi-user access and versioning are highly supported, (iii) the top-popular specification technique is natural languages, while precise specification via modeling languages is rarely supported, (iv) requirements analysis is rarely supported, (v) requirements transformation is considered for generating documents only, (vi) tool customisation via the tool integration and API support is highly popular, while customising the notation set is rarely supported, (vii) exchanging requirements is popular in such standards as ReqIF and Excel/CSV, while no single standard are accepted by all the tools, (viii agile development is very common, while other methodologies (e.g., MDE and SPLE) are rarely supported, and (viii) user-guide, telephone, e-mail, videos are the top methods for sharing knowledge. The analysis results will be useful for different stakeholders including practitioners, tool vendors and researchers.
... It's rare to have a back-up for a document like this. At Jenderal Soedirman University, there are no facilities that can be used in the preparation of higher education accreditation instruments, while the need for accreditation data is very much needed by the academic community of General Sudirman University in the preparation of university accreditation instruments and study programs so that they are still experiencing difficulties in archiving and presenting form data information, By utilizing information technology in the application of computer-based applications for archiving and presenting accreditation data needs, it is hoped that it can help the academic community more quickly and precisely in processing accreditation instrument data [3][4][5][6]. It is hoped that with the development of archiving applications and the presentation of accreditation instruments with the completion of the System Development Lyfe Cycle (SDLC) method in the problem analysis stage, the applications built can improve the quality of filling out accreditation instruments in data processing that is well integrated and can be utilized at any time by the academic community of the Lancang kuning university. ...
Article
Full-text available
See the retraction notice E3S Web of Conferences 420, 00001 (2023), https://doi.org/10.1051/e3sconf/202342000001
... The requirements for this study's purpose are defined in an exploration of the body of evidence. This study adopts Laplante (2017) general framework with functional, non-functional, and domain requirements. The aim is to define high-level requirements for BD systems. ...
... There have been various attempts to defining and classifying software and system requirements. For the purposes of this study, we opted for a well-received approach discussed by Laplante [31]. In this approach, requirements are classified into three major types of (1) functional requirements, (2) non-functional requirements, and (3) domain requirements. ...
Article
Full-text available
The panorama of data is ever evolving, and big data has emerged to become one of the most hyped terms in the industry. Today, users are the perpetual producers of data that if gleaned and crunched, have the potential to reveal game-changing patterns. This has introduced an important shift regarding the role of data in organizations and many strive to harness to power of this new material. Howbeit, institutionalizing data is not an easy task and requires the absorption of a great deal of complexity. According to the literature, it is estimated that only 13% of organizations succeeded in delivering on their data strategy. Among the root challenges, big data system development and data architecture are prominent. To this end, this study aims to facilitate data architecture and big data system development by applying well-established patterns of microservices architecture to big data systems. This objective is achieved by two systematic literature reviews, and infusion of results through thematic synthesis. The result of this work is a series of theories that explicates how microservices patterns could be useful for big data systems. These theories are then validated through expert opinion gathering with 7 experts from the industry. The findings emerged from this study indicates that big data architectures can benefit from many principles and patterns of microservices architecture.
... Requirement Validation Phase is a method of determining if the specification is a precise representation of the customers' need. Validation responds to the question, "Am I building the right product?" (Laplante, 2013). According to Raja (2009), the process of requirement validation confirms that, the requirements in SRS are complete and consistent. ...
Article
Full-text available
Requirement traceability (RT) is one of the critical activity of good requirements management and an important part of development projects. At the same time, it improves the quality of software products. Nevertheless, industrial practitioners are challenged by this lack of guidance or results which serve as a rule or guide in establishing effective traceability in their projects. The outcome of this is that practitioners are ill-informed as to the best or most efficient means of accomplishing their tasks, such as found in software companies. Notwithstanding the lack of guidance, there are a number of commonly accepted practices which can guide industrial practitioners with respect to trace the requirements in their projects. This study aims to determine the practices of RT through conducting a systematic literature review. Also, this study conducted a survey for investigating the use of RT practices in the software companies at northern region of Malaysia. Finally, a series of interviews with practitioners were carried out to know the reasons that influence on the use of these practices in software development. The findings showed that majority software companies do not use traceability practices for tracing requirements due to financial issues and the lack of knowledge of these practices. This study presented empirical evidence about the use of RT practices among software companies. Thus, the findings of this study can assist practitioners to select RT practices, and also enables researchers to find gaps and pointers for future study in this study domain.
... Fernandes and Machado [6] have defined a generic requirements elicitation process as one consisting of the following steps: 1) Study the domain of interest; 2) Identify the requirements sources; 3) Consult and engage stakeholders; 4) Select the techniques to be applied for elicitation; and 5) Elicit the requirements from the stakeholders and other identified sources. Analysing domain specific knowledge helps identify essential, as well as missing, functionality [7]. Furthermore, this mapping can inform the design process with potential user requirements [8]. ...
Conference Paper
Full-text available
The H2020 MOSES project aims to significantly enhance the short sea shipping component of the European supply chain by developing the following innovations: an Innovative Feeder vessel outfitted with a Robotic Container-Handling System, an Autonomous Tugboat swarm that cooperates with an Automated Mooring System, and a Digital Matchmaking and Logistics Collaboration Platform. Towards this goal, the MOSES project implements a user-driven development approach that aims to ensure that the systems are designed to satisfy actual stakeholder needs. This paper aims to comprehensively map the needs of the MOSES stakeholders and translate them into formally structured user requirements for each innovation, which will be used at a later stage of development to determine system requirements and specifications. The employed MOSES User Requirements Extraction Methodology includes determining key design goals, identifying the stakeholder categories that affect the future operation of the MOSES innovations, eliciting stakeholder needs from the results of an online survey and two stakeholder workshops. The results show that the MOSES stakeholders focus on environmental impact, safety of automated and autonomous functionalities, and operational flexibility and dependability. Based on the identified needs, this paper documents essential requirements that determine the main functionalities of the MOSES innovations and relate to the project's broad objectives. These requirements provide the basis for elaborating the qualities and performance characteristics of the innovations at a later stage of development.
... Also likely relevant is information regarding the decision-making processes or systems that ADM will subsume or replace. Information from business analysis or requirements engineering activities, common for many organisational technology undertakings [42], will often be pertinent, as will any documents such as minutes from board meetings, consultancy reports, and so on that involve discussions or decisions about the nature of the proposed system. 4.1.2 ...
Preprint
Full-text available
This paper introduces reviewability as a framework for improving the accountability of automated and algorithmic decision-making (ADM) involving machine learning. We draw on an understanding of ADM as a socio-technical process involving both human and technical elements, beginning before a decision is made and extending beyond the decision itself. While explanations and other model-centric mechanisms may assist some accountability concerns, they often provide insufficient information of these broader ADM processes for regulatory oversight and assessments of legal compliance. Reviewability involves breaking down the ADM process into technical and organisational elements to provide a systematic framework for determining the contextually appropriate record-keeping mechanisms to facilitate meaningful review - both of individual decisions and of the process as a whole. We argue that a reviewability framework, drawing on administrative law's approach to reviewing human decision-making, offers a practical way forward towards more a more holistic and legally-relevant form of accountability for ADM.
... The system should meet both user requirements and business needs. These requirements should be flexible according to the business needs [10]. In PHCS, two types of requirements should be taken into account: the first type is functional requirements which mean what is the system you want to do? ...
Article
Full-text available
With the massive success of electronic health care applications and with emerging technologies in the areas of telecommunications which are widely used in healthcare sector, a reliable system to serve Pet Owners and Veterinarians will be designed and implemented in this paper. Pet's medical condition should be evaluated by a veterinarian before any medical decisions will be implemented. The proposed system, Pet Health Care System (PHCS), will be helpful to the specialists in the field of Veterinary Health Care. It centralizes database which contains the pet records. The system will enable the Vet to access the database and show the pet details to diagnose their medical condition and write the required treatment. PHCS is considered an efficient system to reduce healthcare costs and provide the time. It offers veterinarians an exciting way to make the service of pets owners more better. It helps the Owners of the unhealthy Pets to have more accurate information about the date of their pets' pathological status.
... Since there is a clear commonality across the entire software engineering requirements and systems engineering requirements processes, the integration of the two courses was expected to occur without major barriers. Reputed software engineering academics also acknowledged this commonality and referenced it widely in literature [8] . The Embry-Riddle Aeronautical University Graduate Catalog course descriptions of the two courses are presented in Appendix A. ...
Article
Full-text available
The automotive industry is experiencing a surge in system complexity driven by the ever-growing number of interacting components, subsystems, and control systems. This complexity is further amplified by the expanding range of component options available to original equipment manufacturers (OEMs). OEMs work in parallel on more than one vehicle model, with multiple vehicle variants for each vehicle model. With the increasing number of vehicle variants needed to cater to diverse regional needs, development complexity escalates. To address this challenge, modern techniques like Model-Based Systems Engineering (MBSE), digitalization, and Artificial Intelligence (AI) are becoming essential tools. These advancements can streamline concept development, optimize thermal and HVAC system design across variants, and accelerate the time-to-market for next-generation EVs. The development of battery electric vehicles (BEVs) needs a strong focus on thermal management systems (TMSs) and heating, ventilation, and air conditioning (HVAC) systems. These systems play a critical role in maintaining optimal battery temperature, maximizing range and efficiency, and ensuring passenger comfort. This article proposes a digital prototype (DP) and AI-based methodology to specify BEV thermal system and HVAC system components in the concept phase. This methodology uses system and variant thinking in combination with digital prototype (DP) and AI to verify BEV thermal system architecture component specifications for future variants without extensive simulation. A BEV cabin cooling requirement of 22 °C to be achieved within 1800s at a high ambient temperature (45 °C) is required, and its verification is used to prove this methodology.
Chapter
The automotive industry faces radical changes induced by new and potentially disruptive technologies emerging from digital transformation. At the same time, the increased demand for energy efficiency, CO2 neutrality, autonomous driving, connectivity, and artificial intelligence is leading to fundamentally new business models. These new business models also open up opportunities for new market entrants. Global competition is also further increasing pressure on the players. This chapter focuses on selected systems engineering methods and tools that support activities throughout the automotive development process. They provide the required functionality to author, modify and manage the results of systems engineering, and adhere to positive user experience fostering user acceptance and tool adoption in daily work. Through systematic use of systems engineering methods and tools, omissions and false assumptions caused by complexity can be identified early, so that their impact can be minimized. The constant change in artifacts is traced and managed through the systems engineering project lifecycle.
Article
Full-text available
Digital technologies affect all areas and activities of society. Accounting is no exception to this trend, as organizational information system accounting increasingly integrates digital technologies. The paper aims to study the integration of ethical requirements with the quality requirements in implementing digital technologies based on artificial intelligence, blockchain, the internet of things, and cloud computing in financial and managerial accounting. This empirical study of 396 accountants from Romanian organizations involves investigating the influence of ethical and quality requirements of digital technologies on the perception of users’ satisfaction in financial and managerial accounting. Empirical research encompasses a quantitative approach using structural equation modeling and artificial neural network analysis in a two-stage procedure. Some of the existing ethical issues can be addressed by implementing new digital technologies but implementing these emerging technologies can generate other ethical and quality issues that accounting and IT professionals must address in a combined effort. The research results show that the ethical requirements that influence the perception of financial and managerial accounting are security and trust. Among the quality requirements, the most critical influence in the perception of accountants is reliability.
Chapter
One of the most important phases in software development projects is the validation of requirements. Erroneous requirements, if not detected on time, can cause problems, such as additional costs, failure to meet expected objectives and delays in delivery. For these reasons, it is beneficial to invest efforts to this task. This paper aims to identify best practices that can help to carry out the Requirements Validation process. The best practices are determined by the analysis of software requirements validation approaches proposed in recent years, in order to evaluate their characteristics with the “Way-of” framework and the reference model for technical reviews.
Article
Full-text available
Functional requirements on a software system are traditionally captured as text that describes the expected functionality in the domain of a real-world system. Natural language processing methods allow us to extract the knowledge from such requirements and transform it, e.g., into a model. Moreover, these methods can improve the quality of the requirements, which usually suffer from ambiguity, incompleteness, and inconsistency. This paper presents a novel approach to using natural language processing. We use the method of grammatical inspection to find specific patterns in the description of functional requirement specifications (written in English). Then, we transform the requirements into a model of Normalized Systems elements. This may realize a possible component of the eagerly awaited text-to-software pipeline. The input of this method is represented by textual requirements. Its output is a running prototype of an information system created using Normalized Systems (NS) techniques. Therefore, the system is ready to accept further enhancements, e.g., custom code fragments, in an evolvable manner ensured by compliance with the NS principles. A demonstration of pipeline implementation is also included in this paper. The text processing part of our pipeline extends the existing pipeline implemented in our system TEMOS, where we propose and implement methods of checking the quality of textual requirements concerning ambiguity, incompleteness, and inconsistency.
Article
Full-text available
Requirements are the basis of software development practices. Ambiguities in requirements lead a project to a point of failure or penalize it with a high budget and time for defect traceability. The ever-growing demand for advanced computing systems has increased the complexity of Software Requirements Engineering (SRE) practices. Blockchain systems require specialized SRE practices as the issues of Requirement Traceability (RT), developer/client confidentiality, and Requirement Negotiation (RN) typically exist in conventional approaches, which require more improvement. Moreover, blockchain technology incorporates the capacity to function as an infrastructure for the SRE framework providing transparency, security, and reliability. Even though the significance of studying blockchain in the context of SRE is evident, it is still in its infancy. None of the previous studies surveyed this domain to the best of our knowledge. We aim to summarize the scholarly contributions of blockchain acquainted SRE from 2015 to 2021 and to provide academia and practitioners with in-depth knowledge about this domain. In this article, we have provided a novel comprehensive review of the aspects of blockchain-acquainted SRE practices. We have presented SRE-based quality improvement factors and outlined the need for blockchain technology in this domain. Furthermore, we have classified SRE practices based on blockchain engineering. In addition, we have proposed a generic SRE model built on blockchain infrastructure along with its workflows. Similarly, we have provided implementation guidelines for the future development guidance of SRE applications built on blockchain technology. Finally, we have presented the current research challenges and provided future directions based on blockchain acquainted SRE.
Article
Full-text available
Governments and private sectors currently procure software solutions for industry through public tender using mass distribution websites. This alternative organizes the demand and produces a large number of software tenders. Objective . The present study focuses on analyzing the texts of these documents to characterize them efficiently and explore a particular solution to the general problem known as “to bid or not to bid.” The tool is based on the automatic classification of speech acts, from where we generate different metrics from the Public Call Software Tender (PCST). Methodology . Our first approach was to use some analysis techniques suggested for Requirements Specifications. In particular, our interest focused on speech acts and the ontology-based on speech acts for analyzing requirements. These works focus on classifying software requirements in the early stages of the life cycle, which gave us a starting point for our work in PCST. We use our tool to analyze a set of four PCSTs downloaded from the Chilean Government’s public purchases website for the validation stage. The automatic analysis consisted in categorizing and classifying the four PCST downloaded, obtaining the measured values of the variables used by the metrics. Results . An initial assessment shows that the results of this application agree with the proposals generated manually by expert analysts. Our proposal saves time and effort when looking for relevant tenders. Conclusion . We consider the theory of speech acts, which allows texts to be categorized from a pragmatic point of view. We propose a first version of an automatic text classifier based on characterizing speech acts accompanied by metrics. This tool will allow potential tenderers in a public call for software tenders to decide whether it is worth tendering for the call. Based on these assumptions, we propose to use the identification of speech acts in requirements specifications to calculate a set of metrics that will enable us not only to describe PCST but also to compare them.
Article
A key objective in the requirements elicitation process is to ensure a common understanding of requirements between customers and users and software developers from the other. The traditional practices for preventing ambiguous requirements focused on writing requirements clearly without guidelines that help practitioners elicit requirements from customers and users unambiguously. Since multiple studies underlined the prevalence of ambiguous requirements in software projects, the key purpose of this article is to construct a conceptual model of the consequences of ambiguous requirements. The novelty of this model manifests itself in explaining the possible negative effects resultant from eliciting ambiguous requirements from customers and users across software development processes. Accordingly, this model can increase the awareness of practitioners' and academicians' potential threat of ambiguous requirements and act as a trigger to find the guidelines to prevent ambiguous requirements during requirements elicitation.
Article
Full-text available
During the time half of the twentieth century, the utilization of Programmed computers has become huge. As an outcome, software programming has turned out to be increasingly differing and complex. Also, there are expanding requests on software programming – it must be less expensive, have more usefulness, be conveyed speedier, and be of higher quality than already. In the constantly changing environment and society of programming advancement, the procedures and strategies utilized when growing little projects are not adequate while developing extensive frameworks. As one response to this, distinctive improvement lifecycle models have been characterized. This paper portrays the three fundamental sorts of systems Development lifecycle models, from the successive models using incremental models to transformative models. The iterative advancement technique is additionally examined, and we additionally intricate the association of advancement lifecycle models to two rising fields in programming designing: programming design and part-based programming advancement.
Chapter
Business process management has become the most widely-used and reliable approach to organizational management over the last decades. It is also considered as a part of quality management system in an organization. Business process modeling is the core of business process management, which is used for visualization, analysis, and improvement of organizational activities. Moreover, business process modeling plays an important role in the context of business process management maturity of an overall enterprise. Therefore, this paper is focused on the problem of business process model quality evaluation. Existing approaches based on business process modeling guidelines, measures, and their thresholds are considered. Refined business process modeling rules, measures, quality criteria of numerical and linguistic values, and a method for evaluation of business process model quality are proposed. The corresponding information technology is designed and implemented, and results of its usage are outlined.
Article
Full-text available
Most software systems have different stakeholders with a variety of concerns. The process of collecting requirements from a large number of stakeholders is vital but challenging. We propose an efficient, automatic approach to collecting requirements from different stakeholders’ responses to a specific question. We use natural language processing techniques to get the stakeholder response that represents most other stakeholders’ responses. This study improves existing practices in three ways: Firstly, it reduces the human effort needed to collect the requirements; secondly, it reduces the time required to carry out this task with a large number of stakeholders; thirdly, it underlines the importance of using of data mining techniques in various software engineering steps. Our approach uses tokenization, stop word removal, and word lemmatization to create a list of frequently accruing words. It then creates a similarity matrix to calculate the score value for each response and selects the answer with the highest score. Our experiments show that using this approach significantly reduces the time and effort needed to collect requirements and does so with a sufficient degree of accuracy.
Chapter
The automotive industry faces radical changes induced by new and potentially disruptive technologies emerging from digital transformation. At the same time, the increased demand for energy efficiency, CO2 neutrality, autonomous driving, connectivity, and artificial intelligence is leading to fundamentally new business models. These new business models also open up opportunities for new market entrants. Global competition is also further increasing pressure on the players. This chapter focuses on selected systems engineering methods and tools that support activities throughout the automotive development process. They provide the required functionality to author, modify and manage the results of systems engineering, and adhere to positive user experience fostering user acceptance and tool adoption in daily work. Through systematic use of systems engineering methods and tools, omissions and false assumptions caused by complexity can be identified early, so that their impact can be minimized. The constant change in artifacts is traced and managed through the systems engineering project lifecycle.
Chapter
Cyber-physical systems, electrification, autonomous driving, connectivity, and shared mobility pose new challenges for powertrain development. To cope with these challenges, development approaches such as systems engineering need to be applied and further improved. Possible directions for the development of systems engineering are discussed together with the required skills and changes in education. The challenges of current development approaches are described from the powertrain development perspective. As the complexity of mechatronic and cyber-physical systems continues to increase rapidly, a deep understanding of systems in their ecosystems provides new opportunities for business and technological innovation. In the future, systems engineering as an approach needs to be customizable in order to fit to individual constraints such as organization, processes, methods available, resources, skills, and IT tools.
Chapter
The automotive industry faces radical changes induced by new and potentially disruptive technologies emerging from digital transformation. At the same time, the increased demand for energy efficiency, CO2 neutrality, autonomous driving, connectivity, and artificial intelligence is leading to fundamentally new business models. These new business models also open up opportunities for new market entrants. Global competition is also further increasing pressure on the players. This chapter focuses on selected systems engineering methods and tools that support activities throughout the automotive development process. They provide the required functionality to author, modify and manage the results of systems engineering, and adhere to positive user experience fostering user acceptance and tool adoption in daily work. Through systematic use of systems engineering methods and tools, omissions and false assumptions caused by complexity can be identified early, so that their impact can be minimized. The constant change in artifacts is traced and managed through the systems engineering project lifecycle.
Article
Full-text available
Gestational diabetes mellitus (GDM) is a condition in which women without previously diagnosed diabetes exhibit high blood glucose levels during pregnancy, especially during their third trimester. Gestational diabetes results from the body which makes some insulin but cannot use it properly. This in turn causes inappropriately elevated blood sugar levels. Diagnostic tests detect inappropriately high levels of glucose in blood samples. So, there is a need to manage this disease in order to reduce its risks through providing healthcare technologies. The aim of this research is to design and implement the Gestational Diabetes Management System (GDMS).This proposed system is centralized database which contains the patients’ records of gestational diabetes during Pregnancy. The system enables the patient to access the system and enter their medicinal readings like: blood glucose and blood pressure. These data will be held on a database and the system will process these medical data to statistical data for progressing of the patients and their physician. It allows the physician to make a suitable decision based on the collected data. Lastly advices of treatments are sent to the patients. The system will meet the needs of pregnancy and should be consistent with the maternal blood glucose goals that have been established. It will help to manage a gestational diabetes in a correct an easy way and to increase patient program compliance.
Chapter
Cyber-physical systems, electrification, autonomous driving, connectivity, and shared mobility pose new challenges for powertrain development. To cope with these challenges, development approaches such as systems engineering need to be applied and further improved. Possible directions for the development of systems engineering are discussed together with the required skills and changes in education. The challenges of current development approaches are described from the powertrain development perspective. As the complexity of mechatronic and cyber-physical systems continues to increase rapidly, a deep understanding of systems in their ecosystems provides new opportunities for business and technological innovation. In the future, systems engineering as an approach needs to be customizable in order to fit to individual constraints such as organization, processes, methods available, resources, skills, and IT tools.
Chapter
Full-text available
Alternative investments present an intensively grow domain which characterizes by relatively high risk. Our research focus to complex evaluation of such investment’s risks. There were formed special sample from ETF corresponding alternative invest-ments. Sample was structured in 10 classes of alternative investments. Risk evalua-tion involve applying different approaches. First approach grounding on volatility conception and include a number of risk measures. Special attention was paid to consider risk from asymmetry analysis, which reveals domination of negative skew of return`s distribution. Second approach estimates risk at the frameworks of a Val-ue-at-Risk methodology. VaR and CVaR estimations were examined by compara-tive analysis. Third approach use sensitivity analysis with returns of two chosen mar-ket indices. They are S&P500 and AGG. Only two classes from considered ETF`s classes (hedge funds and long short) indicates sensitivity to changes of S&P500 re-turns. A separate area of research was fitting probability distribution function. Four type of distributions were identified as a best fitting. The most recurrent distribution turned out to be four parametric Burr distribution. ETF classes are differing by risk level and risk characteristics, which should be taking into account in asset allocation process. Modelling investment risk for alternative investments should use complex attitude to risk analysis and evaluation.
Chapter
The automotive industry faces radical changes induced by new and potentially disruptive technologies emerging from digital transformation. At the same time, the increased demand for energy efficiency, CO2 neutrality, autonomous driving, connectivity, and artificial intelligence is leading to fundamentally new business models. These new business models also open up opportunities for new market entrants. Global competition is also further increasing pressure on the players. This chapter focuses on selected systems engineering methods and tools that support activities throughout the automotive development process. They provide the required functionality to author, modify and manage the results of systems engineering, and adhere to positive user experience fostering user acceptance and tool adoption in daily work. Through systematic use of systems engineering methods and tools, omissions and false assumptions caused by complexity can be identified early, so that their impact can be minimized. The constant change in artifacts is traced and managed through the systems engineering project lifecycle.
Article
Full-text available
Context & motivation] Growing software companies with increasing product complexity face the issue of how to scale up their Requirements Engineering (RE) practices. In market-driven requirements engineering, release planning and scoping decisions are increasingly challenging as the size and complexity increases. [Problem] This paper presents initial results of an ongoing exploratory, qualitative investigation of three market-driven, industrial cases with the objective of increasing our understanding of challenges in scaling up requirements engineering and how these challenges are addressed by the studied companies. [Results] Through 13 interviews in three companies, requirements engineering scalability issues are explored related to scoping and the structure of RE artifacts. [Contribution] The main contribution are findings related to increasing RE scale based on interpretations of the experienced interviewees' views.
Article
Full-text available
To avoid problems in software development, requirements must be elicited and documented properly. The formal methods approach to requirements specification provides precision, helps to refine requirements, and strives to ensure their correctness by providing a mathematical basis. Overall, formal specifications can be very beneficial for the entire development process due to the mathematical rigor that can help in avoiding errors, but only if formal methods are employed judiciously. In addition, writing good formal specifications requires both engineering skills and abstract thinking, which come with practice as well as expertise. In this entry, formal requirements specification is discussed in terms of advantages and trade-offs, the process of formalization, and best practices. To demonstrate the style and give the reader a feel for formal specification, a case study of formalizing requirements using the Z notation is presented.
Conference Paper
Full-text available
In this paper, we propose a novel Artificial Neural Network (ANN) to predict software effort from use case diagrams based on the Use Case Point (UCP) model. The inputs of this model are software size, productivity and complexity, while the output is the predicted software effort. A multiple linear regression model with three independent variables (same inputs of the ANN) and one dependent variable (effort) is also introduced. Our data repository contains 240 data points in which, 214 are industrial and 26 are educational projects. Both the regression and ANN models were trained using 168 data points and tested using 72 data points. The ANN model was evaluated using the MMER and PRED criteria against the regression model, as well as the UCP model that estimates effort from use cases. Results show that the ANN model is a competitive model with respect to other regression models and can be used as an alternative to predict software effort based on the UCP method.
Article
Full-text available
Requirements Development, Requirements Verification, Requirements Validation, System Verification, and System Validation are important systems engineering tasks. This paper describes these tasks and then discusses famous systems where these tasks were done correctly and incorrectly. This paper shows examples of the differences between developing requirements, verifying requirements, validating requirements, verifying a system, and validating a system. Understanding these differences may help increase the probability of success of future system designs. © 2004 Wiley Periodicals, Inc. Syst Eng 8: 1–14, 2005
Article
Full-text available
Requirements engineering (RE) tools are increasingly used to ease the RE processes and allow for more systematic and formalized handling of requirements, change management and traceability. For developers and companies evaluating the use of RE tools it is thus essential to know which RE processes are supported by tools and how they fit to their own priorities. The answer isn't easy because many sales prospects highlight numerous features-yet leave out to which degree they're supported and whether all features really matter. To gain insight into how current RE tools adapt to RE activities, we ran a 146-item survey based on the features covered by the ISO/IEC TR 24766:2009, a new framework for assessing RE tool capabilities. We received responses from 37 participants, covering all relevant tools. In addition to the tools' score in each activity, we assessed their performance in three concrete use scenarios. Our findings can help practitioners select an RE tool as well as provide areas for improvement for RE tools developers.
Article
Full-text available
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 article 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 for 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.
Article
Full-text available
In 1990, Anthony Hall published a seminal article that listed and dispelled seven myths about the nature and application of formal methods. Today - five years and many successful applications later - formal methods remain one of the most contentious areas of software-engineering practice. Despite 25 years of use, few people understand exactly what formal methods are or how they are applied. Many nonformalists seem to believe that formal methods are merely an academic exercise -- a form of mental masturbation that has no relation to real-world problems. The media's portrayal of formal methods does little to help the situation. In many "popular press" science journals, formal methods are subjected to either deep criticism or, worse, extreme hyperbole. Fortunately, today these myths are held more by the public and the computer-science community at large than by system developers. It is our concern, however, that new myths are being propagated, and more alarmingly, are receiving a certain tacit acceptance from the system-development community. Following Hall's lead, we address and dispel seven new myths about formal methods: Formal methods delay the development process; formal methods lack tools; formal methods replace traditional engineering design methods; formal methods only apply to software; formal methods are unnecessary; formal methods are not supported; and formal-methods people always use formal methods.
Conference Paper
Full-text available
In this paper, we present and discuss the results of an internal replication of a controlled experiment for assessing the effectiveness of including screen mockups when adopting Use Cases. The results of the original experiment indicate a clear improvement in terms of understandability of functional requirements when screen mockups are present with no significant impact on effort. The data analysis of the replication, conducted also in this case with undergraduate students, confirms the results of the original experiment with slight differences, thus confirming that screen mockups facilitate the understanding of requirements without influencing the effort. We also sketch here some issues related to the documentation and communication between experimenters.
Conference Paper
Full-text available
The PLUSS approach (Product Line Use case modeling for Systems and Software engineering) is a domain modeling method tailored towards the development of long lived software intensive systems. PLUSS provides means to maintain a common and complete use case model for a whole family of systems. In this paper, we describe how the commercial requirements management tool Telelogic DOORS and the UML modeling tool IBM-Rational Rose can be extended and used for managing system family models in accordance with the PLUSS approach.
Article
Full-text available
The article proposes and justifies a trial classification scheme. An earlier version was used to organize the papers submitted to this symposium, and the scheme has been refined somewhat in response to inadequacies discovered during the process of selecting the program. The first issue to be tackled is the heterogeneity of the topics usually considered part of requirements engineering. They include: tasks that must be completed; problems that must be solved; solutions to problems; ways of contributing to knowledge; and types of system. There seems to be a need for several orthogonal dimensions of classification. While multiple dimensions certainly help us cope with the heterogeneity of concerns, there is a danger of making the classification scheme too complex to use. I have compromised by settling on two dimensions.
Article
Full-text available
This paper describes the application of human–computer interaction (HCI) principles and methods to requirements engineering in a case study development of a visualisation tool, ADVISES, to support epidemiological research. The development approach consisted of scenario-based design and analysis of the users’ tasks and mental model of the domain. Prototyping and storyboarding techniques were used to explore design options with users as well as specifying functionality for two versions of the software to meet the needs of novice and expert users. Application of HCI functional allocation heuristics to guide system requirements decisions is explained. An evaluation of the prototype was carried out to assess the extent to which the expert model would support public health professionals in their analysis activities. The results of the design exploration requirements analysis study are reported. The implications of scenario-based design exploration, functional allocation and software architecture are discussed.
Book
Do you… Use a computer to perform analysis or simulations in your daily work? Write short scripts or record macros to perform repetitive tasks? Need to integrate off-the-shelf software into your systems or require multiple applications to work together? Find yourself spending too much time working the kinks out of your code? Work with software engineers on a regular basis but have difficulty communicating or collaborating? If any of these sound familiar, then you may need a quick primer in the principles of software engineering. Nearly every engineer, regardless of field, will need to develop some form of software during their career. Without exposure to the challenges, processes, and limitations of software engineering, developing software can be a burdensome and inefficient chore. In What Every Engineer Should Know about Software Engineering, Phillip Laplante introduces the profession of software engineering along with a practical approach to understanding, designing, and building sound software based on solid principles. Using a unique question-and-answer format, this book addresses the issues and misperceptions that engineers need to understand in order to successfully work with software engineers, develop specifications for quality software, and learn the basics of the most common programming languages, development approaches, and paradigms.
Book
AntiPatterns: Identification, Refactoring, and Management catalogs 48 bad management practices and environments common to software development, IT, and other organizations. The authors cover antipatterns of management, along with environmental/cultural antipatterns and personality antipatterns/phenotypes. Through the classification of these harmful practices, you will be able to correctly identify problems in your own work environment, and take action to correct them. The authors apply their extensive work and consultative experience, as well as the experience of the many professionals that they have known. This approach leads to a realistic treatment of antipattern concepts. Written for a wide audience of practitioners, the authors avoid a scholarly style, instead infusing the text with entertaining “gadgets,” including rambunctious and ribald sidebars, cartoons, stories, and jokes, as well as names for their antipatterns that are at once visual, iconic, humorous, and memorable. Following introductory material describing some management theory and how humans behave individually and in groups, the text provides the catalog of management and environmental antipatterns. The book then offers general advice on overcoming bad practices through successful interaction with clients, customers, peers, supervisors, and subordinates.
Article
The FBI's Virtual Case File is intended to automate the FBI's paper-based work environment, allow agents and intelligence analysts to share vital investigative information, and replace the obsolete Automated Case Support (ACS) system. However, several years after its inception, VCF emerged as the most high publicized software failure in history. Eight factors are deemed responsible for the failure and these include poorly defined and slowly evolving design requirements, overly ambitious schedules, and the lack of a plan to guide hardware purchases, network deployments, and software development for the bureau.
Article
This report is primarily aimed at people with some background in Requirements Engineering or practitioners wishing to assess tools available for managing requirements. We provide a starting point for this assessment, by presenting a brief survey of existing Requirements Management tools. As a part of the survey, we characterize a set of requirements management tools by outlining their features, capabilities and goals. The characterization offers a foundation to select and possibly customize a requirements
Conference Paper
The field of software economics seeks to develop technical theories, guidelines, and practices of software development based on sound, established, and emerging models of value and value-creation---adapted to the domain of software development as necessary. The premise of the field is that software development is an ongoing investment activity---in which developers and managers continually make investment decisions requiring the expenditure of valuable resources, such as time, talent, and money. The overriding aim of this activity is to maximize the value added subject to an equitable distribution among the participating stakeholders. The goal of the tutorial is to expose the audience to this line of thinking and introduce the tools pertinent to its pursuit. The tutorial is designed to be self-contained and will cover concepts from introductory to advanced. Both practitioners and researchers with an interest in the impact of value considerations in software decision-making will benefit from attending it. This tutorial is offered in conjunction with the Fourth International Workshop on Economics-Driven Software Engineering Research (EDSER-4). The tutorial is meant in part to enable those who would like to participate in the workshop, but who might not possess the requisite background, to come up to speed.
Article
This book is a text and reference book on Category Theory, a branch of abstract algebra. The book contains clear definitions of the essential concepts, which are illuminated with numerous accessible examples. It provides full proofs of all the important propositions and theorems, and aims to make the basic ideas, theorems, and methods of Category Theory understandable. Although it assumes few mathematical pre-requisites, the standard of mathematical rigour is not compromised. The material covered includes the standard core of categories; functors; natural transformations; equivalence; limits and colimits; functor categories; representables; Yoneda's lemma; adjoints; and monads. An extra topic of cartesian closed categories and the lambda-calculus is also provided.
Article
We must question the assumptions underlying the well-known current formal software development methods to see why they have not been widely adopted and what should be changed.
Article
Requirements engineering is one of the fundamental knowledge areas in software and systems engineering graduate curricula. Recent changes in educational delivery and student demographics have created new challenges for requirements engineering education. In particular, there is an increasing demand for online education for working professionals. This paper describes a graduate requirements engineering course designed to address these new dynamics while aligning learning objectives with the prevailing body of knowledge and professional practices.
Article
A review of the problems that haunted the FBI's Virtual Case File and Sentinel case management programs and an examination of the technical reasons for these failures provide the basis for recommendations to help avoid their repetition.
Article
From the Book:Why We Wrote This BookTrue believers represent software development alternativesIn the last few years, two ostensibly conflicting approaches to software development have competed for hegemony. Agile method supporters released a manifesto that shifts the focus from traditional plan-driven, process-based methods to lighter, more adaptive paradigms. Traditional methods have reasserted the need for strong process discipline and rigorous practices. True believers on both sides have raised strident, often antagonistic, voices. This book is for the rest of us We wrote this book for the rest of us—those caught in the middle of the method wars simply trying to get our projects completed and accepted within too-tight schedules and budgets. We hope to clarify the perplexity about the roles of discipline, agility, and process in software development. We objectively compare and contrast the traditional, plan-driven approaches to the newer, agile approaches and present an overview of their home grounds, strengths, and weaknesses. We then describe a risk-based approach to aid in balancing agility and discipline within a software development project. Our goal is to help you in your business environment We hope that this is a practical book. It is intended to be neither academic nor exhaustive, but pragmatic. It is based on our own development experiences, current and past literature, long conversations with proponents of agile and plan-driven approaches, teaching students how to balance discipline and agility, and years of observing and measuring software development in industry, government, and academia. We discuss the subjectmatter absent a need to choose sides. Our goal is to help you gain the understanding and information you need to integrate the approaches in a manner that best fits your business environment. Who Should Read This Book The perplexed—or just curious This book is for perplexed software and management professionals who have heard the buzz about agile methods and want to separate the chaff from the wheat. Perhaps you have a CMM- or ISO-certified organization and want to know if and how agile methods can help you. Or perhaps some part of your organization has adopted agile methods and you are unsure of how they should fit in. Fundamentally, if you need to understand how the latest software development approaches can help meet business goals, this book is for you. Software project managers and mid-level executives should read this book to understand the agility/plan-driven controversy and learn how best to apply the new approaches in your organizations. Software developers should read this book to better understand how your field is evolving and what it means for your career.Computer science and software engineering students should read this book to better understand how to make choices about your own level of discipline, both in school and at work. Academicians should read this book to understand some of what your students are asking about, and how to help them make informed decisions.Proponents of both agile and plan-driven methods should read this book to dispassionately look at your opponent's ideas.CIOs and CEOs should read this book to help you understand what's going on in the software world and what implications it may have for your company.How To Read This Book Several ways to read the book Most of you are busy people, and "must-read" material attacks you from all sides, 24/7. Some of you want to quickly assess the material for later reflection. Others want to know how to implement the concepts we present. For that reason, we've tried to make this book easy to read quickly but with pointers to more in-depth material. In a hurry? Use the fast track for a quick overview If time is short, use the fast track summaries to scan the total content of the book, stopping to read things you find interesting or particularly applicable to your needs, and following the icons for specific technical information. If you find you need even more detailed material, there are references as well as a list of additional resources in Appendix F. First and last chapters are key You can also tailor your reading through chapter selection. Reading the first and last chapters gives a pretty good idea of the material at a familiarization level. You can read the chapters in any order. Here is a quick summary:The first chapter sets the stage for what follows. It introduces the main points and provides an executive summary of the book.Chapter 2 compares the agile and plan-driven approaches and provides insight into the type of projects where each has been most successful—their home grounds.Chapter 3 provides an experiential introduction to the approaches by describing how both a typical and not-so-typical day might be spent using each.Chapter 4 presents two project case studies that illustrate the limits of pure agile and pure plan-driven implementations and the benefits of integrating the approaches.Chapter 5 describes a risk-based approach for making methodology decisions that integrate agile and plan-driven practices, and illustrates it with representative examples. Chapter 6 summarizes the material and offers some final observations. Appendix A provides top-level descriptions of the major agile and plan-driven methods, highlighting their primary distinguishing factors, and a summary of those factors for comparison.Appendices B-E provide technical and background information to support our analyses and speak to specific technical topics. Appendix F supplies references and the endnotes are listed by chapter in Appendix G. 0321186125P04142003
Article
Anyone who has built or remodelled a house and has developed or enhanced software must have noticed the similarity of these activities. This paper examines these two processes from the points of view of budgeting, scheduling, and requirements creep. It is admitted from the start that some of the argument and conclusions are based on popular perceptions and personal observation over small populations, that is, the houses the author and some close friends have remodelled and built and software projects in which the author has participated as an analyst, designer, programmer, or consultant.
Article
The management of the requirements engineering process is similar to the management of any other endeavour. Before starting out it is necessary to understand what needs to be done. We need to know the sorts of activities that must be undertaken. We need to know whether there are any dependencies between the activities, e.g. whether one activity can only commence when another one has been completed. We need to know what kinds of skills are required to perform the activities.
Article
As with any engineering discipline, software development requires a measurement mechanism for feedback and evaluation. Measurement is a mechanism for creating a corporate memory and an aid in answering a variety of questions associated with the enactment of any software process. It helps support project planning (e. g., How much will a new project cost?); it allows us to determine the strengths and weaknesses of the current processes and products (e. g., What is the frequency of certain types of errors?); it provides a rationale for adopting/refining techniques (e. g., What is the impact of the technique XX on the productivity of the projects?); it allows us to evaluate the quality of specific processes and products (e. g., What is the defect density in a specific system after deployment?). Measurement also helps, during the course of a project, to assess its progress, to take corrective action based on this assessment, and to evaluate the impact of such action.
Conference Paper
In requirements engineering, CRC modeling and use case analysis are established techniques and are often performed as a group work activity. In particular, role play is used to involve different stakeholders into the use case analysis. To support this kind of co-located collaboration we developed CREW-Space, which allows several users to simultaneously interact through Android-enabled mobile devices with the same model displayed on a shared screen. Furthermore, it keeps track of the current state of the role play and, in addition, each mobile device serves as a private workspace; it actually turns into a tangible digital CRC card.
Article
Model transformation is one of the basic principles of Model Driven Architecture. To build a software system, a sequence of transformations is performed, starting from requirements and ending with implementation. However, requirements are mostly in the form of text, but not a model that can be easily understood by computers; therefore automated transformations from requirements to analysis models are not easy to achieve. The overall objective of this systematic review is to examine existing literature works that transform textual requirements into analysis models, highlight open issues, and provide suggestions on potential directions of future research. The systematic review led to the analysis of 20 primary studies (16 approaches) obtained after a carefully designed procedure for selecting papers published in journals and conferences from 1996 to 2008 and Software Engineering textbooks. A conceptual framework is designed to provide common concepts and terminology, and to define a unified transformation process. This facilitates the comparison and evaluation of the reviewed papers.
Chapter
The concept of Simultaneous Engineering has long been known to manufacturing companies throughout all engineering sectors. Despite the first euphoric waves of implementation, most companies are not satisfied with their Simultaneous Engineering successes. This Paper summarizes short comings of current implementations of the Simultaneous Engineering approach and illustrates how production Requirements Management could be used as an approach for solving those problems. The major differences between product orientated requirement engineering compared to the production perspective are shown and a first approach for the extension of the theory of Requirements Management is proposed. Keywords:Simultaneous Engineering-Product and Production Co-Development-Agile Production
Article
The search for scientific bases for confronting problems of social policy is bound to fail, becuase of the nature of these problems. They are wicked problems, whereas science has developed to deal with tame problems. Policy problems cannot be definitively described. Moreover, in a pluralistic society there is nothing like the undisputable public good; there is no objective definition of equity; policies that respond to social problems cannot be meaningfully correct or false; and it makes no sense to talk about optimal solutions to social problems unless severe qualifications are imposed first. Even worse, there are no solutions in the sense of definitive and objective answers.
Article
The authors review how to define a set of "negative requirements," or hazards, starting with elicitation and discovery of shall-not requirements through system integration and testing using a process called hazard mining.
Article
Recent conversations pertaining to licensure of software engineers in the US and offshoring had me thinking about Carmen again. I wondered how well she would have fared if her secret agent cover was as a software guru. Would she be able to pass as a software engineer in several different countries-for example, in the US, India, Malaysia, Argentina, and Ireland? Are there differences in how software engineering is practiced in different cultures that are so profound that even a super spy, expert at mimicry and disguise, couldn't fool her colleagues? The answers to these questions have important implications for the transnational practice of software engineering, for outsourcing and offshoring policy and strategy, and even for national security.
Article
Today's large software-intensive systems have critical quality requirements, limited budgets, and stringent development and maintenance schedules. It is therefore necessary to be able to objectively evaluate these systems during their development to determine whether they will meet requirements, schedule, and budget, to assist risk management, and to facilitate corrective and preventive action. The discipline of software metrics has the potential for providing the objective information necessary for technical and managerial insight into, and control of, the development effort. However, the current software metrics literature does not address the need for integrated and consistent system- and software-level metrics, nor does it provide detailed descriptions of metrics for full life cycle coverage. This article is an introduction to work in progress at The Aerospace Corporation and California State University, Long Beach, in the area of metrics for requirements engineering. The first in a planned series of papers on metrics for full life cycle system and software engineering, it describes the role of metrics in an integrated approach to system and software engineering, introduces the basic components of complete metric definitions, and discusses the use of metrics in comprehensively assessing objective aspects of the requirements engineering process and its products.
Conference Paper
Providing high-quality software within budget is a goal pursued by most software companies. Incomplete requirements specifications can have an adverse effect on this goal and thus on a company's competitiveness. Several empirical studies have investigated the effects of requirements engineering methods on the completeness of a specification. In order to increase this body of knowledge, we suggest using an objective evaluation scheme for assessing the completeness of specification documents, as objectifying the term completeness facilitates the interpretation of evaluations and hence comparison among different studies. This paper reports experience from applying the scheme to a student experiment comparing a use case with a textual approach common in industry. The statistical analysis of the specification's completeness indicates that use case descriptions lead to more complete requirements specifications. We further experienced that the scheme is applicable to experiments and delivers meaningful results.
Article
The study of software economics is not yet mature. For many years, the lines of code (LOG) metrics has tended to conceal major software cost drivers such as the production of requirements, plans, specifications, manuals, and other paper documents. The advent of function point metrics in the late 1970s allowed us to explore the measurement of such noncoding activities, none of which could be properly explored or normalized using LOC metrics. Indeed, we now know that on some projects (such as large defense systems) the cost to produce paper documents is twice as much as the cost to produce the code itself. The ability to measure all activities associated with software production has led to the concept of activity-based studies of software cost. The paper discusses the approach
Article
Agile development processes are adaptive rather than predictive. Therefore, agile processes emphasize operational system code rather than its documentation. To overcome the absence of comprehensive documentation artifacts, agile methods require constant interaction between the system stakeholders. Ironically, however, some traditional documentation artifacts come to support this kind of interaction. In this study, we examine the relationship between software and documentation. We develop an approach that enables incorporating domain documentation to agile development, while keeping the processes adaptive. We also provide a system design that actively uses domain knowledge documentation. These ideas have been applied through the implementation and use of agile documentation support components.