Non-functional requirements that affect architecture Decision-Making

This article was first published by IEEE software and is now presented to you by infoq and IEEE Computer Society.

In software engineering, there is a close relationship between nonfunctional requirements and software architecture (SAS. As early as 1994, Rick kazman and Len bass affirmed that there was a close relationship between software architecture and non-functional requirements. 1. This idea has been popular in the software development field for many years. It also explains why development projects need to invest heavily in implementing non-functional requirements. 2

This general point of view is more specific when we recognize how the concept of software architecture evolves from a simple structural representation to a decision-making perspective. 3. From the perspective of decision-making, non-functional requirements are the criteria for selecting various design schemes. 4. For example, in terms of maintainability or portability, a hierarchical architecture style is required. In terms of efficiency, a dedicated database technology is required.

 

Software architects must continuously respond to non-functional requirements when performing software architecture design tasks. They must understand the non-functional requirements of the system and the impact of architecture decision-making on the realization of these non-functional requirements. In this article, we will introduce an empirical study that reveals the practices of software architects in coping with non-functional requirements in the decision-making process. This study is based on a survey activity that consists of two groups. First, we analyze non-functional requirements from the engineering perspective, especially the relationship with the three types of requirement engineering activities (acquisition, documentation and verification. Then, we thoroughly studied how non-functional requirements affect architecture decision-making.

Research

For the same software project, we have organized semi-structured interviews (semi-structured interviews) for multiple times. The interviewees are all the software architects who have participated in the project. Compared with other qualitative research strategies (such as structured surveys), semi-structured interviews are more flexible, allowing us to better study the problems that arise in conversations. In addition, we limit the scope of discussion to a single software project, rather than considering general architecture principles, which helps us better understand and evaluate background information. 5

Interviewees and institutions

This survey involves 13 interviewees from 12 software-intensive institutions that span different business and application fields (see table 1 ). Based on different business types, these organizations can be divided into three types:

 

• The software consulting company is mainly engaged in software development tasks for customers.
• The IT department is engaged in or outsourced software development tasks to meet internal requirements of the Organization.
• Software vendors develop and commercialize specific private solutions.

The functions and sizes of software projects involved in this survey are also different.

Although all interviewees perform architect duties in their respective projects, their institution does not have a specific software architect position. On the contrary, organizations select architects for each project based on technical knowledge or experience. Except for one, all other interviewees also serve as other roles (such as project managers, consultants, or developers ).

(Click to enlarge the image)

Interview implementation

We have created an interview guide for the interview and tested it through two researchers and two software architects to ensure its effectiveness. Then we pre-Send the interview guide to all the interviewees so that they can familiarize themselves with the interview topics and select a project for the interview. Interviews are conducted face-to-face, with each interview lasting about one hour. We recorded the interviews and then translated them into text for analysis. Then, we asked the interviewees to verify the transcript content. Sometimes, we explicitly request the interviewee to clarify some aspects. We used the nvivo software to evaluate the collected data. We classify all statements and words, and classify the statements and words that describe the same idea, action, or attribute into a group. Finally, we analyzed the data based on the organization and project features.

Limitations

We understand that our samples are not random, so they may not represent the broader software development community. Therefore, in an attempt to mitigate possible deviations, we asked organizations to select their own interviewees and allow them to select their own projects. We acknowledge that interviewees may be inclined to select more successful projects. To alleviate this problem, we explained to the interviewees that the study was not used to analyze best practices, but to understand how to do things. We promise to keep the feedback confidential. Most institutions are small and medium institutions, all from Spain. Of course, the survey results may be affected by the above factors. In addition, most of them are not projects in critical fields. No, this is not a major weakness because we try to use these projects to reveal industry practices, rather than proposing general theories.

How Should architects respond to non-functional requirements?

We asked software architects several specific questions about how they can obtain and document non-functional requirements and how they can be verified in the system. We believe that this is very important to understand the background of architects in making decisions in the project. For more information, see article 6. For the problem list, see. Since we are implementing semi-structured interviews, these questions are only for guidance, and interviews are promoted based on conversations. The topic about requirement acquisition, docalization, and verification naturally appears in the conversation.

Who is responsible for obtaining non-functional requirements?

The purpose of requirement acquisition is to obtain and refine system requirements from stakeholders. Both researchers and practitioners agree that demand acquisition is the most challenging part of the demand project. There are many technologies dedicated to precisely expressing demand without ambiguity, such as research and creative seminars.

These technologies assume that customer stakeholders (end users, managers, etc.) will contribute a lot in demand acquisition. In terms of functional requirements, some interviewees agree with this assumption. For example, the interviewee A said: "[business analysts] write a detailed document to reflect all [functional] needs ".?

However, this assumption is not true for non-functional requirements. In our survey, there were 10 projects where software architects were the main sources of non-functional requirements. Some customers have never mentioned non-functional requirements. Interview subject e said: "[Customer] never mentioned the requirement that the webpage loading time cannot exceed 2 seconds, but he complained about it later ." The interviewee L2 said: "The customer mentioned a basic [non-functional requirement] And then supplemented it based on our own experience "."

This value has exceeded the ratio (60%) that the architect mentioned by Uwe Van Heesch and Paris avgeriou significantly involved in requirement acquisition ). 7

The organizations where only the interviewees D, H, and I are located are obtained by the customer to lead non-functional requirements. Interestingly, only the projects of these organizations are outsourced (the manager is an Aviation Industry Company, a software company, and a bank ). This situation is caused by the subordination between institutions. However, in these cases, architects still play a positive role in defining non-functional requirements. "Our customer is an Aviation System Department, so all non-functional requirements are well defined," said D, the interviewee. In addition, we need to add some non-functional requirements based on our experience .?"

How to obtain non-functional requirements?

The unpredictable features of non-functional requirements make it difficult to obtain them in advance. According to this general opinion, all the interviewees agree that the acquisition of non-functional requirements is an iterative process and must span the entire system lifecycle. This is because before reaching an important stage (usually a prototype), it may not be easy to put forward expectations for part of the system's behavior. Interview object J said: "We first determine some related non-functional requirements, such as compatibility with other systems, and then develop a prototype and analyze other candidate solutions ."?
In addition, we cannot fully consider non-functional requirements before the first development. They need corrective maintenance to correct incorrect behaviors that do not meet expectations. "In terms of efficiency, we must make a change because there was no requirement for service levels at the beginning of the project," K said ."? This is reasonable. Some non-functional requirements (such as security) can be fully checked only when the system is deployed in the target environment or unexpected occurrence.

How to archive non-functional requirements?

In order to make archive more effective, academia and standardization organizations have put forward many expressions and templates for Compiling System Requirement Specification. However, nine out of the 13 interviewees admitted that they did not archive non-functional requirements. "[Functional requirements] are expressed using UML, conceptual models, and use cases, but have never heard of non-functional requirements," said H, An interviewee ." Some interviewees said that archive is necessary only when the customer needs or items are in a critical field. Four Interviewees indicated that they explicitly recorded non-functional requirements. The subject of the interview D is located in a domain-specific language ). "Because we work in the aviation field, we must clearly express non-functional requirements in a verifiable manner. We have dedicated templates that we use different technologies from other engineering fields (such as risk models and Fault Tree )." Two interviewees said they used natural languages with a certain structure to record non-functional requirements. Interview object B uses the volere requirement template (which provides a highly structured requirement template), and interview object K uses plain text that complies with the ISO/IEC 9126 quality model.

Interview object J only uses plain text documents. Only the interviewees B and D are constantly maintaining the requirement documents; J and K only record the initial non-functional requirements. K, the interviewee, said: "At first, we wrote down some ideas about non-functional requirements in natural language ,... however, we did not follow them and there were no new non-functional requirements in the design process." It seems natural that there is a relationship between measurable and continuous (or at least regular) record updates. However, further research is required to confirm whether the relationship exists.

Therefore, we can see that many non-functional requirements are self-evident and even hidden. Archiving them will cause serious damage to accuracy and timeliness. This situation can be explained by cost and benefit. The interviewee C bluntly said: "I almost didn't archive the project properly, mainly because it consumes too much money ." If practitioners do not feel the benefits, non-functional requirements will remain elusive.

How to verify non-functional requirements in the system?

It is difficult to verify that the system behavior meets non-functional requirements. There are differences between different non-functional requirements, so the corresponding verification methods are also different. However, 11 interviewees said that all non-functional requirements were met in the project, although there was always room for improvement. However, when we asked how to validate non-functional requirements, their answers were vague. The interviewee D said: "For some [not all] non-functional requirements, we only informal discussions with the customer as it is not easy to test. "Therefore, we need to distinguish ourselves from true verification to meet non-functional needs (as the 11-bit (85%) in the interviewees) (eight (61%) in the interviewees) some types of non-functional requirements are verified ). (This is commensurate with 60% of the previous studies. 8)

