Some believe that Requirements Engineering (RE) for a computer-based system (CBS) should be done upfront, producing a complete requirements specification before any of the CBS’s software is written. A common complaint is that (1) new requirements never stop coming; so upfront RE goes on forever with an ever growing scope. However, data show that (2) the cost to modify written software to include a new requirement is at least 10 times the cost of writing the software with the requirement included from the start; so upfront RE saves development costs, particularly if the new requirement is one that was needed to prevent a failure of the implementation of a requirement already included in the scope. The scope of a CBS is the set of requirements that drive the CBS’s implementation. We believe that both (1) and (2) are correct, but each is about a different category of requirements, (1) scope determininG (G) or (2) scope determineD (D), respectively. Reexamination of the reported data of some past case studies through the lens of these categories indicates that when a project fails, a large majority of its defects were due to missing D requirements, and when a project succeeds, the project focused its RE on finding all of its D requirements. The hypothesis that waterfall methods (WMs), with their upfront RE, do a better job of avoiding missing D requirements in developing CBSs than do agile methods (AMs) was not supported by the data from 8 WM projects and 8 similar AM projects in one company. In fact, the null hypothesis, that there is no difference between WMs and AMs in avoiding missing D requirements in developing CBSs, cannot be rejected for any logically posssible assignment of the collective data from the 16 projects to 16 specific projects. It appears that intimate knowledge of the domain and development of a CBS is necessary to be able to classify the CBS’s defects arising from missing requirements as of category D or G with respect to (w.r.t.) the CBS’s scope. Finally, software and requirement engineers are able to learn from a half-hour lecture about D and G requirements to correctly categorize most requirements of a familiar CBS as D or G, w.r.t. the CBS’s scope.

Requirement elicitation can be done by individuals or by groups. Computer-based system development life-cycle models suggest having people working together for many steps. Also, recommendations about analysis and design methods indicate that some processes could take advantage of group work. In requirements engineering, groups are suggested for requirements elicitation. From the software and the requirements engineering viewpoints, and in turn for companies, a relevant overall research question is “What is a suitable size for a requirements elicitation group?” Our goal was to answer this question, first by looking for available guidelines in textbooks and secondly by investigating requirements elicitation in companies. To address the research question, we conducted two studies. The first was a review of most widely adopted software and requirements engineering textbooks. The second was a study aimed at identifying factors affecting group size for requirements elicitation, based on an online questionnaire submitted to professional analysts. The review of the textbooks showed that very few give advice on the number of analysts to involve in requirements elicitation sessions. When they do, guidelines are quite general and not supported by empirical data. According to data gathered from the questionnaire, most companies use and suggest using small groups. Data also allowed identifying four categories of factors useful to make decisions about requirements elicitation group sizes: people, relation, project, and output. Both the textbook review and the data from the questionnaire say that it is better to aim for small groups than to have individual analysts working separately. The ideal number of analysts for a requirements elicitation session appears to be 2, but large groups are necessary in some cases. Factors in all the four categories have to be considered in deciding the size of groups.

The research presented in this article deals with the difficulties and mental processes involved in the definition, implementation, and use of abstract data types encountered by 12 th grade advanced-level computer science students. Research findings are interpreted within the theoretical framework of reducing abstraction [Hazzan 1999]. The article describes the research setting and findings and concludes with some pedagogical implementations.

This paper discusses the suitability of the qualitative research approach to computer science education research. It is based on the following two observations: First, only a small proportion of works presented in the computer science education literature contain some experimental component (Fincher and Petre, 2004; Valentine, 2004). Second, those research works conducted in computer science education that do, usually employ a quantitative research approach. This paper focuses on the qualitative research approach, presenting its nature, discussing its relationships to the quantitative research approach and addressing its application in general and in the context of computer science education in particular.