Remo Ferrari

Architecting-problems rooted in requirements

Requirements permeate many parts of the software development process outside the requirements engineering (RE) process. It is thus important to determine whether software developers in these other areas of software development face any requirements-oriented (RO) problems in carrying out their tasks. Feedback so obtained can be invaluable for improving both requirements and RE technologies. In this paper, we describe an exploratory case study of requirements-oriented problems experienced by 16 architecting teams designing the same banking application. The study found that there were several different types of RO problems, of varying severity, which the architects faced in using the given requirements; those architects with RE background also faced RO problems; and about a third of all problems were RO problems. There was much concurrence of our findings with software-expert opinion from a large insurance company. There were also areas where there were relatively few RO problems. The paper also describes some implications of the findings for the RE field, particularly in the areas of: expression of quality requirements for different stakeholders; empirical studies on quality scenarios; tighter integration of RE and software architecting processes; and requirements to architecture mapping. There are opportunities for further research based on two emergent hypotheses which are also described in this paper.

The Impact of Requirements Knowledge and Experience on Software Architecting: An Empirical Study

While the relationship between Requirements Engineering and software architecture (SA) has been studied increasingly in the past five years in terms of methods, tools, development models, and paradigms, that in terms of the human agents conducting these processes has barely been explored. This paper describes the impact of requirements knowledge and experience (RKE) on SA tasks. Specifically, it describes an exploratory, empirical study involving a number of architecting teams, some with requirements background and others without, all architecting from the same set of requirements. The overall results of this study suggest that architects with RKE perform better than those without, and specific areas of architecting are identified where these differences manifest. We discuss the possible implications of the findings on the areas of training, education and technology.

A controlled experiment to assess the impact of system architectures on new system requirements

While much research attention has been paid to transitioning from requirements to software architectures, relatively little attention has been paid to how new requirements are affected by an existing system architecture. Specifically, no scientific studies have been conducted on the “characteristic” differences between the newly elicited requirements gathered in the presence or absence of an existing software architecture. This paper describes an exploratory controlled study investigating such requirements characteristics. We identify a multitude of characteristics (e.g., end-user focus, technological focus, and importance) that were affected by the presence or absence of an SA, together with the extent of this effect. Furthermore, we identify the specific aspects of the architecture that had an impact on the characteristics. The study results have implications for RE process engineering, post-requirements analysis, requirements engineering tools, traceability management, and future empirical work in RE based on several emergent hypotheses resultant from this study.

The impact of non-technical factors on Software Architecture

Most of the research and pedagogical literature in Software Architecture is on technical issues. Recently, however, there has been increasing interest on the importance of non-technical factors such as leadership, communication, inter-personal skills, work habits etc. in architecting. In this paper, we continue this line of research by conducting an empirical study examining the impact of non-technical factors in Software Architecture from the viewpoint of academia. We analysed non-technical problems encountered from 15 student architecting teams to determine the types of problems students have, and also their impact on the quality of the architecture. Furthermore, we analyzed the IEEE/ACM Software Engineering and Computer Science curriculums to determine any correspondence between these curriculums and the students architecting performance. Based on this analysis, we make recommendations for the improved education of student software architects.

Towards a compliance meta-model for system requirements in contractual projects

In contractual systems engineering projects, the developing organization is often required to demonstrate compliance of the systems requirements against a myriad of engineering standards and government regulations. In order to satisfy this goal, the project requirements imposed by standards and regulations through the contract need to be traceable to/fro appropriate project artefacts (such as the contract, various system and sub-system requirements specifications, standards, regulatory documents, etc.). However, these artefacts form a complex interrelationship network, leading to significant challenges in demonstrating requirements compliance. Current practices dealing with such compliance are ad hoc and arduous. In this paper, we identify key artefacts, relationships and challenges that we are currently discovering from a case study on a large-scale, contractual, requirements compliance project. These findings can be a basis for creating a meta-model for requirements compliance in a systems engineering project. This paper describes the on-going case study, the emerging findings, and their implication.

Requirements and Systems Architecture Interaction in a Prototypical Project: Emerging Results

[Context and Motivation] Subsequent to an exploratory laboratory study on the effects of Software Architecture (SA) on Requirements Engineering (RE), in this paper, we present preliminary results of an extension of this initial study by conducting a case study on a large-scale prototypical rail project. [Question/Problem] Specifically, we ask “What is the role of an SA on Requirements decision-making?”. [Principal Ideas/Results] Specific types of architectural effects on requirements decisions are identified. The impact of the affected requirements decisions on downstream processes and the product itself is also characterized. [Contribution] The understanding gained from this study has implications on such areas as: project planning, risk, RE, and others.

Does Requirements Clustering Lead to Modular Design

[Context and motivation] The clustering of system requirements groups together related requirements. In a concept paper, we had previously proposed a requirements clustering approach for the purpose of modularizing software. [Question/problem] In this short paper, we describe a preliminary study to explore the answer to the posed question: whether or not requirements clustering leads to modular design as measured by design goodness criteria. [Principal ideas/results] The study assesses the modularity of software designs developed by independent groups given the same requirements. These are then compared against the expected design resultant from implementing the requirements cluster. [Contribution] The study results are encouraging and it warrants further investigation.

Requirements Engineering Decisions in the Context of an Existing Architecture: A Case Study of a Prototypical Project

The role of an existing systems architecture (SA) in requirements engineering (RE) is recognised as important, but under-researched. A recent exploratory study of ours investigated this issue in a laboratory setting involving student participants. While the initial findings are promising, much work still remains to solidify the results. Therefore, we conducted a replication of the study, and its significant extension, on a large-scale prototypical rail project. Specifically, we identify (i) the effects of SA on RE decisions, (ii) the characteristics of the RE decisions and (iii), the impact of such decisions on development activities and the rail system. The findings of this study have implications on tighter RE-SA integration across subsystems, impact analysis of requirements on SA, and planning and risk management. We also propose three emergent hypotheses from this case study as a driver for future empirical work in RE. This case study involved examining the 10-year history of requirements and architecting decisions in several major components of the rail project. The data collected was from numerous project documents and extensive interviews with the developers and planners.

How do system architectures affect software requirements

While much research attention has been paid to transitioning from requirements to software architectures, relatively little attention has been paid to how new requirements are affected by an existing system architecture. Specifically, no scientific studies have been conducted on how a systems architecture affects software requirements; in particular, the “characteristics” of newly elicited requirements gathered in the presence of an existing architecture. This paper describes emerging results from an exploratory controlled study investigating such requirements characteristics.