In order to make an understandable presentation, Sommerville had to skip some detail which can be implemented by special analysts in different organisations. So this is the simplest process which almost includes nothing about in what way analysts should manage requirements. It is just a kind of plain models which uses simple flow of data. If analysts use this process without any requirements management, they may have some problems.
Problems
1. There is no classification of requirements in the process. So every requirement may have to be analysed separately with lack of relationship.
2. There is no analysis methodology based on classification. This may cause inefficiency.
3. If an analyst wants to make changes to requirements, this process may be not suitable for rolling back or reversion check.
So, a methodology which can manage requirements should be required to intervene in the requirements transition among these activities in the process.
2.2 Describe the REA process using a semiotic framework
An effort on creating a semiotic framework has been made in IT industry. Liu (2000) organised traditional divisions of semiotics and Stamper’s (1973, cited in Liu, 2000) theory into a semiotic framework (see figure 2.2). In this framework, there are six levels. In the requirement elicitation and analysis process, analysts usually care about the upper three levels which focus on “communicating meanings and intentions” (a quote of Liu, 2000, p. 27) rather than the lower three.
Figure 2.2 The semiotic framework (Liu, 2000)
After the semiotic framework has been introduced, it naturally leads to a question whether the semiotic framework can be applied into the process of requirements elicitation and analysis. One of the best ways is to divide the process into different levels using the semiotic framework. In order to integrate the semiotic framework with the process of requirements elicitation and analysis by dividing the process, the outputs of different levels should be found as a reference of division (see table 2.1).
Table 2.1 Outputs of the upper three levels in the semiotic framework
In the social level, semiotics concerns norms and expectations developed through practical experiences of agents in a society (Liu, 2000, p. 42 & p. 98). The output of this level meets the activity Domain understanding‘s output in the REA process, which is ‘analysts must develop their understanding of the application domain (a quote of Sommerville, 2001. p. 125)’. Interacting with stakeholders in the activity Requirements collection outputs the unstructured collection of requirements which meets the output of pragmatic level (Sommerville, 2001. p. 125). In semantic level, analysts will work on the meanings of requirements and create a kind of logic which obeys a specific rule. Before checking the requirements, this logic (function, interface, design constraints etc.) should be figured out in a requirements document. Requirements checking and Requirements specification link semantic level with social world, so, critically speaking, they do not belong to any semiotic level, but they have relationship with every level. According to this, the REA process can be divided into three levels using semiotic framework (see figure 2.3).
Figure 2.3 The REA process with semiotic analysis
The semiotic integration into the REA process demonstrates that the process is a typical semiotic activity, which is sign-based. One of the advantages of the integration is that analysts can manage requirements in a different view. They can know not only the requirements flow but also which semiotic level a requirement belongs to, what relationship the requirements have and how they improve. Last but not least, analysts can arrange their work according to this framework by dividing the whole job into different phases. In each phase, they can just concentrate on the problems of a specific semiotic level.
In this section, the semiotic framework is integrated with the REA process through the analysis of both concepts of them and outputs that they make. In this semiotic framework aided REA process, analysts can use many semiotic approaches to support their analysis, which will be listed in the next section.
3. The contribution that semiotics makes in the REA process
Current contribution of semiotics to the information technology industry involves norms analysis, pragmatic analysis, semantic analysis, project planning, system modelling and requirements analysis etc. In the process of REA, the studies of the semiotics focus on the requirements analysis, the management of requirements and the project planning etc. In this section, some semiotic approaches applied into the REA process will be discussed and evaluated. The implication of semiotics will also be examined as a part of the research in the essay.
3.1 MEASUR
MEASUR is one of the vast semiotic methodologies, which is a radically new set of norm-oriented methods for business systems modelling and requirements specification for software development (Liu, 2000, p. 37). It consists of five methods: Problem Articulation Methods (PAM), Semantic Analysis Method (SAM), Norm Analysis Method (NAM), Communication and Control Analysis (CCA) and Meta-Systems Analysis (CSA).
Table 3.1 shows which activities can the semiotic methods in MEASUR serve.
Table 3.1 Current semiotic approaches in MEASUR to the requirement analysis
MEASUR provides the infrastructure analysis to help understand the social, organisational, cultural and technical contexts in domain understanding. It also focuses on how to understand business objectives and strategies in the organisation. In the activities of the semantic level, it can help identify business and technical problems and solve them. MEASUR almost intervenes in all activities in the process of requirements elicitation and analysis to help requirements understanding and representing. Furthermore, it implies a new approach to solve problems, which is to do sign-based analysis. Following this way, we might be able to continue working out new methods supporting the REA process such as a semiotic logs tool.
3.2 Semiotic logs tool for requirement analysis
After the requirements analysis, analysts have to show the requirements document to all stakeholders. That means the requirements document has to fulfil the needs of all stakeholders ranging from customers to developers. This activity might involve many problems. One of them is whether analysts can give consonant explanations of requirements to different groups of stakeholders. Furthermore, sometimes, analysts need to find hidden meanings in users’ requirements which might cause misleading assumptions. To make sure they have not made any mistake and they can roll back to the original requirements, analysts have to make a reversion check on the requirements. But, the situation usually is that they can not link every requirement to original one which is presented by customers because of lack of organising requirements.
Actually, semiotics can help analysts make an efficient reversion check. Figure 3.1 illustrates an example called semiotic logs which shows how to track the requirements during the requirements analysis.
Figure 3.1 Semiotic logs for requirements analysis
In figure 3.1, R1, R2, R3… means requirement No.1, requirements No.2, requirement No.3 etc. P 1.1, P 1.2, P 2.1… separately means the first priority No.1, the first priority No.2, the second priority No.1 etc.. Requirements, according to the levels they belong to, are classified in at least more than 3 levels. The first level is original requirements level which comes from users directly. The second level is pragmatic requirements level whose requirements are collected from the original ones using pragmatic analysis methodology. The third level is semantic requirements level which holds the requirements which come from the last level after semantic analysis. The lines which link requirements demonstrate the inheritance from super-requirement to sub-requirement. Line L1.1 and L2.1 seem special as the lines cross different original requirements. This situation would be common during the requirements analysis because different intentions might create the same requirement. The important thing is that the more this kind of cross lines, the closer the relationship between these two original requirements. In REA, this point of view will be very useful when analysts want to change requirements. They can examine the relationship of requirements and estimate the cost of change.
This logs tool does not care what methodology analysts are using in different levels but remembers what they have done using a semiotic approach. So it cannot guarantee to keep requirements correct among different level of the analysis. In fact, it is not the job that a logs tool should do. However, the aim to keep requirements correct can be achieved by a set of semiotics described principles, as follow:
Semiotics described principles of requirements analysis
1. Pragmatics protection: Collecting requirements should not change the implications of the social norms.
2. Semantics protection: Conflict solving should not change the meaning of the requirements.
3. Consistency: Generated documents should mirror social level, pragmatic level and semantic level.
The process of requirements elicitation and analysis is a series of activities in human communication, which should be analysed by linguistic methodology. Semiotics as a study of signs which bridges the gap between the engineering and the linguistics provided a new perspective to solve human communication in the engineering industry. So, following semiotic described principles is the best way to avoid ambiguity and to help roll back or change requirements without errors.
In this section, the contribution of semiotics to REA has been discussed from existed methodology to the implication of semiotics in the REA process. Next section will make further discussion about the future of the semiotics in information systems engineering.
4. Future implication of semiotics in information systems engineering
Existed successful methodologies and applications of the semiotics have showed a great example of applying semiotics into information systems engineering. In MEASUR, a recent research stated that PAM can be used for organisational infrastructure modelling (Liu, et al, 2006). They intended to use semiotic methods to support project planning which is ‘difficult and inherently involves challenges and elements of unpredictability (a quote of Liu, et al, 2006)’. What they said also implied the general aim that semiotics should achieve. Semiotics should focus on the problems which have more uncertainties. According to this, Souza (2006) raised Semiotic Engineering described as a semiotic theory of Human-Computer Interaction (HCI), because HCI is a meaning-negotiation process which involves many uncertainties.
In requirements understanding and representation, besides the REA process, there are also many activities with a great amount of uncertainties such as feasibility study, requirements validation and requirements management etc. Requirements validation/checking as well as requirements management need to deal with unpredictable requirements change while feasibility study which involves information assessment and information collection (Sommerville, 2001, p. 123) has to overcome the human uncertainties during study, for example a system analyst may meet different groups of users who have responsibility of communicating with the system analyst. In the future, semiotics might intervene further more in these activities to help analysts manage any information.
5. Conclusion
In information systems engineering, semiotics as a new methodology has been paid more attention to in order to solve uncertainties in development of information systems. Requirements engineering as a crucial part of development needs methodological help from the semiotics. This help now includes project planning and management, requirements elicitation and analysis, systems analysis and design, business process modelling, organisational semiotics, systems integration and human-computer interaction etc.
Requirement elicitation and analysis as a stage of requirements engineering processes involves many complicated activities including domain understanding, requirements collection, classification, conflict resolution, prioritisation, requirements checking and specification. These activities have many problems waiting for efficient solutions. Semiotics in requirements understanding and representing has done a great amount of jobs using many analysis methods such as PAM, SAM, NAM etc. In these methods, many semiotic theories have been used for Infrastructure analysis and systems analysis, design and implementation. Furthermore, the process of requirements elicitation and analysis can be reconsidered to a great degree when the semiotic framework intervened in. Six levels of semiotic framework including physical level, empiric level, syntactic level, semantic level, pragmatic level and social level draw a structure for the REA process. Because of this, requirements management could be easy if analysts divide requirements into different semiotic levels and it could be easy to make reversion check or change requirements during analysis.
Although semiotics has made great contributions to information systems engineering, it never stops. As uncertainties in analysis rise because more human’s intentions and activities have been added in information systems, semiotics would be a great methodology to solve these problems in development of information systems.
References
Davis, A. M. (1990) ‘The analysis and specification of systems and software requirements’ in Thayer, R. H. and Dorfman, M. (eds.) System and software requirements engineering. p. 119-144. Los Alamitos: IEEE Computer Society Press.
Easterbrook, S. ‘Resolving requirements conflicts with computer-supported negotiation’ in Jirotka, M. and Goguen, J. (eds.) Requirements engineering: social and technical issues. p. 41-66. London: Academic Press.
Liu, K. (2000) Semiotics in information systems engineering. Cambridge: Cambridge University Press.
Liu, K., Sun, L. and Tan, S. (2006) ‘Modelling complex systems for project planning: a semiotics motivated method’ in International Journal of General Systems, Vol. 35, No. 3, p. 313-327. Taylor & Francis Group
Pfleeger, S. L. (2000) Software engineering: theory and practice, 2nd edition. London: Prentice- Hall, Inc. Pearson Education Limited
Sommerville, I. (2001) Software engineering, 6th edition. Essex: Pearson Education Limited
Vliet, H. (2000) Software engineering: principles and practice, 2nd edition. West Sussex: John Wiley & Sons, Ltd
Souza, C. S. (2005) ‘Semiotic engineering: bringing designers and users together at interaction time’ in Murray, D. (eds.) Interacting with computers, Vol. 17, Issue. 3, p. 317-341. Thomson Scientific
