Handshaking

Requirements communication is the process of conveying needs from a given customer to a given supplier that enables the supplier to implement a solution that is accepted by the customer.

Requirements communication is challenging. How should a given customer collaborate with a given supplier to achieve shared requirements understanding? Traditional techniques for requirements push (e.g. requirements specification techniques) ignore the supplier. Requirements pull (e.g. the inquiry cycle) ignores the customer. Established balanced techniques (e.g. Quality Function Deployment, QFD) that involve both customer and supplier are unnecessarily rich and have scalability issues. Agile development approaches the problem by reactive error correction and so far does not address proactive agreement on requirements understanding before development.

We propose a pragmatic approach to requirements communication. When following the pragmatic maxim formulated by Charles Sanders Peirce at the beginning of the last century, the meaning of requirements is visible in the design that results from these requirements. It is risky to pursue the idealistic idea of perfect requirements specifications. Too much effort will be invested in uncritical requirements, while acceptance of the intended solution cannot be guaranteed. Instead, misinterpretations of given requirements should be caught by choosing the right design from all possible alternatives.

Can requirements be frozen before design, or does software design affect requirements? The figure illustrates a case observed in industry that shows how requirements are identified as an answer to proposed design. A product manager asked a development team to support Cyrillic characters. The team proposed to partially implement a GUI configurator that was planned for a future project. The product manager felt that the proposal had a negative effect on a so far unstated requirement that he did not think he would have to specify: product reliability. The team answered by deferring the initial proposal and proposed the alternative of using unicode text fonts. The product manager accepted that proposal. In this example, requirements were adjusted as an answer to proposed design, and a seemingly valid but unacceptable design was replaced to account for these requirements changes.

How much does design affect requirements? In another case, we observed a 69% change of the requirements specification when a product manager was confronted with proposed design for the first time. The design was changed by 33% to account for these requirements changes. The effort for identifying and negotiating these changes corresponded to only 3% of the total effort invested in requirements communication. As a consequence, the product manager continued to study design proposals from other teams to even further improve the intended product. In this example, negotiations of implementation proposals were used to improve the value of the initially intended product.

We are using a negotiation process, called handshaking with implementation proposals, to communicate requirements effectively—even in situations where almost no written requirements exist and where distance separates the customer from developers. Handshaking is an efficient technique that uses architectural options as a way to understand requirements, to make implementation decisions that create value, and to establish the foundation for a stable project. The handshaking process supports the communication between a company’s product management and its development organization, with the former acting as a customer of the latter.

Using handshaking with implementation proposals to replace requirements handoffs led to recognized improvements in industry. The development projects that we accompanied with our research targeted new features for existing software products or product lines of software-intensive systems. The projects lasted from three months to two years with staffs ranging from four to more than 50 engineers. Seven projects were collocated, and three were distributed over three development sites in Europe and Asia.

Strengths: Customers and suppliers established a win-win dialogue with improved requirements and improved identification, analysis, and selection of alternatives. Customers obtained more and better information for decision-making. Suppliers achieved a deep, agreed understanding of requirements. Handshaking practice correlated with planning accuracy.

Limitations: Some requirements could not be communicated because they have not been sufficiently justified. Writing implementation proposals required domain knowledge. Requirements understandability did not improve for people not involved in requirements communication.

Government procurement is an important economic factor. The countries that signed the agreement on Government Procurement (GPA) have agreed to apply principles of transparency and non-discrimination for the procurement of software and software development of a given minimum size. Current research addresses the question how the dialogue between customer and supplier can be supported in such regulated tendering.

Calibration of the handshaking process affects the pre-project planning effort. Not all requirements need to be handshaked to achieve a good-enough requirements understanding. Current research addresses the question how much design is needed for stable and predictable project planning.

We encourage practitioners to test handshaking with implementation proposals for requirements communication. Start writing and negotiating implementation proposals for customer requirements that are vague or volatile or that are critical for mutual understanding. Implementation proposals can be quick and dirty initially and refined after reaching a first agreement. They helped our industrial partners use domain knowledge and experience to reach an agreed requirements understanding efficiently and became an important input for robust project planning.

To seize the full benefits and ensure consistent use of handshaking in your organization, the technique must be properly institutionalized and managed. This requires initial effort, but the returns become rapidly evident.

Please contact Dr. Samuel Fricker.

S. Fricker, M. Glinz (2010). "Comparison of Requirements Hand-Off, Analysis, and Negotiation: Case Study", 18th IEEE International Requirements Engineering Conference (RE'10), Sydney, Australia.

S. Fricker (2010). "Pragmatic Requirements Communication: The Handshaking Approach", presentation given at Blekinge Institute of Technology and at London City University.

S. Fricker, T. Gorschek, C. Byman, A. Schmidle (2010). "Handshaking with Implementation Proposals: Negotiating Requirements Understanding", IEEE Software 27, 2. 72-80.

S. Fricker (2009). Pragmatic Requirements Communication: The Handshaking Approach. Doctoral Thesis, University of Zurich, Switzerland. ISBN 978-3-8322-8602-6.

S. Fricker, E. Fuchs (2009). "Pragmatisch Anforderungen kommunizieren: Zwei entgegengesetzte Beispiele", REConf Schweiz 2009, Zurich, Switzerland.

S. Fricker (2008). "Verhandle um Anforderungen auch wirklich zu verstehen!", 1. Requirements Engineering Forum, Zurich, Switzerland.

S. Fricker, T. Gorschek, M. Glinz (2008). "Goal-Oriented Requirements Communication in New Product Development", 2nd International Workshop on Software Product Management (IWSPM'08), Barcelona, Spain.

S. Fricker, P. Grünbacher (2008). "Negotiation Constellations - Method Selection Framework for Requirements Negotiation", 14th International Working Conference on Requirements Engineering: Foundation for Software Quality (RefsQ'08). Lecture Notes in Computer Science (LNCS) 5025, Berlin: Springer. 37-51. 

S. Fricker, T. Gorschek, P. Myllyperkiö (2007). "Handshaking between Software Projects and Stakeholders Using Implementation Proposals". In P. Sawyer, B. Paech, P. Heymans (eds.), Proceedings of the 13th International Working Conference on Requirements Engineering: Foundation for Software Quality (REFSQ'07). Lecture Notes in Computer Science (LNCS) 4542, Berlin: Springer. 144-159.

S. Fricker, M. Glinz, P. Kolb (2006). "A Case Study on Overcoming the Requirements Tar Pit", Journal of Universal Knowledge Management (J.UKM) 1, 2. 85-98.