1. Motivation: collaboration in engineering design
Collaboration is a fundamental aspect of engineering design, enabling the integration of diverse perspectives, expertise, and skills to solve complex problems (Reference Kleinsmann, Deken, Dong and LaucheKleinsmann et al., 2012a; Reference O’Shields and SummersO’Shields & Summers, 2018; Reference Ostergaard and SummersOstergaard & Summers, 2009). Engineering design is described as a complex social activity, the complexity of which is mitigated through the systematic sequencing of activities and the integration of many actors to ensure coverage of view (collaboration) (Reference Milne and LeiferMilne & Leifer, 1999). Engineering design is inherently social, systematic, and creative, thus effective teamwork is essential throughout the stages of problem-solving, from identifying needs to implementing solutions (Reference Dym and LittleDym & Little, 2004; Reference Otto and WoodOtto & Wood, 2001; Reference Pahl, Beitz, Blessing, Feldhusen, Grote and WallacePahl et al., 2013; Reference Ullman, Summers and FieldingUllman et al., 2024). While the significance of collaboration is widely recognized, the understanding of how team size influences collaborative design remains limited, especially in the context of requirements generation (Reference Weiss and HoeglWeiss & Hoegl, 2016). Team size, when combined with various mechanisms, influences team creativity, output quality, and efficiency, three key dimensions of team performance (Reference Weiss and HoeglWeiss & Hoegl, 2016). Further, team size can have distinct impacts on the performance of teams engaged in innovative tasks.
What is not fully understood is how team size relates to performance for engineering design activities. Team size was studied as a factor in a large design competition (Robots to the Rescue) with 101 teams of sizes ranging from 4 to 32 participants (Reference Deng, Marion and OlechowskiDeng et al., 2022). It was found that team size had an influence on points garnered. The team size correlated with the number of actions and the occurrences of individuals opening an already open CAD document, both of which can be explained simply by the increase in the number of individuals on the team. The Wisdom of Crowds suggests that with a well-designed crowd (diverse, independent, and large), collective understanding and decision making can be improved against an individual’s actions (Reference SurowieckiSurowiecki, 2005).
The objective of this paper is to investigate the relationship between team size and the quantity of requirements generated during the early stages of engineering design. By examining how variations in team size impact the collaborative process, researchers seek to provide insights into optimizing team composition for effective requirement generation. Specifically, the research will explore how team size influences factors such as communication, coordination, knowledge sharing, and decision-making, which are critical for generating comprehensive and high-quality requirements. Understanding these dynamics will enable engineers and project managers to make informed decisions about team size and structure to maximize the effectiveness of collaborative design efforts
2. Background
Requirements ensures designs with stakeholder needs but capturing clear and comprehensive requirements is often challenging. This section discusses the considerations of team size and how requirements are written.
2.1. Team size
Collaborative design plays a pivotal role in engineering complex systems, yet it also introduces significant challenges (Reference Grogan and WeckGrogan & de Weck, 2016). Research shows that while increasing team size could theoretically improve performance, perspectives from fields such as psychology, economics, and management suggest that larger teams may face diminishing returns due to communication overhead and other challenges (Reference Bernerth, Beus, Helmuth and BoydBernerth et al., 2023; Reference Grogan and WeckGrogan & de Weck, 2016; Reference Jacobs, Pfarr, Fazelpour, Koroma and MesfinJacobs et al., 2019; Reference Mao, Mason, Suri and WattsMao et al., 2016; Reference Staats, Milkman and FoxStaats et al., 2012). Larger teams tend to encounter difficulties such as conflicts, reduced cohesion, and performance declines due to anonymity, which may outweigh the benefits of diversity and skill sets. Therefore, the ideal team size remains a matter of ongoing research (Reference Jacobs, Pfarr, Fazelpour, Koroma and MesfinJacobs et al., 2019).
Some studies suggest an optimal team size between 5–10 individuals, but factors like task complexity, individual skills, and project-specific requirements influence the appropriate team size (Reference Akinola and AyinlaAkinola & Ayinla, 2014; Reference Mao, Mason, Suri and WattsMao et al., 2016; Reference Ostergaard and SummersOstergaard & Summers, 2009; Reference Sami, Kakolaki and TaghadosSami et al., 2019). Larger teams often lead to social loafing, where individuals contribute less, and coordination becomes more complex as the number of communication channels increases. In contrast, smaller teams tend to foster more efficient collaboration and communication due to fewer members and closer interpersonal connections (Reference Majalian, Kleinman and SerfatyMajalian et al., 1992). This results in faster decision-making and problem-solving but may limit the team's ability to address highly complex problems due to a lack of breadth in expertise (Reference Akinola and AyinlaAkinola & Ayinla, 2014).
Understanding the relationship between team size and performance in complex tasks is not straightforward. While larger teams offer advantages such as more resources and diverse perspectives, the challenges related to group dynamics, communication, and coordination must be carefully evaluated when selecting the most suitable team size for a project.
2.2. Generating requirements
Effective generating of requirements is essential in the engineering design process, particularly in the conceptual design phase, which significantly influences the overall success of a project (Reference Andreasen, Hansen and CashAndreasen et al., 2015). Clear and well-defined requirements serve as the foundation for guiding the design process and are refined throughout the project’s lifecycle. They help establish a shared understanding among the design team and stakeholders about the project’s goals, limitations, and scope (Reference Morkos, Mathieson and SummersLoucopoulos, 2005; Reference LoucopoulosMorkos et al., 2014). This shared understanding is critical for making informed decisions and avoiding misalignment between the team’s actions and the project's objectives (Reference LoucopoulosLoucopoulos, 2005).
Poorly defined requirements can lead to uncertainty, project delays, and design failures (Reference Joshi, Summers and MockoJoshi et al., 2012; Reference LoucopoulosLoucopoulos, 2005; Reference Mokammel, Coatanea, Christophe, Khouya and MedynaMokammel et al., 2014). Generating effective requirements reduces the risk of these issues by ensuring that all stakeholders have a clear vision of the project’s scope and objectives. Different organizations provide standards for writing these requirements, with INCOSE, IEEE, and NASA offering specific guidelines on what constitutes a “good” requirement (Institute of Electrical and Electronics Engineers (IEEE), 2018; International Council on Systems Engineering (INCOSE), 2023; National Aeronautical and Space Administration, 2016). These standards emphasize clarity, consistency, and specificity in the requirement statements to prevent ambiguity.
Requirements should be framed using precise language, such as the use of the word “shall” to indicate a mandatory requirement. Vague expressions like “many” or “a few” should be avoided, and each requirement should focus on a single quality, characteristic, or function. Furthermore, requirements must be realistic, verifiable, and feasible to ensure that they can be effectively tested or validated during the project’s execution (Institute of Electrical and Electronics Engineers (IEEE), 2018; International Council on Systems Engineering (INCOSE), 2023; National Aeronautical and Space Administration, 2016).
Organizations such as INCOSE, IEEE, and NASA have developed similar standards for writing requirements. These include structuring the requirement with a condition, subject, modal term (e.g., “shall”), verb phrase, and target value, as shown in Table 1. Additionally, modal terms describe the obligation or manner in which the requirement must be fulfilled (Reference Spivey, Ortiz, Patel, Davenport and SummersSpivey et al., 2021a). Consistency across all requirements and throughout the requirements document is critical to ensure clarity and prevent contradictions. In all the examples from NASA, INCOSE, and IEEE, key components such as the subject, modality, and verb phrase are consistently present.
Table 1. Comparison of requirements syntax
3. Experiment design
The research focuses on experimentally examining how team size affects the performance of engineering design teams during requirements generation. Conducted in a classroom setting, this study provides participants with a familiar and natural environment. This section outlines the approach to analyze how variations in team size influence the quantity of requirements generated during the problem definition phase.
3.1. Participants
The study followed an approved experimental protocol from the local Institutional Review Board, with no identified risks for participants. A total of 1,208 pre-service engineers (undergraduate mechanical engineers) participated across five sections of an introductory Engineering and Computer Science course at a large public research university in the United States. The course, a mandatory first-semester requirement for all engineering and computer science students, involved participants majoring in computer science, bioengineering, electrical engineering, or mechanical engineering. Approximately 80% of the participants identified as male, and 5% were international students. The majority of participants were aged 17 to 20. Demographic data were not collected due to the scope of the experiment.
The class sizes ranged from 170 to 300 students, all meeting in the same lecture hall on Tuesdays and Thursdays. Participants were instructed not to discuss the in-class activity with others. The experiment took place during regular class hours, and the lecture content was standardized across sections, with a guest lecture by the same researcher covering the importance of requirements in engineering design, requirements syntax, evaluation methods, common pitfalls, and stakeholder engagement. The lecture content is loosely based on (Reference Ullman, Summers and FieldingUllman et al., 2025).
Pre-service engineering students were selected to ensure a uniform baseline of engineering knowledge. Previous studies have shown that pre-service engineers perform comparably to practitioners with at least three years of experience in generating requirements (Reference ElenaElena, 2019). Furthermore, research has indicated no significant difference in the quality or technical feasibility of solutions produced by first-year and senior engineering students (Reference Genco, Otto and SeepersadGenco et al., 2012).
After the lecture, participants were given detailed instructions for the requirements generation task. They were provided with a design problem statement and had 20 minutes to generate requirements. The participants were given 20 minutes due to the limitation of the class time and the time it took to organize teams and deliver the lecture content. Their documents were collected at the end of the session, with independent observers monitoring the teams to ensure that each team collaborated internally within their group while remaining independent from other teams. The participant materials consisted of two sections: one for creating a unique identifier and another with instructions for the requirements generation task, along with the design problem prompt. Participants were asked to assume the role of engineers working at a design firm and tasked with generating requirements for a specific problem Figure 1 illustrates the participant packet.
Figure 1. Participant packet with prompt
3.2. Experiment variables
The study manipulates a single independent variable, team size, across three conditions: Teams of One, Teams of Three, and Teams of Six. Teams of One represent individuals working independently, while Teams of Three and Teams of Six represent smaller and larger groups, respectively. Although other variables such as communication styles, team culture, individual personalities, interpersonal dynamics, gender, and age could influence outcomes (Reference Ostergaard and SummersOstergaard & Summers, 2009), these factors are not the focus of this study. To minimize their impact, participants were randomly assigned to teams, reflecting the reality of diverse expertise in engineering teams.
Given the classroom setting, where participants are in close proximity, there is a risk that overhearing discussions from other teams could influence their requirements. To address this, two distinct design problem prompts are used: one for a bookshelf retrieval mechanism for wheelchair users and one for a bicycle safety lock. These prompts were adapted from a previous requirements generation study (Reference Spivey, Ortiz, Patel, Davenport and SummersSpivey et al., 2021a) and are outlined in Table 2. These two prompts have been evaluated for equivalency previously (Elena et al., Reference Elena, Patel and Summers2020).
Figure 2. Design prompts from (Reference Elena and SummersElena & Summers, 2019; Reference Spivey, Ortiz, Patel, Davenport and SummersSpivey et al., 2021b)
The data collected is in the form of requirements lists. The participant packet contains 21 rows for requirements to be written and participants were instructed to write on the back if they needed more room to write requirements. The quantity of requirements in the packet is the dependent variable of interest.
3.3. Requirement quantity
The quantity of requirements refers to the total number generated by the participant teams, serving as a metric for their ability to articulate a set of specifications. Quantity helps assess the teams' capacity for generating requirements and provides insights into the effects of team size in engineering design teams. A study was done tracking requirements evolution over eight design projects and its relation to project success in an engineering design course at a large public university. Results of the study suggest that a higher quantity of requirements improves the likelihood of project success (Reference Summers, Joshi and MorkosSummers et al., 2014). Another study looked at final reports from senior design classes collected over a ten-year period. The results of this study suggest that when the problem statement and requirements are lacking in detail, the final solution tends to reach, at most, a medium level of detail (Reference JoshiJoshi, 2010). Conversely, achieving a highly detailed final solution is more probable when the initial problem statement and requirements are of either high or medium detail. Furthermore, a highly detailed final solution is more likely to correspond with a higher percentage of requirements being fulfilled (Reference JoshiJoshi, 2010). Requirements are counted as single-thought statements based on established criteria (Reference Spivey, Ortiz, Patel, Davenport and SummersSpivey et al., 2021a).
For example, a requirement such as, “While in operation, the heat exchanger must cool the motor and remain under 60 decibels,” is split into two distinct requirements because it contains two separate clauses. The revised requirements are:
1. “While in operation, the heat exchanger must cool the motor.”
2. “While in operation, the heat exchanger must remain under 60 decibels.”
Requirements are split when they include multiple verbs describing actions, multiple adjectives characterizing the design or object, various objects being acted upon, or when a verb includes a modifier specifying how the action should be performed (Reference Spivey, Ortiz, Patel, Davenport and SummersSpivey et al., 2021a). Additionally, requirements are divided if they feature multiple modifiers to the object, conditional expressions linking two functions or characteristics, or distinct thoughts combined in one statement.
However, requirements are not split if (Reference Spivey, Ortiz, Patel, Davenport and SummersSpivey et al., 2021a):
-
a separate clause clarifies the purpose,
-
a single conditional applies to the object,
-
two mutually exclusive options are presented, or
-
two objects must coexist to fulfil the requirement
The complete coding scheme is available at (Reference SpiveySpivey, 2019). A complete list of criteria for splitting requirements is provided in Table 3.
Table 2. Criteria for splitting requirements
4. Results & discussions
The data analysis in this study followed a two-step process of ensuring homogeneity across course sections of the same team size and comparing requirement quantity across different team sizes (1, 3, and 6). To test for homogeneity across course sections of the same team size, six ANOVAs (α = 0.05) were performed across the four sections of the course, for each team size. The analysis revealed that for the Bookshelf prompt, Teams of One had a pair of sections with different variances (p-value<0.044). Similarly, for the Safety lock prompt, Teams of One had a pair of sections with different variances (sections 005 and 006, p-value<0.04). Similar trends were observed in Teams of Three, with two instances of variance differences. Teams of Six showed no significant differences across sections. Despite these minor variances, a closer examination of the ranges suggested that the differences were not substantial. The study concluded that there were no meaningful differences in the number of requirements generated by each team size across course sections.
The study tested three hypotheses:
-
There is no difference or Teams of Three generate fewer or the same number of requirements as Teams of Six;
-
There is no difference in the number of requirements generated between the groups being compared; and
-
Teams of One will generate more requirements than Teams of Three or Six.
The first section of the first-year general engineering course was used as a pilot to verify time allocation and thus excluded. This resulted in 944 participants from the initial 1,208 participants, and a total of 4,310 requirements. Table 4 provides an overview of requirements generation across different team sizes and prompts, showing the number of teams, initial and final counts, average requirements per team, and split requirements. While there is an imbalance in the number of teams, these are large compared to many other past collaborative studies of engineering design that typically include five to ten teams total (Reference Chartres, Gidel and MoulinChartres et al., 2023; Reference Kleinsmann, Deken, Dong and LaucheKleinsmann et al., 2012b; Reference Ostergaard, Wetmore, Divekar, Vitali and SummersOstergaard et al., 2005; Reference Wetmore, Summers and GreensteinWetmore III et al., 2010). The average number of requirements generated for the BS prompt is more for all team sizes than the average number of requirements generated for the SL prompt (by less than one requirement). The ratios of the split requirements are also similar. Thus, the prompts themselves appear to be similar.
Table 3. Number of split requirements
Statistical analysis using ANOVA (α = 0.05), both with and without outliers, confirmed no significant differences in the average number of requirements generated between Teams of One, Teams of Three, and Teams of Six (See Figure 2). However, a trend was observed: the average number of requirements generated decreased as team size increased. The average number of requirements generated went from 15.5 to 14.68 to 14.38 for Teams of One, Three, and Six, for the Bookshelf prompt, respectively. While for the Safety Lock prompt, the number of requirements went from 14.96 to 13.77 to 13.6 for Teams of One, Three, and Six, respectively. Teams of One had the highest average number of split requirements, on average 2.5 times more than the Teams of Three and Six, respectively. This implies that individual participants may have formulated more comprehensive or multi-functional requirements, while larger teams tended to decompose complex concepts into separate, more specific requirement statements.
Figure 3. Requirements generated across teams
5. Conclusion
The study's findings suggest that team size does not significantly affect the quantity of requirements generated. However, the trend of decreasing average requirements as team size increases warrants further investigation. Based on these results, it may be more beneficial to initially generate requirements individually and then merge them as a team. Further, if the “cost” of the collaboration is factored into the considerations, the efficiency of requirements generation is definitely higher for small teams.
One key limitation of this study is the method of counting requirements. The study counted a requirement if a verb was present, which may not fully capture the quality or depth of the requirements. For example, “low-cost” and “The design must cost under $1000 to manufacture” were both counted as single requirements, despite the latter providing more detailed information. In the future, researchers should evaluate the completeness of requirements, assessing whether they leave room for ambiguity or interpretation.
Future research should focus on comparing the variety of requirements across team sizes, examining the diversity and coverage of requirement categories. If a Team of One generates 21 requirements, but they are all related to the overall dimensionality of the product while a Team of Three generates seven requirements, but each covering a different aspect, such as maintenance, assembly, packaging, cost, operations, function, and durability, the Team of Three might have developed a better understanding of the problem. A simple count is not sufficient to measure the value of the results of the design activity. As with the quantity, quality, novelty, and variety metrics developed to compare idea generation techniques (Reference Shah, Kulkarni and Vargas-HernandezShah et al., 2000, Reference Shah, Smith and ndez2003), a similar set of metrics is needed to compare the team performance. Developing more nuanced methods for quantifying requirements that account for the depth and quality of information provided will be crucial. This study focused on a first analysis of the requirements generated, future research will study variety and completeness of the requirements.
These additional analyses will provide a more comprehensive understanding of the relationship between team size and the effectiveness of requirements generation in engineering design processes.
Open access