The eight interviewees performed some non-functional requirements verification, but only one to three. They only consider the following types of non-functional requirements.

• Performance efficiency. "We conduct performance evaluation through load and stress tests," said H, the interviewee ."?
• Correctness. Interview object a said: "We invest an hour to test every coding hour ."?
• Ease of use. "We created a prototype to ensure that the customer is satisfied with the user interface," K said ."?
• Reliability. The interviewee J said: "We forcibly introduce some errors to see what happens in the system and whether data will be lost ."?

Security, as a very important non-functional requirement, is not mentioned by all interviewees. Interview object F describes an extreme example of not doing verification: "When customers complain, they will find the problem ." Although this is an unsatisfactory response, it once again reflects this (just like archiving): Out of budget and time considerations, engineering practices may not work in the ideal way.

In stark contrast, interview object d uses a formal method based on statistical analysis and simulation to check the reliability of the system. Of course, this is expected because their project involves information systems in the aerospace industry and is a critical field. Previous studies have found that the evaluation method is related to the evaluation objectives. 9 our findings coincide with them.

We have a discovery that may be consistent with the results of previous studies, that is, the relationship between archiving and verification. As Andreas Borg and colleagues have said, "If you use words that are not measurable to express your needs, testing will take a lot of time, and even cannot be tested at all ." 10 only two interviewees use measurable methods to express non-functional requirements, which may be one of the reasons for the overall low level of verification.

