Implementing Web-Surveys for Software Requirements Elicitation

Transcription

1 Implementing Web-Surveys for Software Requirements Elicitation Hrvoje Belani, Krešimir Pripužić and Katarina Kobaš Faculty of Electrical Engineering and Computing / Department of Telecommunications Unska 3, HR Zagreb, Croatia {hrvoje.belani, kresimir.pripuzic, katarina.kobas}@fer.hr Abstract This paper presents a practical approach to a survey as one of requirements elicitation techniques. A fundamental goal in requirements engineering is to discover the stakeholders real needs. Conducting a good survey enables acquiring the appropriate information from the stakeholders. The paper discusses the means to elicit software requirements through surveys, and ways to improve the given technique. Advantages of electronic surveys (e.g. Websurveys) versus paper-surveys are pointed out. Architecture of Web-survey tool is proposed, taking the related work into the consideration. User-tool interactions are carefully analyzed. Solution for additional security and privacy issues is suggested. Keywords: requirements elicitation, Web-survey, Java Servlet Technology. I. INTRODUCTION Software development today strives to deliver fully functional product within defined timeframe and given budget. To achieve these goals, the principles of software engineering ought to be applied. Requirements engineering was established as software engineering discipline when the need for more systematic approach to the earliest phases of software development cycle was recognized. Subcomponents of requirements engineering are requirements development and requirements management [1]. Requirements development consists of the following activities: elicitation, analysis, specification, and validation. Scope of this paper addresses the earliest phase of requirements development - requirements elicitation. The idea of requirements elicitation is gathering the needs from the stakeholders in new software product development. Elicitation will succeed only through collaboration between all stakeholders. Because of the extreme importance of the requirements elicitation, many techniques are used for this purpose. It is strongly recommended to use more than one technique for efficient requirements elicitation. These techniques are: interviewing, surveys, group meetings, scenarios, sampling, prototyping, etc [2]. Focus of this paper deals with means to elicit software requirements through surveys and ways to improve them. Figure 1 shows three main levels of software requirements recognized during the elicitation: business requirements, user requirements, and functional requirements. These requirements ought to be considered on different levels of abstraction, because the process of their analysis after the elicitation is not straightforward. For example, two functional requirements can be derived from one user requirement, etc. Survey tends to signify to all three levels of requirements, but further analysis of gathered requirements is obligatory. Functional requirements are crucial for creating requirements specification. II. QUEST FOR REQUIREMENTS A. Surveys The software requirements elicitation comprises an early and critical but highly error-prone phase in software development [3]. Creating a survey is quite demanding for its author(s), for several reasons. It requires a detailed vision of the product, and knowledge in areas of social, financial and psychological sciences. The purpose of surveys in requirements elicitation is to gather significant amount of focused data (attitudes, facts, behavior, etc.) about the software product at the very beginning of the development process. When designing a survey, the research objectives must be articulated clearly [4]. Survey inquires about business objectives of the product and expected product usage, shows scope limitations, proposes success criteria and asks about stakeholder s strategic vision of the product. Figure 1 - Levels of software requirements (adopted from Ref. [1])

