DPP Assignment 1
- 1. DPP ASSIGNMENT 1: PROJECT PROPOSAL Overcoming the communication barriers affecting Software requirements elicitation. SUBMITTED BY: ALBERTO TELLEZ-PICON STUDENT ID13162420 FOR: MANCHESTER METROPOLITAN UNIVERSITY FACULTY OF BUSINESS AND LAW DEVELOPING PROFESSIONAL PRACTICE January 2015
- 2. Alberto Tellez-Picon Student ID 13162420 2 of 12 1. Dissertation Title. The proposed title for this project will be: - Overcoming the communication barriers affecting software requirements elicitation. 2. General Purpose of the study: It has been recognised by the literature that the success of software projects is heavily dependant on how the end product fulfils the customer needs. (Nuseibeh, B. and Easterbrook, S. 2000). In order to provide software that meets the user requirements, digital Project Managers have to master software requirements engineering, which can be defined as the action of assessing the needs that a software has to fulfil. (Ross and Schoman’s 1977). These researchers argued that the software requirements analysis must cover: “why a system is needed, based on current or foreseen conditions, which may be internal operations or an external market. It must say what system features will serve and satisfy this context. And it must say how the system is to be constructed.” Amongst others that will be analysed in the proposed project, communication has been found to be one of the most critical factors when carrying software requirements engineering, (Coughlan, J., & Macredie, R. D. 2002), but yet just a few researches have attempted to provide an approach to overcome the communication barriers found on the different stages of this process, this is why the general purpose of the study will be: 1. To analyse state of the art on software engineering. 2. To investigate how communication affects software requirements elicitation. 3. To provide a communicational approach to software elicitation techniques. 2. Literature Review and Rationale for research in this area: Software development is a task naturally complicated and arduous given its aim, which is to made an environment where both human and technology behaviours will have to interact (Curtis, B. et al. 1988; Yu, Eric SK 1997). As Nuseibeh, B., & Easterbrook, S. (2000:38) expressed it: “The context in which RE takes place is usually a human activity system, and the problem owners are people.”. It is crucial, thus, to create systems that empower the human behaviours and provide solutions to their processes rather than making these more complex.
- 3. Alberto Tellez-Picon Student ID 13162420 3 of 12 It has been said that the success of every software depends heavily on how it fulfils the needs of the end users (Boehm, B. W. 1981; Nuseibeh, B., & Easterbrook, S. 2000). Furthermore, in order to have a methodology to elicit, define and negotiate these specific user needs with the aim to develop a working solution tailored to their specifications, the so called requirements engineering was born. So it can be said that requirements engineering is the process through which the software requirements are defined, negotiated and agreed in order to develop a software tailored to the requestor’s needs. Given its same nature, requirements engineering is a highly communicative process holding tasks such as “idea generation, decision-making, and requirements conflict resolution” (Calefato, F., et al. 2012:642). All of this tasks take place between users and designers, so the process becomes even more complicated by the fact that on one side, a high level of domain knowledge transfer has to take place between these two groups, and second because this knowledge fluxes have to be between people that do not know each other and come from different backgrounds, knowledge areas, and levels; all this makes communication to be even more important on the first stages of requirements engineering (Curtis, et al. 1988). Because of this interaction between really different individuals, it is crucial to acknowledge that misunderstandings will be really difficult to avoid and that these will lead to conflict. (Coughlan, J., & Macredie, R. D. 2002; Curtis, B. et al. 1988). Furthermore, as Easterbrook, S. (1994) pointed out, when carrying the task of RE, conflict management will have to be provided given that by the same nature of this task, the different individuals will find many disagreements among the requirements, specifications and goals of each software to be developed. They argue that the methodologies provided by the literature in order to capture and negotiate software requirements take a conflict avoidance approach, let alone use conflict as a constructive path to better understand the different points of view, requirements and goals. They finally provide a methodology to use conflict resolution as a tool to empower relations between the actors on RE while improving the quality of the end software specifications. This research will follow the same approach taken by Easterbrook (1994), embracing conflict as a positive way of improving user-developer relations while requirement engineering tasks are being carried. Following B.W. Boehm (1981), another characteristic that makes requirements engineering to be one of the most critical tasks of software development is the fact that if correction of the misunderstanding errors is done in later stages, the cost grows up to 200 times more than if found and sorted in the first stages of requirements engineering.
- 4. Alberto Tellez-Picon Student ID 13162420 4 of 12 In order to analyse the information being transferred through the mentioned individuals, it is really interesting the approach provided by Curtis, B. et al. (1988). The different layers through which this information has to iterate are well shown in his early study using the figure 1, with the aim on explaining the whole communicative process: In their study, the researchers argued that provided the requirements engineering tasks are performed by the interaction of individuals with their teams, the project, the company, and the software supplier, all this processes can be considered as communication layers or barriers and, the more people and groups involved on them, the more complicated these communication tasks become . These conclusions still hold valid nowadays and will be used as a starting point for this research. Jane Coughlan and Robert D. Macredie 2002. Figure 1. The layered behavioural model of softwaredevelopment. Curtis, B. et al. (1988) It is also crucial to understand the differentiation that some researchers have done on the approaches taken on RE, depending on whether the technique is product centred or human centred, which can also be expressed by the so called rationalistic against the user-centred perspectives; Coughlan, J., & Macredie, R. D. (2002). The former implies that the specifications are somehow in the customer’s mind and the designers have to work out in order to extract them, and the latest implies that the problem area to resolve is ambiguous and has to be defined with the joint collaboration of user and designers. The implications of this differentiation will drive the approach taken on the objectives, derivations of specifications, and user-designer communications, as can be seen in the following table: Assumptions Product Human Goals Completed system Customer Satisfaction Derivation of Specifications Given/extracted by the customer/user User-designer collaboration Nature of user- designer communication Contractual Continual Figure 2. Differences in assumptions on product and human entered approaches. Coughlan, J., & Macredie, R. D. (2002).
- 5. Alberto Tellez-Picon Student ID 13162420 5 of 12 In the same direction, research carried by Curtis, B. et al. (1988) proves that given software is developed by and for humans, its building has to be analysed as a behavioural process. Other studies, as an example Christel, M. G., & Kang, K. C. (1992), provide a lists of factors that influence the process of capturing software specifications as both human and product process, such as social constraints, architectural constraints, organisational constraints and problem-specific factors. This literature inconsistency provides enough reasons to approach the dissertation literature research and data analysis from a holistic perspective in order to include all possible factors influencing the communication processes. In order to make RE manageable the majority of the researchers have broken down this processes into different stages: elicitation, specification, and validation. (Christel, M. G., & Kang, K. C. 1992; Nuseibeh, B., & Easterbrook, S. 2000). Elicitation has been defined as the process that takes place to gain an understanding of the end software goals, objectives, and scope as well as “identifying the requirements that the it must satisfy in order to achieve these goals.” (Cheng, B. H., and Atlee, J. M. 2007:2). System specifications will be used in this research as the iterative process of defining the details of the system requirements in order to achieve what has been agreed in the elicitation process, which is normally captured in the specifications document; and validation can be defined as the phase in which the stakeholders accept and formalise the systems requirements, clarify the unclear specifications, and identify the unknown ideas. (Christel, M. G., & Kang, K. C. 1992) Other studies have widen this list to include analysis of the existing system in which the software will be build, (Van Lamsweerde, A. (2000, June) or to include modelling, requirements analysis, and requirements management. (Cheng, B. H., and Atlee, J. M. 2007). Although, this processes will be considered included in the three mentioned above. Even though RE tasks will usually be iterative in regards of the knowledge transfer between users and developers (Nuseibeh, B., & Easterbrook, S. 2000), their purpose is to serve as a reference point for researchers in order to narrow the studies to be carried, and to practitioners, in order to clearly understand which characteristics and success factors each stage has. This research will focus in the first of this stages, elicitation, which is believed to be the most affected by the environmental conditions and where the more volatile ideas have to be captured, hence the one where the communication requirements are higher. (Curtis, B. et al. 1988).
- 6. Alberto Tellez-Picon Student ID 13162420 6 of 12 With reference to the tools and channels used in the communication of software requirements, i.e. whether it is done through formal or informal specifications documents, formal or informal meetings, amongst others, there has been a fierce debate on which one is more efficient. Some authors have said that meetings are more cost effective, (Al-Rawas, A., & Easterbrook, S. M. 1996), others have suggested that the more complex the task becomes, the richer the communication media has to be. (Calefato, F., et al. 2012). and that depending on whether the task is elicitation or negotiation text or F2F communication improves. Other studies propose a more wider approach by adding introspection, interviews, questionnaires, and protocol, conversation, interaction, and discourse analyses methods. (Goguen, J. A. and Linde, C. 1993). Thus, there will be an attempt to clarify which tools and channels do contribute to requirements elicitation in a more efficient way, by comparing the literature to date, starting with the foundation on avoiding one size fits all methodology approaches, as Benyon and Skidmore (1987) clarified in their research. This literature review could not end without providing an overall view of the common techniques used on requirements elicitation. Following Jane Coughlan and Robert D. Macredie (2002), these are: MUST techniques, Joint Application Design (JAD), User-Led Requirements Construction (ULRC) and Soft Systems Methodology (SSM). In order to understand how these are differenced, this authors presented the following figure: The differentiations are based on whether the elicitation process is human centred (Used of System) or product centred (System in use), and whether the control of the communications resides with the designers or the users. Figure 3.A classification framework for the methodologies under analysis. Jane Coughlan and Robert D. Macredie (2002) Following a comparison between these techniques, based on parameters such as user participation and selection, user–designer interaction or communication activities, the authors proved that “none of the approaches make a clear statement of stakeholder participation” as well as proving that there is a lack on field research of real life situations with the aim on analysing the user-developer or user-analyst communication and relationship. It will serve as a ground to clarify and understand the most used methodologies in requirements elicitation tasks and to study the communication between these two really different groups.
- 7. Alberto Tellez-Picon Student ID 13162420 7 of 12 4. Specific Objectives. Having done the initial research of the literature, we are now in a position to say that the dissertation principal objectives are to explore the following research questions: - To identify and evaluate the critical factors in requirements elicitation. This will be done by analysing the literature to date and comparing it with the results obtained in the following objective. - To critically analyse the communication difficulties and its causes on requirements elicitation. This objective will be accomplished using empirical study (Interviews and participant observation as will be explained below) - To identify and explore a new communicational approach to requirements elicitation. 5. Limitations As argued by Zave, P. (1997) “The subject of requirements engineering is inherently broad, interdisciplinary, and open-ended.”. As will be shown in this study, one of the main reasons making RE being a broad subject is that it involves people from many different backgrounds, levels and disciplines; it is interdisciplinary because is based on the communication in-between these members, area studied by sociology and anthropology, it is based in understanding which difficulties these members may have in describing their own needs, which is informed by psychology, and has many different communication channels, which is defined by linguistics. (Bashar Nuseibeh & Steve Easterbrook 2000). It is also an open-ended discipline as technology is ever changing so its methods to capture the requirements and specifications to be developed. As a consequence of this, the literature research will have the following limitations: - The amount of articles in the literature is broad. This will be overcome by limiting the research keywords to three: requirements elicitation, communication, software development. - Given the research is about communication, the research can become too broad, this is why the researcher will narrow it to requirements elicitation, which, as has been explained is the first stage of RE.
- 8. Alberto Tellez-Picon Student ID 13162420 8 of 12 - The approach for data collection will be a qualitative method, through interviews and participant observation. Given it will be done with as maximum as 5 projects the study will have the following limitations: - The time frame to undertake the study is limited so a detailed planning will have to be provided and agreed with the subjects involved in the study. - The rigour of the research will be compromised by the small sample size as well as by the fact that the points of view of the subjects to be interviewed on it may be biased being these in the same project under study. As Bell, T. E., & Thayer, T. A. (1976) expressed: “Memories are biased by personal conflicts and occurrences from long after the software is implemented.” In order to overcome this threat, an empirical study of requirements will be based on data collected during the project through observation, so the points of view of these subjects can be compared with the less biased point of view of the researcher; provided that in management disciplines “all research must be biased to some degree” in order to provide good theory. Bell, E. and Thorpe, R. (2013;25) - Having the key subjects acceptance to be interviewed will also pose a severe risk into this research, hence why the possibility of stoping the recording at any time during the interviews and group observation will be offered, as well as allowing the participants to ask at any time that their contribution to the date is erased from the study. - In regards of the external validity of the study, which is the possibility to use its results outside the scope of the same study, there is also a challenge provided the sample may not be representative of the population of software professionals, (Calefato, F.,et. all 2012). But, given the aim of this study will be to analyse individual and group interactions, it is not the intention of the researcher to provide a whole methodology for RE but to find the critical success factors on communication as well as providing a research directions guide. As already mentioned, there are no current papers that describe and analyse software requirements elicitation from a communicational perspective and neither provide recommendations for future research and techniques to do so, although being found as one of the most critical factors when carrying software requirements elicitation, (Coughlan, J., & Macredie, R. D. 2002). This is why the aim of this paper will be to gather the critical factors in requirements elicitation communications in order to contribute to the existing literature providing a qualitative approach as will be explained in the following section.
- 9. Alberto Tellez-Picon Student ID 13162420 9 of 12 6. Research Methodology In order to achieve the proposed objectives and conclusions, a literature research will be carried using secondary data obtained from the main databases provided on the University library, with the aim on gaining an understanding on the common mentioned critical success factors on requirements elicitation. Once above information is gathered, the researcher’s aim is to do a participant observation by being present in the meetings to elicit software specifications of each of the projects under analysis, which will be at the beginning of each project, and at the final meeting with the customer representative. Also, 15 interviews of one hour each will be carried with the Project Manager in charge of each project under analysis, the developers team leader, and the user representative, with the aim of collecting the data. All this field research will be carried at the company the researcher works for, rentalcars.com. As argued by Runeson, P., & Höst, M. (2009), while there are many systematic reviews and guidelines for experiments’ conduct and reporting, only little is written on case studies and qualitative methods in software engineering, which is one of the main reasons that this research will use these methods, with the intention to be innovative. Another main reason for adopting a qualitative approach is the chosen topic nature. Since the objective of the research will be studying the communication between individuals, which is a human way of transferring information through many channels, cues and signals, the methodology has to allow all this information to be captured and analysed; in other words, “The analytical research paradigm is not sufficient for investigating complex real life issues, involving humans and their interactions with technology.”, Runeson, P., & Höst, M. (2009), hence the best way to capture this information is by providing an ethnological attitude by carrying a field study of 5 projects. The interviews will be semistructured or open ended. The main reason for using this type of interviews is to allow participants to provide their own insight on the project, approaching it with a holistic perspective, in order to collect all possible details, providing though a guideline of the interview and specific time to answer each of the questions; some questions included in these interviews may follow this approach:
- 10. Alberto Tellez-Picon Student ID 13162420 10 of 12 Project Manager and Developer Team Leader Interviews: 1. What are the main issues you have come across when eliciting software requirements in your last three projects? 2. Which would you say are the most critical success factors when carrying requirements elicitation tasks? What do you consider about communication? 3. Do you approach elicitation requirements from a product or human point of view? 4. What channels do you normally use on requirements elicitation? 5. Do you use any specific technique? 6. Do you consider conflict to be a challenge or an opportunity? How do you manage software requirements conflict between developers and customer? User Representative Interviews: 1. Which were the main issues you came across when capturing and agreeing software requirements in the project? 2. Which would you say are the most critical success factors when carrying requirements elicitation tasks? What do you consider about communication? 3. Did you consider your requirements where delivered? 4. How the end product satisfied your expectations? 5. Did you feel the channel used for requirements elicitation was the correct one? 6. Did you have any conflict during requirements elicitation? Once the data is collected by carrying the field study, and the literature research is performed, an existing requirements elicitation methodology will be picked among the ones mentioned above; MUST techniques, Joint Application Design (JAD), User-Led Requirements Construction (ULRC) or Soft Systems Methodology (SSM). Once the communication critical factors on software elicitation have been collected also using the literature, these will be compared with the chosen methodology. The aim of this practice will be to have a framework/benchmark with which to compare the results obtained in the field study, with the aim on the third objective of this dissertation: identify and explore a new approach to requirements elicitation, alongside providing recommendations for future research, which will have to take place in order to prove the efficiency of these.
- 11. Alberto Tellez-Picon Student ID 13162420 11 of 12 7. Bibliography. - Achimugu, P., Selamat, A., Ibrahim, R., & Mahrin, M. N. R. (2014). A systematic literature review of software requirements prioritization research. Information and Software Technology, 56(6), 568-585. - Al-Rawas, A., & Easterbrook, S. M. (1996). Communication problems in requirements engineering: a field study. National Aeronautics and Space Administration. - Benyon, D., & Skidmore, S. (1987). Towards a tool kit for the systems analyst. The Computer Journal, 30(1), 2-7. - Brynjolfsson, E., & Hitt, L. M. (2000). Beyond computation: Information technology, organizational transformation and business performance. The Journal of Economic Perspectives, 23-48. - Calefato, F., Damian, D., & Lanubile, F. (2012). Computer-mediated communication to support distributed requirements elicitations and negotiations tasks. Empirical Software Engineering, 17(6), 640-674. - Cheng, B. H., & Atlee, J. M. (2007, May). Research directions in requirements engineering. In 2007 Future of Software Engineering (pp. 285-303). IEEE Computer Society. - Christel, M. G., & Kang, K. C. (1992). Issues in requirements elicitation (No. CMU/SEI-92-TR- 12). CARNEGIE-MELLON UNIV PITTSBURGH PA SOFTWARE ENGINEERING INST. - Coughlan, J., & Macredie, R. D. (2002). Effective communication in requirements elicitation: a comparison of methodologies. Requirements Engineering, 7(2), 47-60. - Curtis, B., Krasner, H., & Iscoe, N. (1988). A field study of the software design process for large systems. Communications of the ACM, 31(11), 1268-1287. - Damian, D. E. H., Eberlein, A., Shaw, M. L., & Gaines, B. R. (2000). Using different communication media in requirements negotiation. IEEE Software, 17(3), 28-36. - Easterbrook, S. (1994). Resolving requirements conflicts with computer-supported negotiation. Requirements engineering: social and technical issues, 1, 41-65. - Goguen, J. A., & Linde, C. (1993). Techniques for requirements elicitation. RE, 93, 152-164. - Nuseibeh, B., & Easterbrook, S. (2000, May). Requirements engineering: a roadmap. In Proceedings of the Conference on the Future of Software Engineering (pp. 35-46). ACM. - Ross, D. T., & Schoman Jr, K. E. (1977). Structured analysis for requirements definition. Software Engineering, IEEE Transactions on, (1), 6-15.
- 12. Alberto Tellez-Picon Student ID 13162420 12 of 12 - Runeson, P., & Höst, M. (2009). Guidelines for conducting and reporting case study research in software engineering. Empirical software engineering, 14(2), 131-164. - Van Lamsweerde, A. (2000, June). Requirements engineering in the year 00: A research perspective. In Proceedings of the 22nd international conference on Software engineering (pp. 5- 19). ACM. - Verburg, R.M., Bosch-Sijtsema, P. and Vartiainen, M. (2013). “Getting it done: Critical success factors for project managers in virtual work settings” International Journal of Project Management 31 (2013) 68–79. - Yu, E. S. (1997, January). Towards modelling and reasoning support for early-phase requirements engineering. In Requirements Engineering, 1997., Proceedings of the Third IEEE International Symposium on (pp. 226-235). IEEE. - Zave, P. (1997). Classification of research efforts in requirements engineering. ACM Computing Surveys (CSUR), 29(4), 315-321.