Mahemoff, M. J. and Johnston, L. J. (1998).
Software Internationalisation: Implications for Requirements
Engineering. In Fowler, D. and Dawson, L. (Eds.), Proceedings of
the Third Australian Workshop on Requirements Engineering, 83-90.
Deakin University: Geelong. [In Geelong, Australia, October 26-27,
1998]
http://www.cs.mu.oz.au/~moke/papers/reqsi18n/
Software Internationalisation:
Implications for Requirements Engineering
Michael J. Mahemoff and Lorraine J. Johnston
Department of Computer Science
The University of Melbourne
Parkville, 3052, Australia
Phone: +61 3 9287-9100
E-mail: {moke,ljj}@cs.mu.oz.au
Keywords:
Software internationalisation, Requirements engineering.
Abstract
When developers produce software for users from different cultures, they should consider how both overt and covert cultural factors impact on the requirements. Overt factors (e.g. measurement units, calendars) are well-defined and easily understood. Covert factors (e.g. mental disposition, perception) are more vague and may not be immediately obvious. Both types of factors demand early attention to produce usable software. Usability tests and local consultants can help to identify requirements for internationalisation, but should be supplemented with recorded information about cultural factors. We provide a classification of factors which impact on requirements, and propose that it could form the basis for a repository of cultural information accessible by developers.
Introduction
Increasing connectivity, the move towards a global economy, and growing use of technology are making internationalisation an increasingly important concern for developers. Software intended for international audiences must exhibit functional and non-functional features which are appropriate to the end-users' culture and conventions.
There are many advantages in developing systems which can be used by a wide range of people. The most obvious benefit for users is software which closely matches their needs. Furthermore, there are synergies to be gained by using the same systems as others, especially as nations draw closer together. Poorer countries would also benefit from technology which helped developers to produce systems for less substantial markets. The benefits to organisations are obvious: an opportunity to boost international market share, and simultaneously reduce risk by diversifying their served market.
Typically, the implementation of such software involves two key stages (Luong et al., 1995). The first stage--internationalisation (also called ``localisation-enabling'')--prepares the core system to enable the subsequent localisation process. Localisation is the process of ``plugging in'' the locale-specific data into the internationalised structure. Clearly, a fundamental component of the internationalisation process is distinguishing between the needs which are common to all users, and those which are culture-specific. Development effort is optimised when only features depending on the perceived needs of end-users are customised; the rest of the system will then be common for all versions.
However, it is a non-trivial problem to separate requirements which are culture-specific from those which apply to all versions. Some information can be obtained via extensive prototyping and beta-testing. In reality, though, errors revealed in the testing stage are often too difficult or too costly to fix (Lim and Long, 1994), and the identification of defects does not guarantee that they can be removed (Karat and Dayton, 1995). This paper shows how cultural factors can be separated into distinct categories. Our classification is intended to help developers identify culture-specific requirements and understand how they can be addressed. At present, there is insufficient information available to practitioners who wish to define requirements for international audiences. We propose that the level of support could be improved by establishing a central repository of culture-specific information, based on our classification. Thus, we begin by discussing how cultures vary and describing the cultural factors which can impact on requirements. We then discuss implications for the requirements process, and the benefits which a repository would offer.
Cultural Differences which Affect Software Design
The term culture is used throughout this paper. A person's culture can extend beyond their ethnicity to include factors such as their hobbies and lifestyle. People therefore belong to more than one culture. The term locale generally refers to the realisation of the cultural variable in software, such as ``Japanese'', or ``French-Canadian''; Uren et al. (1993) define it as ``a combination of language, region, and code or character set''. Since culture goes beyond geographic details, it follows that locales can do likewise.
Understanding the user is a fundamental component of requirements analysis. If the user's cultural background is not taken into account, usability problems will arise, and this suggests that we need to develop models of culture. A user's culture can be modelled in various ways (see Hoft, 1996). For the purpose of requirements analysis, a useful approach is suggested by Yeo's (1995) dichotomy of overt and covert factors.
Overt factors are tangible, obvious characteristics of a culture, such as calendars, units of measure, and character sets. In many ways, these variables are somewhat arbitrary. It is true that some of these factors embody traces of cultural history; the fact that Australia shares the same calendar and date format as England provides information about its background. However, overt factors per se tend not to offer deep cultural insights. They are the daily conventions under which a society operates and must be supported in software; most people do not particularly care whether their currency is denoted by dollars or Francs, but once the decision has been made, financial packages must certainly cater for it. Since overt factors are based on convention, they tend to correspond to national boundaries.
At the other end of the spectrum are covert factors--vaguely-defined, complex aspects of a society which are easily misunderstood by outsiders and are sometimes so subtle that they may go unnoticed altogether. Verbal and non-verbal communication style, the meanings of symbols and problem-solving techniques are all examples of covert cultural factors. Whereas overt factors reside on the ``tip of the iceberg'', covert factors are the unspoken and unconscious rules that hide below the surface(see Hoft, 1996). Similarly there are varying degrees of covertness. Some aspects, such as commonplace customs, are observed with relative ease; others--like psychological facets--require deep probing and careful experimentation, and will always be the subject of vigorous debate.
This paper modifies Yeo's definitions to distinguish explicitly between cultural factors and consequential software features. Instead of treating an icon as a covert factor, it is viewed as a software feature whose interpretation will depend on certain covert factors.
To document cultural factors in such a way as to directly support the work of developers, it is desirable to extend this two-factor classification. After surveying the literature for examples of cultural factors, we produced a more refined classification in which overt and covert factors are further divided into six and four sub-categories, respectively. These factors are presented in the next section.
Implications for Requirements Engineers
Identification of Relevant Overt and Covert Factors
To understand the impact of overt and covert cultural factors on requirements, an initial step for practitioners is to be aware of the wide range of cultural aspects which these categories cover.
Overt factors can be divided into six sub-categories:
Overt factors typically result in non-functional requirements. However, in situations where the user can customise software according to the factors, there will also be some functionality required. A functional requirement for a manufacturing system might state that the user can choose between metric and imperial units.
Covert factors fall into four major categories:
Covert factors come in many guises. As with overt factors, they can translate into non-functional requirements. However, some also necessitate changes in the functionality itself. As a whole, covert factors are likely to cause major problems for developers if they are not identified sufficiently early.
How Cultural Factors Impact on Requirements
The most obvious implication in this area is that requirements engineers should seek detailed information about the anticipated user base. The variance among cultures shows that it is not enough to classify users simply by their system-oriented role (e.g. administrator, data entry clerk). The internationalisation process suggests an understanding of variables across target markets, so that the appropriate hooks can be applied. Thus, when requirements engineers examine user characteristics, it is essential that they forecast user bases for later versions of the system. The internationalisation-enabling phase can then isolate the appropriate culture-specific variables. Even though these variables might be identical for initial releases, later versions could vary them when users are introduced who require different features. The localisation process is relatively straightforward, and might only involve updating a database or adding an image. In contrast, if unanticipated cultural variables are introduced, a far more expensive process of re-enabling may need to be carried out.
Developing culturally-aware requirements specifications means more than just declaring who will use the system. As with other user characteristics, this information must be reflected throughout the requirements. There are some important differences between overt and covert factors in the way they affect requirements. Overt factors generally map isomorphically into non-functional requirements. For example, the knowledge that users require measurements in metric or imperial format simply means that the software must support both of these formats. The only other issue is how users can change their preferred measurement method. However, this becomes more of an issue about customisation than internationalisation itself.
The situation is radically different for covert factors. Obviously, these factors can affect surface-level features of the user-interface, such as images, colour schemes, and auditory cues. However, more profound effects also exist. Nielson (1990) reported on a French educational product which enables users to annotate poems. In some countries, it would be appropriate to allow children as well as the teacher to comment, but in France, only the teacher was allowed to add comments. This relates to cultural issues of authority and independent thought. A requirements engineer must therefore be aware of such issues to determine an important functional requirement.
Likewise, covert factors can affect non-functional requirements. Consider how one type of non-functional requirement--performance--depends on who will be using the system. First, a notion of suitable performance depends on how users achieve their task, i.e. their mental disposition. Some people might prefer to spend most of their time planning potential actions without directly interacting with the system. For such users, performance requirements might be less overall, but higher in the worst case due to brief periods of high activity. Second, a notion of acceptable time to perform a task depends on how cultures perceive time and how long they are willing to wait. Third, the context of usage must also be considered. An employer will be more tolerant of slow software if data entry clerks are being paid salaries which are small compared with the cost of development, or if the typical work processes in that locale do not place severe demands on performance.
Towards ``Culturally-Aware'' Requirements Specifications
Awareness of cultural variation is necessary, but not sufficient. It is one thing to understand how various factors influence requirements, but it is a far more difficult task to produce a specification which accounts for these factors. The intangible nature of covert factors suggests that an insufficient treatment can lead to software which is unusable, inefficient, or offensive to individuals belonging to other cultures. Local expertise, prototypes and tests, and practical documentation can all help developers to support internationalisation issues adequately.
Recruiting local expertise is one step in the right direction. At the very least, a local consultant or employee is likely to catch the most obvious mistakes. There have been many examples of poor branding and product design (see Taylor, 1992)--some to the point of embarrassment--which could have been avoided with a few minutes of enquiry. At the same time, it must be recognised that even local consultants may fail to notice more subtle issues, especially if they are not usability or domain specialists. Organisations must make the appropriate trade-offs between the benefits of catering for specific markets, and the complexity and cost inherent in obtaining culture-specific knowledge.
Prototyping is another option for determining requirements, and the costs of overseas testing are diminishing as international networks improve. A more serious concern is the validity of usability tests. Herman (1996) found that subjects from the Far East positively evaluated a product which clearly led to poor performance, and noted that it was culturally unacceptable for the subjects to criticise too openly or directly. Special care must be taken when testing usability in different cultures. For example, Herman suggested that objective tests be conducted to augment subjective evaluations. Local experts can assist in devising tests to ensure that they are designed with the target culture in mind.
While it is helpful to use consultants to gain knowledge about cultural factors, the information could be disseminated more widely, since not all organisations have the necessary resources to employ suitable consultants in a variety of locations. Fortunately, a large amount of this information is relevant to all developers, as these factors pertain to entire cultures rather than specific users. This makes it feasible to provide documentation to support developers' internationalisation work. To this end, we propose the establishment of an internet-based repository where internationalisation information can be made available. This archive could document the ways in which cultures vary and the consequent implications for software development. It would be open for contributions from developers and users. The classification of cultural variables discussed in this paper would serve as a basis for the organisation of the archive.
To date, little work has been done in documenting this kind of information. Most internationalisation texts focus on implementation issues rather than higher-level concepts such as usability. Since overt factors can be summarised relatively easily, it would be feasible to build an exhaustive list for each locale of the appropriate way to format a telephone number, the language(s) spoken, and so on. Such a reference would be extremely useful to developers, ensure that they do not have to ``re-invent the wheel'' in order to provide locale-specific features. Covert factors, although unlikely to be completely described, can still be documented to provide useful data for requirements engineers. There is certainly information which can be provided for many cultures, e.g. recognisable symbols and their meanings, significance of colours, particular usage contexts. Even if there is limited information about some factor, its mere presence in the repository might provoke requirements engineers to investigate its relevance.
In situations where developers cannot justify recruiting local expertise or testing with users from other cultures, a repository would be an inexpensive way to gain information about other locales. However, it would work best in tandem with these other activities. Software organisations could use it to determine where it is appropriate to recruit local expertise. Prototype creators would interpret the repository's recommendations as appropriate for a particular project. Tests could then be used to check if the interpretation was correct. For instance, if the repository says that the colour red is supposed to represent a warning for certain groups, there is still some uncertainty as to how this advice applies. Should a warning dialogue have a red background? Such issues can be resolved via user testing. The repository still adds value by providing an initial direction; in this case, the designers at least know which colour applies for warnings.
Conclusions
Establishing requirements for users of different cultures requires an understanding of the ways in which users vary. It is useful to distinguish between overt and covert factors. Overt factors, such as calendars and measurement units, are well-defined and easily-understood. Covert factors, such as mental processing and perception, require special consideration in requirements analysis because they are usually hidden or vague. Local expertise and prototyping are useful strategies for developers. In addition, supporting documentation should be provided, and this would supplement these other activities. We have proposed the construction of an international repository for this purpose.
In this paper, we have discussed how cultural factors affect requirements. A further step would be to investigate how internationalisation fits into the overall development process. For example, should culture-specific requirements be gathered before, after, or at the same time as other requirements? In addition, we have proposed the establishment of an easily-accessed repository of cultural information. While the classification introduced in this paper could act as the basis for such a repository, more research is needed to help us understand exactly how particular cultures vary along these dimensions.
References
This document was generated using the LaTeX2HTML translator Version 96.1 (Feb 5, 1996) Copyright © 1993, 1994, 1995, 1996, Nikos Drakos, Computer Based Learning Unit, University of Leeds.
The command line arguments were:
latex2html -split 0 reqsi18n.tex.
The translation was initiated by Michael John MAHEMOFF on Tue Oct 6 18:42:11 EST 1998