«Abstract. Handshaking between product management and R&D is key to the success of product development projects. Traditional requirements engineering ...»
Handshaking between Software Projects and
Stakeholders Using Implementation Proposals
Samuel Fricker1,2, Tony Gorschek3, and Petri Myllyperkiö 4
1 ABB Switzerland Ltd., Corporate Research,
Segelhof, 5405 Baden-Daettwil, Switzerland
2 University of Zurich, Department of Informatics,
Binzmuehlestrasse 14, 8057 Zurich, Switzerland
3 Blekinge Institute of Technology, School of Engineering,
PO Box 520, 372 25 Ronneby, Sweden
email@example.com 4 ABB Oy, Distribution Automation B.O. Box 699, 65101 Vaasa, Finland firstname.lastname@example.org Abstract. Handshaking between product management and R&D is key to the success of product development projects. Traditional requirements engineering processes build on good quality requirements specifications, which typically are not achievable in practical circumstances, especially not in distributed devel- opment where daily communication cannot easily be achieved to support the understanding of the specification and tacit knowledge cannot easily be spread.
Projects thus risk misunderstanding requirements and are likely to deliver in- adequate solutions. This paper presents an approach that uses downstream en- gineering artifacts, design decisions, to improve upstream information, a pro- ject’s requirements. During its preliminary validation, the approach yielded promising results. It is well suited for distributed software projects, where the negotiation on requirements and solution design need to be made explicit and potential problems and misunderstandings caught at early stages.
1 Introduction Distributed multi-site product development is increasingly becoming commonplace as companies become global not only in terms of customer base, but also with regards to large parts of the product development that is spread over continents and cultures.
Distribution enables companies to leverage their resources and to draw on the advan- tage of proximity to customers and markets for large-scale product development .
The potential opportunities, however, also come with new challenges that affect both product management and product development of a company, and the require- ments engineering of products. The threat of defect increase and cost overruns in multi-site development has been documented in literature and industry experience reports. Some of the main problems are attributed to heterogeneous understanding of requirements, and substantial differences in domain understanding and interpretation [2-4]. This is compounded by the fact that multi-site development usually is detrimental to informal communication between stakeholders, which include product managers, experts, and developers, as these roles are often separated geographically . Informal communication and face-to-face meetings often help in augmenting imperfect specifications by building a common understanding of what is to be done, by whom, and when, and indirectly passing on domain knowledge and other tacit information crucial to the development effort. The ability for developers to seek out and regularly communicate with domain experts is prohibited by distance: all communication is associated with administrative and planning overhead, resulting in an raised threshold for daily validation of specification interpretations . Cultural differences between sites can also lead to issues as some management styles prohibit developers from directly eliciting information: communication may be routed through one or a few central managers, further congesting communication .
A common result of these challenges is that defects, delays, and misunderstandings are caught very late, often during system integration. This dramatically increases the whole product development effort and is detrimental to time-to-market, which is recognized as one of the most important factors in market-driven development [5, 6].
In response to the challenges posed by distributed development this paper presents a technology developed in active collaboration with industry to alleviate some of the problems and enable explicit handshaking procedures between stakeholders. The technology, called implementation proposal, enables such handshaking by relating software design to requirements. It was primarily motivated by challenges identified at ABB, and relates to a case where large scale development was performed utilizing sites spread across North America, Europe, and Asia.
Implementation proposals and their proper use enable explicit communication between stakeholders at the critical phase of requirements interpretation, as well as mapping the implications of design decisions to the end product. In addition, the comparison of implementation proposals and requirements demands iteration until a joint understanding of requirements and domain implications can be reached. A positive spin-off effect is that requirements deliverers, e.g. product managers, are able to gauge the impact on system architecture early in the process.
The focus of this paper is on presenting the implementation proposal technology and the organizational and process implications that follow the utilization of the technology. The experiences of using implementation proposals are based on a pilot currently underway in a large scale development effort at ABB.
The paper is structured as follows. Section 2 discusses the background and related work. In Section 3 the implementation proposal concept and handshaking process is presented and discussed. Section 4 presents early handshaking results. Section 5 positions handshaking with related literature. Section 6 concludes the paper.
Large scale distributed development demands management of physical distance, time zones, and the thin spread of domain and technology expertise, which impact requirements communication , and management of the overall solution architecture with multiple levels of product integration.
Key principles that are applied to manage these issues include allocation of responsibility for well-separated components of the software solution to various teams, ownership of such a team for the overall lifecycle of their contribution, a globally accessible requirements and configuration management infrastructure, and project roles and practices that enable critical communication to happen among the teams as well as between the teams and product management, project management, and architects.
The application of these principles leads to an organizational structure that is aligned either with the structure of the software product and its related domains  or with the overall development process with different roles located at different places.
Fig. 1 illustrates one such an alignment in a stylized and simplified manner that can be observed in ABB as it relates to the case presented in this paper.
Fig. 1. Alignment of organizational structure with the structure of the software product and its related domains.
In Fig. 1, product management is responsible for a software product’s markets and application domains and formulates relevant requirements, which are handed over to a software architecture team. The software architects, responsible for the overall architecture of the software product, communicate requirements to development teams, which are responsible for the development of the components assigned to them. Those components, finally, are integrated to form the software product, which after verification and validation gets deployed into the targeted application domains and markets.
There are several ways to handle the division of work and organizational structure with regards to distributed development [4, 7]. First, the case of hand-off can be seen in Fig.1, where different process steps are performed at different levels in the organization. Every such process step results in a deliverable that is handed down, like the requirements from product management to the architecture team. This implies that the deliverables have to be transferred across sites. Such a hand-off between sites can cause many of the issues discussed earlier in terms of heterogeneous understanding, and impossible compensation for imperfect deliverables due to lacking informal and day-to-day communication.
Second, the case of structural or functional division can be seen in Fig.1, where different parts of the product itself, i.e. some feature sets, are handled exclusively by one site. This implies that deliverables do not need to be transferred across sites, but are created and handed over locally. The main challenge is here to minimize coordination needs by a clear division of the product with low coupling between the parts that are distributed over sites. This is hard to achieve in practice.
In the ABB case hand-off challenges were predominant, even if some units on development level actually were organized according to product functions. The focus of this paper is on addressing the challenges to this type of distributed organization.
Looking at work performed previously in relation to the problem at hand, several investigations have been conducted for identifying the main challenges and recommending solutions [1-3, 5, 6]. Commonly recurring themes are face-to-face meetings and communication between sites. Solutions include introducing requirements management platforms for global access to requirements, employing communication technologies like chat, persistent video- and teleconferencing for enhanced communication, shared project workspaces, and configuration management systems.
A central issue was not only to address the problems of requirements understanding and communication, but also to find a technology that would enable explicit mapping of design decisions to the product requirements. Product management was the main author of requirements at early stages of the product development project and a central source of domain knowledge. However, the time available to product management for communicating requirements and for validating design decisions was limited. Thus, the communication between product management and the architecture team had to be explicit and concrete enough to avoid misunderstandings despite hand-off over sites, and efficient enough to make good use of time spent.
Traditional communication and face-to-face meetings are well established practices at ABB, as are the utilization of CASE tools over sites. However, the fundamental limitations of not being a team in one location demanded additional steps to be taken to ensure that a common understanding had been reached. One important goal was to increase the efficiency and effectiveness of the limited number of meetings by having relevant decision support material created beforehand as a part of the practices. This involved the creation of artefacts that would increase traceability between design decisions and requirements, the two main constituents of architectural impact.
3 Implementation Proposal Concept and Handshaking Process
It is well accepted that requirements are tightly linked to solution design. This holds for requirements and design decisions at any level of abstraction. This section elaborates on this relationship for the purposes of requirements communication and negotiation on an appropriate implementation approach by describing the structure and possible forms of implementation proposals and their relationships to requirements.
The relationship between requirements and solution design is bidirectional. Not only context and goals affect the design of a software solution, but also the emerging capabilities of the solution influences what goals can be achieved and how effective usage of the software shall be structured . The impact of a targeted software solution on its context is particularly important to consider in situations with limited engineering resources, with limited capabilities of technology, and in projects that are building on legacy, as these factors pose demands on architecture and design regarding feasibility. The impact of a software solution is also important to consider, when errors have been introduced in the design, due to imperfect understanding of requirements for example, which cannot be corrected with given project resources and deadlines, resulting in quality deficiencies and cost overruns.
3.1 Implementation Proposals
Implementation proposals support the negotiation between requirements and solution providers, as shown in Fig. 2. The requirements provider, a stakeholder or customer that is responsible for a problem domain, contracts a solution provider to realize a software solution. The solution provider, the supplier or development team, is responsible for creating a software solution that satisfies the requirements.
Fig. 2. Communication between requirements and solution providers through requirements and implementation proposals.
Solely focusing on requirements during negotiations is not enough as requirements are often misunderstood and the impact of feasible architecture and design is largely ignored. To mitigate these risks, implementation proposals are introduced. Implementation proposals describe the targeted solution and its expected impact from the perspective of the supplier. As Fig. 2 illustrates, implementation proposals are an answer to requirements and flow from the solution provider to the requirements provider.
The situation described in Fig. 2 appears often in product development at ABB.
Referring to Fig. 1, the interaction pattern is of relevance between product management, the requirements provider, and the software architecture team, the solution provider, who need to coordinate the development of the overall software product. The pattern is also of relevance between the software architecture team, which now becomes the requirements provider, and every development team, the solution providers, that are responsible for the various software components. Not shown in Fig. 1 are the likely interactions between product management, the requirements provider, and some of the development teams, the solution providers, for coordinating lower-level requirements for design of externally visible software components.