Final Report Summary - RESACS (Requirements Engineering and Systems Architecting Case Studies)
Objectives
The key objectives of the RESACS project were to investigate into requirements engineering (RE) and software architecting (SA) processes through case studies. We had three lines of investigation: (a) RE-SA interactions, (b) creating a requirements checklist, and (c) compliance of contractual requirements against regulatory codes and standards. These are discussed below in turn.
RE-SA Interactions
While the interplay between Requirements Engineering (RE) and Systems Architecting (SA) processes has been researched in terms of development methods, tools, and processes, there is a distinct lack of empirical understanding and theory building regarding the scientific properties of this interaction. Such an understanding and theory building would: (a) add substantially to the body of knowledge, (b) aid progress in the practice of RE and SA, and (c) help improve RE and SA technology. Furthermore, both technical and human aspects are considered critical for the success of software development. In particular, for RE and SA, human factors are even more important because these processes are at the front-end of the development cycle and are more aligned with real-world issues.
Technical properties deal with such issues as: concrete models in RE and SA, traceability between SA elements and requirements, and the choice of architecting tactics and their impact on requirements satisfaction. In contrast, human-based properties deal with issues such as: the RE competency of software architects and its impact on SA quality; how personal interests and motivation effect RE and SA products; and the importance of non-technical skills (communication, leadership, etc.) in RE and SA activities.
This research focused upon the human and process factors involved in the RE-SA interaction. Example issues considered were: (1) the effect of the presence or absence of an existing SA on requirements; (2) the impact of architects with RE knowledge on architecture quality; and (3) the impact of human factors vs. technology on RE and SA artefacts.
The key result of this investigation is a novel emerging theory describing the impact of human and process factors in the interaction between RE and SA. The theory is constructed bottom-up based on evidence from six empirical studies, in a variety of contexts: “lab” studies and experiments, and a case study on a real, large-scale project. The proposed theory is evaluated for its “goodness” based on SE theory-construction guidelines. The emergent theory describes three observed conditions or issues that can improve RE and SA processes:
The effectiveness of RE and SA processes is increased if technological support ensures: (1) tighter coupling between the artefacts and activities across RE and SA; (2) the project’s development context (such as new development vs. enhancements, agile vs. traditional development models, centralized vs. distributed organization, etc.); and, (3) compatibility with the varying degrees of knowledge, skill-sets and personal motivation possessed.
The socio-economic implications of this theory are anticipated for practice (e.g. aiding management and senior technical staff in the execution of RE and SA processes, resource management, etc.) and research (e.g. aiding researchers in hypothesis forming and testing, and assessing the maturity of the RE-SA field.).
Creating a requirements checklist
The specification of software requirements (SRS) acts as the basis for an agreement between the customer and the developer. Deficiency in SRS can lead to problems in product quality and project costs and schedule.
This research focused on creating a checklist for assessing SRSs in order to help prevent project problems further down the development cycle. Based on theory and standards (e.g. IEEE Std. 830) and “best practices” used in the software industry, we have drafted a prototype SRS checklist. This is currently entering iterations of validation-improvement stages, involving SRS experts from industry. Anticipated result is a useable and effective requirements checklist.
The socio-economic impact of this checklist is higher quality software systems, improved project schedules and reduced software development costs. The target users of the checklist include requirements analysts and quality assurance personnel.
Compliance of contractual requirements
Large-scale contractual systems engineering projects often need to comply with a myriad of government regulations and standards as part of contractual obligation. A key activity in the requirements engineering (RE) process for such a project is to demonstrate that all relevant requirements have been elicited from the regulatory documents and have been traced to the contract as well as to the target system components. That is, the requirements have met regulatory compliance.
However, there are impediments to achieving this level of compliance due to such complexity factors as: voluminous contract, large number of regulatory documents, and multiple domains of the system. Little empirical research has been conducted in the scientific community on identifying these impediments. Knowing these impediments is a driver for change in the solutions domain (i.e. creating improved or new methods, tools, processes, etc.) to deal with such impediments.
Through a case study of an industrial RE project, we have identified a number of key impediments to achieving regulatory compliance in a large-scale, complex, systems engineering project. This project is an upgrade of a rail infrastructure system.
The key contribution of this research is a number of hitherto uncovered impediments described in qualitative and quantitative terms. We also describe an artefact model, depicting key artefacts and relationships involved in such a compliance project. This model was created from data gathered and observations made in this compliance project. In addition, we describe emergent metrics on regulatory compliance of requirements.
The socio-economic impact of these contributions is that the impediments identified now form a solid platform to create technologies to overcome these impediments. This is thus fodder for technology research and development. Also, the artefact model can aid project managers during planning of compliance projects. Finally, the proposed metrics can possibly be used for estimating the effort needed to achieve regulatory compliance of system requirements.
The key objectives of the RESACS project were to investigate into requirements engineering (RE) and software architecting (SA) processes through case studies. We had three lines of investigation: (a) RE-SA interactions, (b) creating a requirements checklist, and (c) compliance of contractual requirements against regulatory codes and standards. These are discussed below in turn.
RE-SA Interactions
While the interplay between Requirements Engineering (RE) and Systems Architecting (SA) processes has been researched in terms of development methods, tools, and processes, there is a distinct lack of empirical understanding and theory building regarding the scientific properties of this interaction. Such an understanding and theory building would: (a) add substantially to the body of knowledge, (b) aid progress in the practice of RE and SA, and (c) help improve RE and SA technology. Furthermore, both technical and human aspects are considered critical for the success of software development. In particular, for RE and SA, human factors are even more important because these processes are at the front-end of the development cycle and are more aligned with real-world issues.
Technical properties deal with such issues as: concrete models in RE and SA, traceability between SA elements and requirements, and the choice of architecting tactics and their impact on requirements satisfaction. In contrast, human-based properties deal with issues such as: the RE competency of software architects and its impact on SA quality; how personal interests and motivation effect RE and SA products; and the importance of non-technical skills (communication, leadership, etc.) in RE and SA activities.
This research focused upon the human and process factors involved in the RE-SA interaction. Example issues considered were: (1) the effect of the presence or absence of an existing SA on requirements; (2) the impact of architects with RE knowledge on architecture quality; and (3) the impact of human factors vs. technology on RE and SA artefacts.
The key result of this investigation is a novel emerging theory describing the impact of human and process factors in the interaction between RE and SA. The theory is constructed bottom-up based on evidence from six empirical studies, in a variety of contexts: “lab” studies and experiments, and a case study on a real, large-scale project. The proposed theory is evaluated for its “goodness” based on SE theory-construction guidelines. The emergent theory describes three observed conditions or issues that can improve RE and SA processes:
The effectiveness of RE and SA processes is increased if technological support ensures: (1) tighter coupling between the artefacts and activities across RE and SA; (2) the project’s development context (such as new development vs. enhancements, agile vs. traditional development models, centralized vs. distributed organization, etc.); and, (3) compatibility with the varying degrees of knowledge, skill-sets and personal motivation possessed.
The socio-economic implications of this theory are anticipated for practice (e.g. aiding management and senior technical staff in the execution of RE and SA processes, resource management, etc.) and research (e.g. aiding researchers in hypothesis forming and testing, and assessing the maturity of the RE-SA field.).
Creating a requirements checklist
The specification of software requirements (SRS) acts as the basis for an agreement between the customer and the developer. Deficiency in SRS can lead to problems in product quality and project costs and schedule.
This research focused on creating a checklist for assessing SRSs in order to help prevent project problems further down the development cycle. Based on theory and standards (e.g. IEEE Std. 830) and “best practices” used in the software industry, we have drafted a prototype SRS checklist. This is currently entering iterations of validation-improvement stages, involving SRS experts from industry. Anticipated result is a useable and effective requirements checklist.
The socio-economic impact of this checklist is higher quality software systems, improved project schedules and reduced software development costs. The target users of the checklist include requirements analysts and quality assurance personnel.
Compliance of contractual requirements
Large-scale contractual systems engineering projects often need to comply with a myriad of government regulations and standards as part of contractual obligation. A key activity in the requirements engineering (RE) process for such a project is to demonstrate that all relevant requirements have been elicited from the regulatory documents and have been traced to the contract as well as to the target system components. That is, the requirements have met regulatory compliance.
However, there are impediments to achieving this level of compliance due to such complexity factors as: voluminous contract, large number of regulatory documents, and multiple domains of the system. Little empirical research has been conducted in the scientific community on identifying these impediments. Knowing these impediments is a driver for change in the solutions domain (i.e. creating improved or new methods, tools, processes, etc.) to deal with such impediments.
Through a case study of an industrial RE project, we have identified a number of key impediments to achieving regulatory compliance in a large-scale, complex, systems engineering project. This project is an upgrade of a rail infrastructure system.
The key contribution of this research is a number of hitherto uncovered impediments described in qualitative and quantitative terms. We also describe an artefact model, depicting key artefacts and relationships involved in such a compliance project. This model was created from data gathered and observations made in this compliance project. In addition, we describe emergent metrics on regulatory compliance of requirements.
The socio-economic impact of these contributions is that the impediments identified now form a solid platform to create technologies to overcome these impediments. This is thus fodder for technology research and development. Also, the artefact model can aid project managers during planning of compliance projects. Finally, the proposed metrics can possibly be used for estimating the effort needed to achieve regulatory compliance of system requirements.