2 The actual trend in software requirements engineering is providing tool support for many its techniques and methods. Using requirement tools seem to have the largest impact on the success of IT projects. This kind of tools represents a platform for communication between all stakeholders [5]. Developing a Web-tool for surveys shows the initiative in this direction. We will first make an overview of results achieved and conclusions made while designing, conducting and processing a paper-survey. Following, we will suggest Web-survey design with our improvements based on the current issues in related work. B. Paper-Survey We conducted a paper-survey among students at our Department. The purpose of this survey was to discover requirements, needs and expectations towards the service of sending exams-information via SMS. The problem that had to be solved first was the software's vision. During a vision creating process, some of the user groups came up naturally. When the vision was created, we have recognized three classes of responders: students, professors and administrators. The professors would grade the exams, students would receive the exam results on their mobile phones, and the administrators would take care of service's functioning. While conducting this survey, the questioned students were also asked for the introspection, i.e. to impersonate the roles of professors and administrators. Every responder class has different needs and requirements that we had to take into consideration and apply it into the survey. The questions in the survey were different for each responder class. According to the vision, a student receives the results on his mobile phone in a form of SMS messages. A professor grades student s exam and sends the results via Web-interface to an administrator. The administrator sends the exam results and the date/time of oral exams to the student. Survey was divided into four main parts: general information, opening issues, context-related issues, and functional requirements. In the first part, responders were asked about their general information (age, occupation, etc.) in order to give better insight to the responder s data. The second part of the survey gave a set of questions that would lead to basic understanding of the problem. Opening issues for this survey were information about owning and using a mobile phone. These types of questions are useful to establish relevancy of each responder. A student who does not own a mobile phone is not as relevant as the one who uses a mobile phone every day. The answers of the less relevant responders in processing the surveys results are taken into consideration with a smaller weight factor. Goal of the third part of the survey is to raise contextrelated issues with the existing means of informing about exam results. These context-related issues include possible problems and levels of satisfaction with current situation. If responders were satisfied with the existing service, it is very important to discover it, and this is also a purpose of this type of questions. In the third part of the survey responders have been concentrated on the context and we could ask questions about their requirements towards the service. These are called functional requirements [6]. Many of functional requirements obvious at the first sight and some of them less obvious were noted down for later analysis. The requirements analysis is necessary to discover and deal with eventual conflicts. Good survey-questions aim to detect these conflicts. Results of this survey have shown the considerable need for the implementation of the new service. It is shown as a good practice to beta-test a survey before conducting the real inquiry. Beta-testing is testadministering the survey to several people. It is needed because it is not always easy to anticipate how the responders will construe the questions. C. Responder Classes Unlike to the popular daily-news surveys, fulfilling the surveys for eliciting software requirements are not supposed to be allowed to everyone. Requirements analyst has to study a software product vision and to identify the users of the product. If large number of users is expected, it is important to elicit the requirements from a representative cross section of these users. We call cross sections as responder classes. They have the following characteristics: different subset of features, different frequencies of product usage, varying experience and skill levels, and varying privilege levels. A survey creator has to create a survey specifically for a different responder classes. The creator has to imagine being a member of a responder class and try considering their point of view for the concrete issue. The method that is mostly used is introspection. There are many drawbacks in this method, so it has to be approached very seriously. D. Survey Dissadvantages One of the issues in conducting paper-surveys is lack of control while responding to the questions in the survey [7]. There are couples of common mistakes made by paper-survey responders: skipping questions, giving more answers then required, and answering questions they are not asked. Additional questions are noted as potential information leak-hole. These are the questions that require an answer only from those responders who gave the particular answer to the previous question. It is very common for responders to answer the additional question even though they did not give the answer in the previous question. This appears as significant problem for processing the survey results. Some other disadvantages of paper-surveys, like difficult handwritings, also have influence on validity of final results.