How does a non-functional requirement affect architecture decision-making?

Unexpectedly, all interviewees agreed that non-functional requirements would affect their decision-making. However, their specific answers reflect some nuances.

Decision type

Non-functional requirements affect four types of decisions.

Architecture Mode

For a given type of project, most of the interviewees naturally choose a hierarchy, although some of them explicitly give reasons for decision-making. "We adopt a layered architecture because it allows future changes," J said ."?

Implementation Policy

Some types of requirements may require specific architecture-level policies. It can be a general design decision (for example, the interviewee L1 says "We use single sign-on to enhance the integration of subsystems "), it can also be specific decisions on individual components (for example, the interviewee A says "we create copies for database tables because the access time is too long ").?

Horizontal Decision-Making

Some non-functional requirements will affect the overall architecture. "We prefer to use the technology we already have," said L1, the interviewee ." A recurring problem is the use of third-party components, especially open source software (OSS. "Out of maintainability, we want to obtain the source code, so we chose the open source software solution," said D ."?

Technical platform

Non-functional requirements may be met by choosing the right database or middleware. In this case, they may affect the entire system. "We need high availability (availability), and only oracle can ensure this," said K, An interviewee ." Non-functional requirements may also be local. "One query is directly implemented through JDBC (joint database connectivity), so Hibernate is not used for efficiency reasons," said H, An interviewee ."?

Different decision making processes

In this survey, we found a special aspect of decision making, that is, the interweaving of technical decisions and other decisions. We have heard three different feedbacks. According to four interviewees, non-technical decisions are preferred. The interview told Xiang C: "architects should select appropriate technologies in the previously designed logical structure ." The other four interviewees said that major technical decisions are preferred, and later decisions should be matched. "Customers impose some restrictions on us. For example, the architecture must be based on open source software (OSS) and Java," said H, An interviewee ." The other five interviewees believe that technical decisions and other decisions are cross-cutting and affect each other. They can be seen as a local dual-peak model at the architectural design level. 11

Impact degree

We asked the interviewees about the non-functional requirements they would consider when making architecture decisions. We use ISO/IEC 25000 quality standards as a unified framework to summarize their answers as follows.

Explicitness)

Obviously, architects expect certain non-functional requirements, even if they are not explicitly listed as requirements. "I will not consider an insecure system," said the interviewee ." Due to the current features of the technologies and platforms used, these self-evident non-functional requirements often come to the architect's mind. "We will not consider document security because it is the responsibility of the SharePoint management system," said e, the interviewee ."?

