Requirements Bazaar is a Web based tool for Large-Scale Social Requirements Engineering (LASSRE) which outputs a list of requirements weighted by user votes. However these user demands are often hard to relate to concrete technical system parts. In this short tutorial we show how this relation may be established by using the methodology called Quality Function Deployment (QFD) and especially its instantiation, the House of Quality, to help transforming user requirements into a software product.

In the Requirements Bazaar, users may enter their requirements for a software, up- & downvote other user's demands, comment and further augment their contributions by the means of user stories, images and videos. By providing various scoring providers, Requirements Bazaar compiles these user-gathered requirements into a ranked list. The prioritized list may then be taken up by developers to ground further development decisions upon, i.e. by implementing higher-ranked requirements first. However, it often remains unclear which functional parameters in a system developers have to tune, in order to meet as many user demands as possible. E.g., enhancing the menu structure of an application may target many user demands at the same time such as shorter paths to certain functionalities and a less complex user interface. Additionally, over-engineered features may no longer be traced back to a concrete user demand at the end of the software development life-cycle.

In order to be able to target these relations, we propose the methodology called Quality Function Deployment (QFD) to be adopted in software engineering. QFD is a methodology that aims to drive product innovation by customer requirements [1]. Its central idea is to separate the what (requirements) from the how (technical realization). The instantiation of QFD is the House of Quality (HoQ). It originated in Japan in 1972 before it was adopted in the 1980s by large companies in the U.S. like Ford, AT&T and Xerox for their product development activities [2]. The HoQ is a matrix of user requirements and technical attributes and outputs a weighted list of the latter. As it takes the output of the Requirements Bazaar as its input, it naturally fits into the social requirements engineering landscape. We have implemented a preliminary Web tool to support the process of filling out the House of Quality matrix; we pursue to link both tools together to support a continuous software development process driven by social factors. In the following, we show how the matrix is calculated and present our future plans with the Web based tool.

Figure 1 shows the general outline of the House of Quality. It consists of multiple sections that need to be entered sequentially before the output can be calculated. The starting point are the Customer Requirements that are enlisted on the left side of the matrix one per row, together with a weight factor representing the voting results determined by the scoring providers in the Requirements Bazaar. On the right, the Product Ratings section contains a short market analysis with existing products in the column headers. Underneath, assessment values for each product are charted on how well it performs on the respective requirements.

Figure 1. Schema of the House of Quality

Now, the Engineering Characteristics are entered one per column in the header of the HoQ. Interdependencies of these features are related with each other in the roof matrix of the HoQ: if one feature has a positive impact on another, the respective field gets marked with a "+". Accordingly, bad correlations get a "-". Later, this helps the decision process by saying which aspects should be taken care of, since features with lots of positive impact are ideal candidates for improvements.

As the most important part of the HoQ workflow, the user requirements are put into relation with the engineering characteristics in the center matrix as Relationship Values. Hereby, using a numerical system comprising the values 9, 3 and 1 is a best practice. No correlation value should be entered if a feature does not target a user requirement at all; the relationship value 1 stands for a weak tie, 3 for medium and finally, 9 is entered for strong interdependencies. These values represent a relative weighting so that strong correlations are valued more heavily than weak relations. The center matrix also serves the purpose to identify requirements or features that are not targeted currently. E.g., if a user requirement exists that is not met by any of the existing technical features, a new feature would have to be introduced. In contrast, technical features that are not at all relevant to any user requirements are good candidates to rethink the feature vector of the system to eliminate possibly unwanted yet high-cost components.

As last step, the Calculated Weights are computed in the basement of the HoQ as the normalized sum of all relationship values multiplied with their weights. The results show that those technical features that are stronger related to more higher-rated user requirements naturally get a higher importance factor as those that are not linked to any user requirements at all. On the other side, lower-ranked features may be put to the lower end of the priority list. However, the roof of the HoQ should still be considered as even lower-ranked features may have many positive correlations with other aspects.

Multiple House of Qualities may be cascaded into a row of matrices by taking the output of one diagram and feeding it into another diagram as the left wing. This way, even fine granular architectural decisions can be traced back onto specific user requirements.

To facilitate the usage of the House of Quality as a tool that turns the ranking of the requirements gathered in the Requirements Bazaar into a weighted list of technical attributes, we created a Web application that is available as a free open source solution; Figure 2 shows a screenshot. Multiple users may work on a diagram collaboratively while the application takes care of resolving possible conflicts. Awareness is supported by multiple means such as a list of currently active collaborators as well as the highlighting of remote edits.

Figure 2. Collaborative House of Quality Web application

To foster further uptake of the tool, we pursued an integration of the House of Quality Web application with the Google Drive cloud based office software solution. Additionally, the application is available over the Google Chrome Web Store free of charge. HoQ diagrams are fully embedded into the Google Drive application; through the "Create" menu, a new HoQ matrix may be created in the current folder. All sharing functionalities are available through the context menu for inviting collaborators (cf. Figure 3). Since the integration with Google Drive is introducing some privacy issues, we pursue a standalone version of the app that is well-integrated into the Requirements Bazaar.

Figure 3. Google Drive sharing options for the House of Quality

In this short article we have presented the Quality Function Deployment methodology for software engineering and more specifically its instantiation, the House of Quality, for getting from weighted user requirements to a list of prioritized technical attributes. We have deducted the creation of such a House of Quality matrix and showed how it can be cascaded in order to be more granularly able to trace functional components to the originating user requirements. Finally, our House of Quality collaborative Web application and its integration into Google Drive was highlighted.

We are currently in the process of integrating the standalone Requirements Bazaar with the House of Quality Web application to provide a seamless user experience and less overhead with importing and exporting the weighted user requirements. By that, we expect further uptake of Quality Function Deployment in Large-Scale Social Requirements Engineering.

Acknowledgements

The research leading to these results received funding from the European Commission’s 7th Framework Programme (FP7/2007-2013) under grant agreement 318209 (Learning Layers).

REFERENCES

[1] J. R. Hauser and D. Clausing, "The House of Quality," in Harvard Business Review, vol. 66, no. 3, pp. 63-73, 1988.

[2] J. R. Hauser, "How Puritan-Bennett Used the House of Quality," in Sloan Management Review, vol. 33, no. 3, pp. 61-70, 1993.