3 Significant paperwork is required to process the papersurvey results. Depending on a number of responders, it takes a lot of time to count and sort every type of question and answer. There is also a problem of counting in answers with smaller relevancy. All answers have to be processed. Some of the questions are not relevant as others, and these answers have to be counted in with a specific weight factor. A tool for Web-survey should solve these obstacles which arise while creating and processing paper-surveys. B. User-Tool Interactions As we can see in the use case diagram (Figure 3) there are two types of actors: creators and responders. Creator interacts with the use cases Create and Browse Statistics. There are two types of surveys: free and focused. A focused survey is intended to a specific class of responders. Contrary to a focused survey, a free survey is open for all responders that wish to participate in it, we call them free responders. III. WEB-SURVEY TOOL A. Tool Architecture As we mentioned above, paper-surveys have many disadvantages. We decided to make a new tool without these disadvantages and that allows: creating surveys, responding to surveys, and browsing filtered survey statistics. <<includes>> <<includes>> Tool design priority has been to avoid difficulties that arise because of different operating systems and security/privacy issues. A Web-based tool has seemed as rational solution. It is accessible from different operating systems and has less security and privacy issues than a desktop application. We assumed that potential Web-tool users have browsers without any additional plug-ins installed (e.g. Java plug-in). As we can see in Figure 2 we have decided to use Java Servlet Technology. It is appropriate because it is free, doesn t require any plug-in on a client side, it is scalable and satisfactorily fast [10]. Figure 2 - Web-survey tool architecture The database consists of XML files. Every created survey and a response to a survey is separate XML file in the database. We have wanted that our tool generates not just one but many on-demand statistics for a given survey. Each of these statistics is unique and made by processing (i.e. filtering) the stored responses. We call this process on-demand filtering of survey responses. Let us take an example of a survey that has certain question with several offered answers. If we want to generate statistics depending on the answers to that question we will have to read through all the responses again regardless of the previously made statistics. This is an example of an on-demand filtered statistics. Figure 3 - Web-survey tool use case diagram We supposed that the survey creator as a creator of a specific survey isn t eligible to respond to it. Each survey has only one creator and may have many different responders. It is important to notice that the creator of a specific survey may be a responder to other surveys. Creating of a survey has to be made question by question. A survey creator has to select type for each question. There are five different types of possible questions in a survey: text-box, text-line, combo-box, radio-buttons, and check-boxes. The last three question types may have two or more predefined answers. A survey creator also has to specify these answers during the creation of a survey. It is possible to create so-called additional questions. These questions appear in a survey only when a survey responder answers to a specific question in an assumed way. During the process of survey creation a creator has to specify the type of the survey. If a survey is focused, a creator will also have to make a list of addresses for a desirable responder class. When the process of a survey creation is over, the tool will generate and send unique message to each responder in a class. Each of these messages contains unique URL. The URL points to the start location of a survey.