Source)

Some requirements come directly from the development team or architect. "We are the people who want to maintain this system in the future. Therefore, it is important for us to ensure the maintainability of this system," said B ." Compared with non-functional requirements from customers, these non-functional requirements from the development team are closer to the architecture decision-making process, because the technicians think about the solution, the customer is problem-oriented.

Nontechnicality)

Non-technical non-functional requirements (NFR) are those that are not directly related to the internal quality of the software but are related to the system environment, such as licenses or costs. 12 architects should consider these basic factors. According to the interviewees, about 40% of all non-functional requirements are non-technical. Sometimes they take these needs into consideration with the highest priority. The interviewee J said: "cost is the first, and everything else has to obey it ."?

Importance)

We asked the interviewees which type of non-functional requirements were the most important. License issues, ease of use, reliability, performance efficiency, and maintainability are the most mentioned. Only two interviewees mentioned portability. We checked the information with the Decision-Making case mentioned in the interview. We found that the performance efficiency and maintainability had the greatest impact on decision-making.

Terminology issues)

When discussing non-functional requirements with the interviewees, we encountered some technical issues. Some interviewees request supplementary interpretations of terms, such as "availability" and "accuracy )". Other interviewees mistakenly use terms in a given context. For example, they use ergonomics to express "ease of use ". Some interviewees even adopt incorrect definitions, such as "maintainability", which is very important because we cannot modify the running system ." Another common problem is obfuscation of performance and efficiency )". ISO/IEC 25000 defines performance efficiency as "performance relative to the number of resources used under certain conditions ".?" 13. This definition helps us to remove confusion.

