Context: System of systems (SOS) is a set or arrangement of systems that results when independent and useful systems are to be incorporated into a larger system that delivers unique capabilities. Our investigation showed that the development life cycle (i.e. the activities transforming requirements into design, code, test cases, and releases) in SoS is more prone to bottlenecks in comparison to single systems. Objective: The objective of the research is to identify reasons for bottlenecks in SoS, prioritize their significance according to their effect on bottlenecks, and compare them with respect to different roles and different perspectives, i.e. SoS view (concerned with integration of systems), and systems view (concerned with system development and delivery). Method: The research method used is a case study at Ericsson AB. Results: Results show that the most significant reasons for bottlenecks are related to requirements engineering. All the different roles agree on the significance of requirements related factors. However, there are also disagreements between the roles, in particular with respect to quality related reasons. Quality related hinders are primarily observed and highly prioritized by quality assurance responsibles. Furthermore, SoS view and system view perceive different hinders, and prioritize them differently. Conclusion: We conclude that solutions for requirements engineering in SoS context are needed, quality awareness in the organization has to be achieved end to end, and views between SoS and system view need to be aligned to avoid sub optimization in improvements.

In software intensive products such as cars or telecom systems, software has traditionally been associated with cost, and there has been no real perception of its value in relation to the entire product offering. However, because software is becoming a larger part of the main competitive advantage, driving innovation and product differentiation, hardware is becoming more standardized, thus the valuation of software is becoming critical. In existing literature, several value constructs and corresponding valuation/measurement solutions needed for making decisions about software product development are presented. However, the contributions are often isolated with respect to a certain perspective such as focusing on product's internal or external quality aspects only. Consequently, a complete view of value constructs relevant from different perspectives required for making decisions about software product development is missing. This paper presents a consolidated view of the software value concept utilizing the major perspectives and introduces a software value map. The created value map was evaluated through an industry case study through the development of impact evaluation patterns, which were subsequently used by professionals in industry, and experiences gathered. During industry evaluation, practitioners found substantial benefits of having a consolidated, vastly improved, and extended value aspect's view of software. Copyright © 2012 John Wiley & Sons, Ltd.

Software product managers are missing guidelines on how to incorporate di erent dimensions of sustainability in software product management and requirements selection decision-making. This is a challenge because considering sustainability perspective while selecting requirements has become a major objective for software product development companies; however, it is unclear how to support it during complex product management decision-making. In this paper, we identify the value aspects related to sustainability for software requirements selection. An exemplary dialogue between a consultant and a product manager illustrates how the proposed approach can be used while taking product management and requirements selection decisions. Our contribution provides software product managers with guidance on how toincorporate value aspects related to sustainability while taking software product management and requirements selection decisions.

Sustaining innovation in a fast growing software development company is difficult. As organisations grow, peoples' focus often changes from the big picture of the product being developed to the specific role they fill. This paper presents two complementary approaches that were successfully used to support continued developer-driven innovation in a rapidly growing Australian agile software development company. The method "FedEx TM Day" gives developers one day to showcase a proof of concept they believe should be part of the product, while the method "20% Time" allows more ambitious projects to be undertaken. Given the right setting and management support, the two approaches can support and improve bottom-up innovation in organizations.

Rubrics and oral feedback are approaches to help students improve performance and meet learning outcomes. However, their effect on the actual improvement achieved is inconclusive. This paper evaluates the effect of rubrics and oral feedback on student learning outcomes. An experiment was conducted in a software engineering course on requirements engineering, using the two approaches in course assignments. Both approaches led to statistically significant improvements, though no material improvement (i.e., a change by more than one grade) was achieved. The rubrics led to a significant decrease in the number of complaints and questions regarding grades.

Software requirement triage and selection in market- driven requirements engineering is a crucial activity for the success of a project, product and company. This paper presents state-of-the- art and state-of-practice in requirements triage and selection through systematic literature review and an industrial survey. Industry practitioner can read solutions that have been proposed in literature and most applicable challenges and factors considered today and factors to be considered ideally to address the challenges, which have been collected through the survey. For researchers, the results show which challenges still needs to be addressed.