The software requirements elicitation comprises an .... only if he previously creates his user-account. ... survey tool and placing it online can solve the specified.
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-10000 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])
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.
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.
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.
lud es >
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.
>
WEB-SURVEY TOOL