4 Responders respond to a survey in a question by question mode. In a case of a check-boxes question type a responder may select arbitrary number of offered answers. Contrary to a check-boxes type, a radio-buttons and a combo-box allows a selection of the exactly one among offered answers. Complete responses are stored to a database for later processing. An on-demand survey statistics contains only numeric results. One may use any spreadsheet program available on the market to create graphical representation of survey statistics. C. Security and Privacy Issues A survey creator is allowed to create the Web-survey only if he previously creates his user-account. To create the survey and see its results or statistics, he must be logged into the Web-tool. Therefore, the survey results are protected from unauthorized users. Survey responders are typically anonymous, especially free survey responders. It is important to notice that if they weren t anonymous, they would be reluctant to answer the questions. Anonymous responders typically give more honest responses. Each of the responses is stored into the database without any additional information about its responder. In this way we protect the responder s privacy by guaranteeing its anonymity. Focused survey responders give away their anonymity in so far by giving their address to the survey creator. As mentioned before, this procedure is necessary for designating the appropriate survey to the focused user. As we emphasized earlier, it is obligatory for requirements analyst to conduct more then one elicitation technique (e.g. group meeting) to gather information from their stakeholders. So, this is a preferable way for him to collect addresses from potential survey responders. Figure 4 Generated access-number To prevent malicious bots from ruining the survey (i.e. invaliding the survey results), in a case of free survey we use special access control. It randomly generates accessnumber and presents it to anonymous responder as a picture. As we can see in Figure 4, only human vision can recognize the written digits, enter the correct accessnumber and start the survey. This procedure verifies the access of a human to a Web-survey. To provide additional security in Web client-server communication, it is advisable to install Secure Socket Layer (SSL) support. This procedure consists of requesting, getting and installing a Web Server SSL certificate issued by the authorized third party (e.g. VeriSign). This kind of communication is encrypted and data is protected from the intruder s intentions. IV. RELATED WORK Surveying as discipline evolved from the printed form to the online, Web-form. Web-surveys allow the receipt of information from multiple responders and user classes quickly and effectively. They have proven to be more cost effective, convenient, and accurate than traditional papersurveys, and they can reach out to a wider audience as well [9]. Most online survey tools do not require downloading or installing the software. They allow creating of its own survey, but also usually constrain it with a certain number and limited types of questions. Time for conducting a survey can also be out of reach for a survey creator, unless he pays the certain price. Survey results are treated with special regard. Because survey results represent complete information for the survey creator, it is usually put on a price. So, implementing our own Web-survey tool shows good perspective for wide usage of the tool in software requirements elicitation and other areas of interest. V. CONCLUSION A. Results Software development stakeholders are persons with different levels of ICT knowledge, various business skills and social affinities. In addition, stakeholders (as survey responders) can be geographically distributed and unreachable at the same time. So, implementing Websurvey tool and placing it online can solve the specified obstacles. Survey represents one of the most common types of quantitative, social science research [10]. So, Web-survey tool is eligible for application in other areas than only software requirements elicitation. Its functionality of creating surveys makes it useable in teaching enhancements (e.g. student feedbacks, mini-tests) and other practical purposes. Web-survey tool for software requirements elicitation solves several shortfalls of paper-surveys. One of the most common shortfalls is not-answered question, therefore lack of desired information. Web-survey tool solves it by not allowing the user to proceed to the next question until he answers the previous one. Possibility of invalidated answers is also prevented by the tool interface. Imperfect recall is dealt with tracing the activations of URLs given to the focused responders and sending the message with the unique URL again as a reminder. The possibility of low reliability of unclear answers is excluded, but free text comments are still saved as additional information for the requirements analyst. B. Further Work Implemented Web-survey tool shows two inclusive ways for improvement. One way to improve the survey tool itself is providing the user with correct set of information (on-demand survey statistics) and also represent it graphically (charts, diagrams, etc.). Such a data representation of gathered user requirements should additionally facilitate the decision making process at the beginning of new software product development. The other way for improvement is to extend the tool functionality with support of some other elicitation techniques (e.g. scenarios). Very useful combination would be additional support for online group collaboration between stakeholders, which typically includes sending notes and documents exchange.

5 ACKNOWLEDGMENT Authors would like to thank Željka Car, Ph.D. from Department of telecommunications, for the support in querying the students with paper-surveys during undergraduate course Telecommunication Software Design. Such practical paperwork gave the authors a good insight of this requirements elicitation technique. REFERENCES [1] K. E. Wiegers, Software Requirements, Microsoft Press, [2] J. A. Goguen and C. Linde, Techniques for Requirements Elicitation, Proceedings of Requirements Engineering '93, IEEE Computer Society, [3] J. Coughlan, R. Macredie, Effective Communication in Requirements Elicitation; A Comparison of Methodologies, Requirements Engineering 7: 46-60, Springer-Verlag, [4] F. J. Fowler, Improving Survey Questions: Design and Evaluation, Applied Social Research Methods Series, Vol. 38, Sage Publications, London, [5] Extreme Chaos, technical report, The Standish Group International, [6] R. S. Pressman, Software Engineering: A Practitioner s Approach, 5 th ed., McGraw Hill, [7] G. Playle, C. Schroeder, Software Requirements Elicitation: Problems, Tools, and Techniques, CROSSTALK - The Journal of Defense Software Engineering, 9(12), December [8] Jason Hunter, William Crawford, Java Servlet Programming, 2 nd ed., O Reilly, April [9] Guide to Online Survey Tools, NPower NY, [10] Writing Guide - Surveys, Writing@CSU, [11] D. Radošević, M. Sajko: Searching the Internet How Do We Do It, 6 th International Conference on Intelligent Engineering Systems: , INES 2002, Opatija, [12] V. Dumičić, M. Sajko, D. Radošević: Designing a Web-Survey Questionnaire Using Automatic Process and a Script Language, Proceedings of the 13 th International Conference on Information and Intelligent Systems: , Faculty of Organization and Informatics, Varaždin, 2002.