To check whether the observed results in the study are valid, we launched a new study with some large IT enterprises. We hope to see improvements in docalization and verification, and, if possible, change in the degree of re-view of various non-functional requirements. We also want to study whether to clearly express the relationship between non-functional requirements and architecture decision-making (for example, considering the trade-offs and the alternatives, what is the impact on the final system architecture decision-making. For more information about this topic, see below.

Thank you

We are very grateful to the participants in this topic for their time and contributions. This topic is funded by the Spanish project TIN2010-19130-C02-01.

References

1. R. kazman and L. Bass, toward deriving software ubuntures from quality attributes, tech. Report CMU/SEI-94-TR-10, software Eng. Inst., Carnegie Mellon Univ., 1994.
2. F. buschmann, "value-focused system quality ,?" IEEE software, vol. 27, No. 6, 2010, pp.84.86.
3. P. kruchten, R. Capilla, and j.c. duenas, "The demo-view? FS role in software architecture practice ,?" IEEE software, vol. 26, No. 2, 2009, pp. 36.42.
4. L. Chung and j.c. S. do Prado Leite ,?" On non-functional requirements in software engineering ,?" Conceptual Modeling: foundations and applications, a.t. borgida et al., eds., Springer, 2009, pp. 363.379.
5. R. conradi et al .,?" Reflections on conducting an international survey on software engineering ,?" Proc. Int? FL Symp. Empirical software Eng., IEEE, 2005, pp. 214.223.
6. D. Ameller et al .,? Ghow do software into ts consider non-functional requirements: an exploratory study ,? H Proc. 20th IEEE Int 'l requirements Eng. conf., IEEE, 2012, pp.41.50.
7. U. Van Heesch and P. avgeriou, "mature indexing Ting-A survey about the reasoning process of professional sort ts ,?" Proc.9th working IEEE/ifip Conf. Software Architecture (wicsa 11), ieee cs, 2011, pp.260.269.
8. R. B. Svensson, T. gorschek, and B. regnell, "quality requirements in practice: An Interview Study in Requirements engineering for embedded systems ,?" Requirements engineering: Foundation for software quality, lncs 5512, Springer, 2009, pp. 218.232.
9. M. Ali Babar, L. Bass, And I. Gorton ,? "Factors influencing industrial practices of software architecture evaluation: An Empirical Investigation" software ubuntures, components, and applications, lncs 4880, Springer, 2007, pp. 90.107.
10. A. Borg et al .,? "The bad conscience of Requirements engineering: An Investigation in real-world treatment of non-functional requirements ,?" Proc. 3rd Conf. Software Eng. Research and Practice in Sweden (serp 03), csrea Press, 2003, pp. 1.8.
11. B. nuseibeh, "Weaving Together requirements and ubuntures", vol. 34, no. 3, 2001, pp. 115.119.
12. J.p. Carvallo and X. Franch, "" extending the ISO/IEC 9126-1 Quality Model with non-technical factors for COTS components selection ,? H Proc. Int? FL workshop software quality (wosq 06), ACM, 2006, pp. 9.14.
13. Software Engineering. Software Product quality requirements and Evaluation (square). Guide to square, ISO/IEC 25000, International org. for standardization, 2005.

Non-functional requirements

Although there are not many studies, we try to summarize the results of empirical studies on non-functional demand. Richard svenssion and his colleagues described 18 studies related to our proposal. 1. However, these studies did not involve the relationship between non-functional requirements and architecture decision-making. Most of their research focuses on non-functional requirements (NFR), while other researchers have made more in-depth exploration of software architecture (SA) issues; uwe Van Heesch and Paris averiou specifically research the relationship between non-functional requirements and software architecture. 2

Some of our observations are consistent with previous findings-for example, software architects often assume other responsibilities. No other observations have been published. For example, participants in this project will think that non-functional requirements (NFR) have met the requirements only when simple verification is performed. Some of our observations are different from previous studies. For example, we found that non-functional requirements have poor scalability, which is different from the previous cases. 3. We also analyzed the impact of different types of non-functional requirements. We found that this is similar to the previous research. For example, Jose de la VARA and his colleagues listed efficiency and ease of use as the most important factor. 4. However, our research results are a little less rigorous. First, this topic uses different types of non-functional requirements. In addition, the responsibilities involved are often different, so the types of non-functional requirements are also different. 1

References

1. R. B. Svensson, M. host, and B. regnell ,? Gmanaging quality requirements: A Systematic Review ,? H Proc. 36th euromicro Conf. Software Eng. and advanced applications (SEAA 10), ieee cs, 2010, pp. 261.268.
2. U. Van Heesch and P. avgeriou ,? "Mature privacy ting. A survey about the reasoning process of professional certification ts", Proc. 2011 9th working IEEE/ifip Conf. Software Architecture (wicsa 11), ieee cs, 2011, pp.260.269.
3. A. Borg et al., "? The bad conscience of Requirements engineering: An Investigation in real-world treatment of non-functional requirements ", Proc. 3rd Conf. software Eng. research and Practice in Sweden (serp 03), csrea Press, 2003, pp. 1.8.
4. J. L. de la Vara et al., "an empirical study on the importance of quality requirements in industry ,?" Proc. 23rd Int? FL Conf. Software Eng. And knowledge Eng. (seke 11), knowledge systems Inst. Graduate School, 2011, pp. 438.443.

Author Profile

David AmellerHe is a Ph.D. student at barcelonatech-Universitat politecnica de Catalunya. He is a member of the software engineering for Information Systems Research Group. His research interests include software architecture and demand engineering. Ameller earned a master's degree in computer science from the University of Science and Technology of Guatemala. The contact information is [email protected].

 

Kradia AyalaHe is a researcher and lecturer at onatech-Universitat politecnica de Catalunya. She is a senior member of the software engineering for Information Systems Research Group. Her research interests include demand engineering, software architecture, and open source software. Ayala earned a doctorate degree in computer science from the University of Science and Technology of Guatemala. Her contact information is [email protected].

 

Jordi CabotHe works at the Ecole des Mines de Nantes Institute of Mining, France, and leads the INRIA study group in Atlanta. His research interests include model-driven engineering, software modernization, and formal verification. Cabot earned a degree in computer science from the University of Science and Technology of Catalunya. He is an IEEE member and an ACM member. Contact him here.

 

Xavier FranchAssociate Professor at onatech-Universitat politecnica de Catalunya. He is the research lead of the research team of Software Engineering for information systems. His research interests include demand engineering, software architecture, and open source software. Franch earned a doctorate degree in computer science from the University of Science and Technology of Catalunya. Contact Method: [email protected].

 

This article was first published in IEEE software. IEEE software aims to deliver reliable, useful, and cutting-edge software development information to leading and future software practitioners, helping engineers and managers keep up with fast-paced technological changes.

Non-functional requirements that affect architecture Decision-Making