Requirements Engineering: Elicitation Techniques - DiVA

2008:PR003

Requirements Engineering: Elicitation Techniques Sai Ganesh. Gunda

Source:http://www.marcocioffi.com/archives/2005/04/requirements-engineering/

MASTER’S THESIS

Software Engineering, 2008 Department of Technology, Mathematics and Computer Science

MASTER’S THESIS

Requirements Engineering: Elicitation Techniques

Abstract

Requirement engineering is the first and crucial phase in the development of software.

The main aim of the requirement engineering process is gathering of requirements. It

involves set of activities like system feasibility study, elicitation analysis, validation and

management of the requirements. There are many methods already exist to perform the

requirement gathering process and the software developers apply them to gather the

requirements but still they are facing so many problems in gathering the requirements

due to the lack of knowledge on result of the methods and selection of appropriate

method. This affects the quality of software and increases the production cost of

software. this paper presents the literature study and the experimental case study on

analyzing and compare different methods for requirement gathering process, this

provides the flexibility to requirements engineers to know the characteristics and the

effectiveness of every method, it is useful to select the particular elicitation method

depends on the type of application and the situation. And this analysis may be useful for

the future development of new methods for requirement elicitation.

Author: Sai Ganesh. Gunda Examiner: Dr. Steven Kirk Advisor: Dr. Steven Kirk Programme: Software Engineering, 2008 Subject: Software Engineering Level: Master Date: June, 2008 Report Number: 2008:PR003 Keywords Requirement Engineering, Elicitation, Functional Requirements, Non- Functional

Requirements, Questionnaires, Interviews, Requirements Reuse, Prototyping, Social Analysis, User Centred Design, JAD and Brainstorming.

Publisher: University West, Department of Technology, Mathematics and Computer Science, S-461 86 Trollhättan, SWEDEN Phone: + 46 520 22 30 00 Fax: + 46 520 22 32 99 Web: www.hv.se


Acknowledgement I want to thank Dr. Steven Kirk (supervisor), for his invaluable guidance and suggestions. I also want to thank my parents, for their support and belief in me. Without them, I would never be the person, who I am now.

1


Contents 1. Introduction...................................................................................................................................3 2. Background....................................................................................................................................4

2.1 User requirements................................................................................................................5 2.2 System Requirements ..........................................................................................................5

2.2.1 Functional requirements........................................................................................5 2.2.2 Non functional requirements ...............................................................................5

2.3 Requirements engineering ..................................................................................................6 3. Requirements Engineering Process............................................................................................6

3.1 Feasibility study....................................................................................................................8 3.2 Requirements Elicitation and Analysis .............................................................................9

4. Classic Requirements Elicitation techniques ..........................................................................10 4.1 Interviews............................................................................................................................11 4.2 Questionnaire .....................................................................................................................11 4.3 Social analysis .....................................................................................................................12

5. Modern Requirements Elicitation Techniques.......................................................................13 5.1 Prototyping .........................................................................................................................13 5.2 Requirements reuse ...........................................................................................................15 5.3 Scenarios .............................................................................................................................16 5.4 Brainstorming.....................................................................................................................16 5.5 Joint Application Development.......................................................................................17 5.6 User Centered Design .......................................................................................................17

6. Method .........................................................................................................................................18 7. Results ..........................................................................................................................................20

7.1 Experimental Survey .........................................................................................................20 7.2 Literature Review...............................................................................................................24

8. Discussions ..................................................................................................................................26 8.1 Experimental Survey .........................................................................................................26 8.2 Literature Review...............................................................................................................26 8.3 Comparison of results from Literature Review and Experimental Survey ...............27 8.4 Margin of Error..................................................................................................................27

9. Future Works...............................................................................................................................28 10. Conclusion.................................................................................................................................28 12. References..................................................................................................................................29 A. Appendix.....................................................................................................................................36

2


1. Introduction Nowadays the usage of computer applications and software is increasing day by day and these systems play a vital role in the management of businesses existing today. Most of the software products developed today is to extend the existing system functionalities. Due to the today’s commercial on the shelf products development [1, 2], the vast range of fields that uses the computers today, different services are expected by customers, which make it difficult to develop software that fulfils the expectations of the users. Since the 1960’s the development of computer based systems has faced many problems [3, 4] that leaded to too many projects being delayed and over budget. The systems that were delivered also did not meet the requirements, or satisfy the intended purpose which resulted in the dissatisfaction of the users. The main reason that could be stated for this problem is difficulties faced in the gathering of requirements [4], as requirements engineering is the first step in the software development. Whenever the requirements engineers lack the knowledge of the performance and characteristics of the different elicitation methods, the activities related to requirements will fail, thus leading to wrong gathering of requirements that makes the wrong requirements specification document. The wrong specification document set the improper objectives in product development phase. The product developed with the wrong specification document never meets the customers’ expectations and the intended services. Moreover, the changes in the requirements in the middle of the project development phase will lead to delay and increased cost. There are some famous cases of software failure due to improper use of requirements elicitation methods. One of such famous case is the Ariane5 Flight 501 (European Ariane 5 expendable launch System) where the requirements specifications of Ariane4 were reused. But, Ariane5’s flight path was much different which could not be handled by the code developed using Ariane4’s requirements specification. This is one of the examples which show the importance of requirements elicitation and also the importance of selecting the appropriate elicitation method [57]. Goals This paper describes the different activities involved in requirements engineering process. The main goal of this paper is to analyze and compare of the different methods for the requirements elicitation process, which will be useful to find the different characteristics and the performance of different elicitation methods both in theoretical and practical approach. Hence the results presented in this paper are acquired using both literature study and an experimental survey. The survey on the different elicitation methods that forms the part of the paper is conducted among the experienced people who are currently using the requirements elicitation methods in the software industry. Literature review presented in this paper compares the different elicitation methods according to their characteristics. This papers deals only with the requirements elicitation part of the requirement engineering process. The research presented in this thesis commences with the Introduction section, in which the current problems faced in the process of requirements elicitation and the methods used to solve it are presented. The work done in this paper may be small and limited, but it will be useful for the development of new methods in the future.

3


Section 2 includes the background that presents the basic information required to understand the topic and rest of the paper. This section provides the definitions and the importance of the requirements engineering process in the software development. It deals with the different activities involved in the requirements engineering process like feasibility studies and requirements elicitation and analysis. Section 3 contains the description of different activities involved in the requirements engineering process and the inputs and out puts of the requirements engineering process. Subsections in this, describes the topic of requirements elicitation, which forms the main topic of this paper. This subsection describes the purpose of the requirements elicitation in the requirements engineering process and the different activities involved in the requirements elicitation process with diagrammatic representation. Section 4 and 5 starts with describing various methods for the requirements elicitation process, this provides the basic guide lines to perform the different methods of requirements elicitation. This section is based on the literature study of experts’ articles in the field of software engineering and requirements engineering. The articles are gathered from various sources, each describing different elicitation methods. Section 6 describes the method used to gather the material from the different sources and the method used for conducting the survey among experienced professional and their opinion on the elicitation methods and the usage of these methods in the industry level. Results section provides the result of the research. It describes the comparison of different elicitation methods based on the experimental survey and the literature review. This section also includes the discussion of every observed result in detail. Future work that can be carried on and the conclusion derived from the work are followed by the results section.

2. Background DEFINITION “Requirements engineering is the branch of software Engineering concerned with the real world goals for, Functions of and constraints on software systems. It is also concerned with the relationship of these factors to precise specifications of software behaviour, and to their evolution over time and across software families” [5] There has been many research works already conducted on this topic from 1990, such as Basher Nuseibeh’s paper “Requirements Engineering Road map”[5] and “Requirements Elicitation Techniques: Analyzing the Gap between Technology Availability and Technology Use” by Ann M. Hickey, Alan M. Davis and Denali Kaiser[13]. However, these papers did not contain an actual analysis of the different methods used in the Industrial level. This is a vital part to gather the advantages and disadvantages of the methods in a practical way. In order to fill this gap, a survey is added as the part of this paper.

4


Requirements specify the services that should be provided by the system, the method in which they should be provided and constraints in providing these services. Requirements forms the first phase in the software lifecycle, as given by Somerville “Requirements are the things we should discover early stages of the software development life cycle”. The gathered requirements describe how the system will behave, system domain, user level facilities and the constraints on which the system should be operated [4 6]. There are typically 2 main types of these requirements, which will be described in the following sections.

2.1 User requirements User requirements describe the expected services from the system, constraints on achieving them and the way the system provides the requirements [6]. It must be written in such a way, that it must be understandable by a person without technical experience and background knowledge. These requirements are generally defined using the external activities and behaviour of the system and is never defined based on system design or implementation [6, 7].

2.2 System Requirements System requirements provide the in-depth knowledge of the user requirements. System requirements are the basic principles that should be followed to design the system architecture [6]. The software engineer should analyse these requirements to know about what exactly has to be implemented and provided in the proposed system [7]. This is very important and useful to make an agreement or the contract for the implementation of the system [6]. System requirements are classified in to different types as follows,

2.2.1 Functional requirements These are the functions/ services that define [6, 8]

• What the system is expected to provide • How the system should respond or react to particular input or situation • What the system should not do • Constraints on implementing the above said requirements.

These requirements mainly depend on the users of the system and the type of software that is developed [3, 6]

2.2.2 Non functional requirements These requirements define the effectiveness of the functions provided by the system. They are not provided by the system, but they affect the functions provided by the system [8]. Any system that does not provide a reliable service and also security measures against any threats will be not being considered as a success. These requirements form the basis of the quality of the system. For example, a Banking system that satisfies every functional requirement, and does not provide any non functional requirements is sure to fail. Thus, the failure of the non functional requirements will lead to the failure of the whole system. Non functional requirements include [1, 6, 8].

5


• Safety and security measures provided by the system • Reliability and efficiency of the system • Portability and integrity of the system • Memory used and cost effectiveness of the system

This also includes budget, scheduling, etc.

2.3 Requirements engineering “Requirements engineering is a branch of system engineering”[5]. The work in the requirements engineering is related to the analysis of the system boundaries and the system characteristics. The requirements engineering involves requirements elicitation, documentation and maintenance of the requirements. Requirements engineering is a repeatable and systematic technique. In each and every phase of the requirements engineering lifecycle, the requirements are analyzed and evaluated to find the consistency and completeness of the requirements [4, 9]. The requirements that are gathered from this process are applicable to whole system and not only for a single component. “The cost of the requirements engineering depends on the size and the type of the system that is being developed. For large systems it wills costs 15% of the total budget only for formal requirement specification, for smaller systems it varies from 8 to 10 percent” [4, 5]. There are many problems due to usage of wrong requirements [4, 10]. They are,

1. Delayed and over budget projects. 2. The product does not reach the intended purpose. The customers, who are

actually paying for the system, are not satisfied. 3. The errors encountered in the development of the system, is the reason for the

problems in using the system. 4. The continuous use of such system makes it error prone, and thus increases the

cost of the maintenance. Rectifying an error resulted by the wrong requirement is much harder than correcting the errors occurred in the later stages of the project. “Correcting the requirements errors requires the rework on system design, implementation and testing. The cost of correcting the requirements errors is 100 times more than the cost of the simple errors occurred in the later stages of the project” [4].

3. Requirements Engineering Process A process is organizing a set of activities; it is a continuous transformation of input to output activity [2, 4]. Requirements engineering is also an organized and structured process with the set of activities to transform input to output followed by elicitation, validation and maintaining the requirements [6, 10]. The activities involved in the requirement engineering include,

• Feasibility study • Requirements elicitation and analysis

6


• Requirements validation • Requirements management • Requirements documents.

Unlike the Software engineering process, Requirement engineering is also made up of different activities that connect, interact and lead one another to form a whole Requirements engineering lifecycle. This lifecycle is represented in figure 1, and is followed by an explanation of various activities.

Feasibility study

Requirements gathering

Require Validation

Require specification

Feasibility study

User and system requirements

System models

Requirements Document

Figure 1: Requirements engineering process [6]. The detailed background theory of the activities showed in the figure 1 describes planning and scheduling of the activities, inputs and outputs of the every activity, tools used to perform each activity. The performance of the activities depends mostly on the people who are involved in the requirements engineering process; they will decide the major issues like where and when to perform the activities. The requirements engineers will decide the usage of the different available resources depending on the situation and the necessity [6]. “The requirements engineering process is an input and output activity” [4], it mainly depends upon the four things to perform the requirements process, which are known as the inputs of the requirements engineering process. They are [4],

1. Existing system document 2. user and stake holders requirements 3. organization and business procedures 4. Domain Knowledge.

The outputs for the Requirements engineering process are,

1. Final requirements 2. Specification of system 3. System models

7


Diagrammatic representation of Inputs and outputs of a requirements engineering process

Existing system document

Requirements engineering process

Figure 2: Inputs and Outputs of a Requirements engineering process [4].

3.1 Feasibility study The first step in the Requirement engineering process is the feasibility study. The Feasibility study is based mainly on the necessity of the proposed system in the organization and the domain information of the system. The result of the feasibility study provides us with the report of the worthiness of the proposed system. It also recommends whether the proposed system should be developed or not, and whether the requirements engineering process should be initiated for the proposed system [6, 11]. This feasibility study helps the requirements engineers to answer the questions like[6],

• Does the overall objectives of the organisation is satisfied by the system? • Can the system be developed within the proposed budget and timeline? • Can the proposed system made to co-exist with the existing systems?

In the problems specified above, the first one is most critical, as it answers the problem whether the system satisfies the intended objective or not. Unless the system answers this problem positively, there is no use in developing the system. Any organization that desires to develop the systems should have the clear arguments and statements on their objectives. This feasibility study involves set of activities such as information gathering, assessment and the report of the information [6]. The assessment activity is used to find the different solutions for the problems faced in the feasibility study process. Once the solution is acquired, the questions can be answered from the source of information. The sample questions that arise in this cyclic process are [6],

1. The reaction of the organisation if the proposed system is not implemented.

Stake holder’s requirements

Business and organisation procedures

Domain knowledge

System models

Final requirements

Specification of system

8


2. Can the existing system integrated with the proposed system to solve the problems.

3. The level of problems that has to be solved by the proposed system. 4. Can the proposed system be developed and used with the existing technology or

newer technology is needed? 5. What exactly the proposed systems should support and not be support?

The main source for the feasibility study activity includes the total management department, technical professional, expert’s judgement and the people who are familiar with the usage and type of the system. The required information in this activity is gathered from analyzing the different types of user expectations on the new system. The gathered information is used for the preparation of the feasibility report. This report is basis for the critical decision regarding the changes in system development decisions, schedule, and budget. The feasibility study report some times affects and changes the overall objective of the organization.

3.2 Requirements Elicitation and Analysis Requirements elicitation is the process of gathering the requirements. In this process the technical professional in the organization, like software developers and the system engineers, work together with the users of the system and the customers [12]. This process is useful in finding the problems that has to be solved. The problems include,

1. What the proposed system should provide? 2. What are the expected services form the system? 3. What are the required characteristics of the system? 4. What are the required hardware and software constraints of the system?

Requirements elicitation process includes a chain of processes that interact with each other to produce requirements documentation. The lifecycle of the requirements elicitation process is represented in figure 3 and the steps involved are explained [6] Diagrammatic Representation of Requirements elicitation process

Requirements Requiremen

ts c heck

Background Knowled

Requirements ge priority

Requirements documents

Gathering re

Conflict resolutionquirement

Figure 3: Requirements elicitation process [6]

Requirements classify

9


Back ground Knowledge The analyst must understand the back ground and the domain knowledge of the application that is being developed. Example: If the system is developed for ATM, the developer should have some basic knowledge of how the ATM works. Gathering the requirements This is the activity of discovering the requirements by involving with the stakeholders and users. Requirements classification This activity includes the organizing of the requirements gathered from different sources. Requirements conflict This activity involves with the stakeholders and requirements engineers. This is used to solve the problems in the requirements that contradict the organization and business rules. Requirements Prioritization Discovering the important requirements by interacting with the stake holders and organize them in to most priority order. Requirements check This activity involves checking the stake holder’s expectations on the system with the gathered requirements. Requirements elicitation process not only helps the organization to gather the requirements, but also it analyses the requirements and the business procedures of the organization. The requirements elicitation and analysis is a difficult activity in the requirements engineering, due to the following reasons [6].

1. Lack of technical knowledge and unawareness of the technical aspects of the system from the stake holder’s side.

2. Some times they may demand unrealistic things and they do not know what they exactly expecting form the system.

3. Stakeholders express their requirements in the most general terms; it is difficult to find the technical aspects of the system form the general terms.

4. Different people expect different services form the proposed system, requirements engineers has to discover the good sources of requirements and commonalities.

5. Business procedures, political influences and the budget matters where the clear analysis is required.

4. Classic Requirements Elicitation techniques These requirements elicitation techniques have been used for a long time. These are tested and proven methods. The different classic requirements elicitation processes are,

10


4.1 Interviews Interviews are the commonly used and most popular method for requirements elicitation [4, 18]. In this method the analyst and the engineers of the requirements engineering process discuss with the different types of stake holders to understand the requirements of the system and the objective they have to fulfil in the system [16, 17]. There are typically 2 main types of interviews, which will be described in the following sections [4, 16, 52].

1. Closed Interview: In this interview the requirements engineer prepare some predefined questions and he tries to get the answers for these questions from the stake holders.

2. Open interview: In this interview the requirements engineer does not prepare

any predefined questions, and he tries to get the information from the stakeholders in open discussions. He mostly concentrates on finding the stake holders expectations on the system.

Generally the interviews start with the predefined questions [4]. However, in the process of the interview, a lot of different considerable things may arise, that leads to open discussion. Interviews are effective for understating the problems in the existing system and to find the general requirements of the stakeholders. But, it is difficult to decide the boundaries of the proposed system and the organization procedures using this method. To make the effective interview the requirement engineer and the stake holders has to perform in the following ways [4, 16, 17]. 1. Interviewer should be patient enough to listen to the stake holder’s views and the requirements. He should be open-minded. 2. Stake holders should be expressive in the interview; they should express their views in definite context.

4.2 Questionnaire Questionnaires are one of the methods of gathering requirements in less cost [26]. Questionnaires reach a large number of people, not only in less time but also in a lesser cost. But the results extracted from the questionnaires should be clearly analysed. The result from the questionnaires mainly depends on the two factors [20, 23, 24],

1. Effectiveness and the design of the questionnaire 2. Honesty of the respondent.

A well designed and effective questionnaire can be used to decide the actual user requirements, objectives and the constraints [22]. A good structured questionnaire influences people to answer honestly thus making it possible to gather reliable results from a large group of people. The data collected through questionnaires can be used to analyze the obtained results, both systematically and quantitatively [26]. The designing of questionnaire is a multi stage process and should be viewed accordingly.

11


The steps involved in designing and administering a questionnaire are [22, 26],

1. The purpose of the survey should be defined 2. The sampling group (respondents to the survey) should be decided 3. Preparing and developing the Questionnaire 4. Conducting the Questionnaire process 5. Gathering and analysing the results

Steps in arranging a questionnaire [25]

• The questions should be arranged well, so that general questions are followed by particular questions.

• Arrange the questions such that, easy questions comes first. • Arrange the questions in a order of known to unknown • Try to use closed format questions in the beginning. • The questions relevant to the main subject should be given high priority and

stated at the start of the questionnaire. • Avoid personal and intimate questions at the beginning

The general factors which affect the usage of the questionnaire are [24, 25, 26]

1. The available resources to gather the requirements: The usage off the questionnaire mainly depends on the available resources. When the resources and the funds are less, the questionnaire is the best method to gather the requirements because the cost of the administrational is very less. The questionnaire can also be used to save the time by gathering the requirements from a large number of people in a very short interval.

2. Type of Requirements that has to be gathering: The type of the information that has to be gathered depends on the level of the respondent’s knowledge and background.

3. Anonymity provided to the respondent: These are the general factors to use the questionnaire but there is no particular rule as and when to use the questionnaire for gathering requirements.

4.3 Social analysis Social analysis is also known as Observation. Observation is the method of collecting requirements by observing the people doing their normal work. This method is generally used to find the additional requirements needed by the user, when the user is unable to explain their expected requirements from the new product and problems with the existing product. This social analysis is of four types [33, 34]. They are, Passive observations- This social analysis is carried out without direct involvement of the observer in the society. The observation of the peoples work is carried out by recording using videotapes, video cameras and surveillance cameras. The

12


documentation of the problems and the requirements are prepared from the recorded data. Active observation- This observation is carried out with the direct involvement of the observer. The people are provided with the new product prototype or existing product to perform the operations on the product. The observer provides the domain knowledge to the user to work with the product and he makes the report of the requirements of the people by observing their work with the product. Explanatory Observations- In this type of observation, the users talk loudly, explaining what they are doing, while using the product. The observer takes notes using the explanation given by the user. Ethnography [4,33,58] - In this method the observer is completely immersed in the society. The observer goes through in depth observation of the society and their works. There is no particular formula to carry out this method but it is time consuming and expensive method to gather the requirements.

5. Modern Requirements Elicitation Techniques There are different types of modern elicitation techniques, which will be described in the following section.

5.1 Prototyping Prototype is the representations or visualizations of the actual system parts [2, 4, 27]. The prototype is designed in the early stages of the implementation of the project. It provides the General idea of the actual system functions and the work flow. Prototyping is used to gather the requirements from the users by presenting GUI based system functions [28]. The main aim of Requirements Elicitation is to gather the requirements before the product is developed. But it is difficult to discover the additional requirements until it comes in to usage or some body is actually using it [1, 4, 28]. The process of gathering the requirements from the stakeholders and the end users is limited and it is difficult to discover their expectations and the requirements on the new product with out providing some model that resembles the appearance of the real product. A prototype represents the actual product in both functional and graphical sense [6, 29]. It provides the flexibility to the users and the stake holders to work with the initial version of the product to understand the system and discuss them to think of the additional and missed requirements. Prototyping is a most expensive than the all other methods of requirements elicitation [30].

13


Diagrammatic representation of the Prototype lifecycle model

Figure 4: Prototype life cycle model source [3]. Prototypes are generally developed in the early stages of the actual product development process. The software developers use these prototypes in the situations like,

1. When the users are unable to express their requirements. 2. If it is a new product and the users have no experience with this product. 3. When ever the requirements analysis and feasibility studies is difficult.

These prototypes are typically of two types. They are [1, 4, 31, 32],

1. Throw-away prototypes: This type of prototype is not reusable and hence is discarded when ever the requirements elicitation process is complete.

2. Evolutionary prototypes: This type of prototypes is reusable. They are evolved or improved according to the feedback and is given as the original product.

Advantages of Prototyping

• Reduces time of development. • Reduces cost of development. • The users provided with a visual representation, thus facilitating system

implementation. • Provides high level of user satisfaction. • The ways in which the system can be enhanced in future is known.

Disadvantages of Prototyping

• The users may expect the finished product to be the same as the prototype • Developers may be tempted to stop with the prototype. • Can lead to unfinished system implementation.

14


5.2 Requirements reuse In the field of software engineering reusing the requirements of the existing system is common method of requirements elicitation [2,4,33, 34]. Using the existing Knowledge to develop the new product has many advantages that include low cost and less time. Though each product has their own type of stake holders and users, there is still number of situations that the reusing of the requirements takes place [4, 35]. Example, 1. User interface designs of the application domain information

2. Different companies’ database and security policies. Nowadays in software industries the more than half of the requirements for the new project requirements are acquired from the existing projects [2, 6, 36]. Although there is need to check the requirements before they are used in the proposed product, the reused requirements are already validated and analysed thus reducing the time of testing. “Successful reuse starts with the having an organizational culture that consciously encourage reuse rather than reinvention” [2]. The various questions that help us to find the reusable requirements are [36],

• What are the problems in the existing product? • What the proposed product should provide to over come the difficulties in the

existing product? • Who are the users and the stakeholders of the existing and proposed products?

It is difficult to say that particular proposed product is completely different from the existing product, because it is easy to find reused requirements in any project requirement specification [2] Diagrammatic representation of Reusable requirements:

Recognize which existing

Reusable requirem

Requirements

conte

Figure 5: Reusable Requirements [2]

Stake holders will provide the related documents and the existing system documents to find the reusable requirements [1]. Some times the documents of the existing product questionnaire are also helpful in finding the source of reusable requirements. Finding

15


and using the reusable requirements for the projects is the best way of requirements elicitation [6, 36, 37].

5.3 Scenarios The scenarios of the particular system will give the working method of different interaction sessions or the situations of the system [38, 39]. These scenarios are helpful for requirements elicitation in two ways. They are [40].

1. Analyzing the different sessions of the system gives the flexibility to find the requirements

2. The user response after interaction with the scenarios will give the flexibility to find the requirements.

Scenarios are generally used after the initial requirements specification is finished [4,41, 42]. The scenarios are produced by the developers when the initial requirements are collected and the basic idea about the functions to be provided by the system is prepared. The developed scenarios will be used to find and prepare the detailed requirements specification. The method to prepare the scenario is as follows [4, 43, 44]

1. Scenario should start with the particular state called the starting point 2. Every state should be connected with the next state. 3. Every state should contain the Normal, exceptional and alternative flow of

events. 4. Every state should describe the actions performed on that state. 5. The interaction should be ended with the final state.

Generally the software industries use the text based and picture based scenarios [2, 4]. The developer provides the scenario model for the system. The user and the requirements engineer work with the scenarios of the proposed system. The requirements engineer takes the notes of the user comments, suggestions and difficulties that user faced when interacting with the scenario. Scenarios of the proposed system are always prepared with the involvement of the stake holders to clarify what they require in each interaction. Use cases developed for the system are the basic guidelines for the scenario models.

5.4 Brainstorming Brainstorming is a techniques used to generate new ideas and find the solution to a specific issue [2, 39, 45,58]. This is conducted as a conference with six to ten members. The members are from the different departments and domain experts are also included. This conference is headed by the organizer, who states the issue to be discussed. The conference is generally held in a round table fashion. Every member person is allotted with certain time interval to explain their ideas. Notepads are provided to all members to write their ideas and suggestions. The team of brainstorming will then decide the best idea by voting from the group and that idea is selected as the solution to the issue discussed in the conference.

16


Brainstorming can be used to answer the following questions [45,58],

• What exactly the system should provide • What are the business and organization rules required to follow • What type of questions should be there in the interviews and questionnaires? • What are the risk factors effect the proposed system development and what to do

avoid that?

5.5 Joint Application Development It is an organized and structured technique for requirements elicitation [46]. This is conducted in the same manner as brainstorming, except that the stakeholders and the users are also allowed to participate and discuss on the design of the proposed system. The participant in these sessions does not exceed 20 to 30 [46]. The requirements engineers start the session by providing the general overview of the system. The discussion with the stakeholders and the users continues until the final requirements are gathered. This leads to elicitation of better requirements in the first attempt and it reduces the time spent on the requirements phase [46]. The success of the JAD depends on [47,58]

1. leader of the JAD session 2. Developers, end-users and the stakeholders of the product. 3. Group involvement.

5.6 User Centered Design This method is similar to Joint Application Development. The one difference is that the user acts as the part of the development team. The user takes active part in the designing and development of the system [48,58]. The user provides his ideas and contributes his suggestions as a member of the development team. The activities involved in user centered design shown in figure 6. Diagrammatic Representation of User Centered Design Activities

Figure 6: Activities Involved in user centred design [59]

17


Advantages of User Centred Design [49,58]

• The user is closely involved with the development • The user feedback can be obtained immediately • Reduces time and cost spent on gathering user feedback.

6. Method There are various articles and papers present on the topic of Requirements Engineering. Some of them are presented using Literature review and others using various practical means. There are also papers on requirements engineering for specific applications. However, very few are the papers that present these two perspectives together [51-56]. The main constraints that were considered for choosing the methods for this thesis work were time, cost and reliability. Literature review, as it is gathered from reliable sources, proved to be much reliable and cost free. Though much time was spent on collecting the sources, it proved to be an effective method. On the other hand, the practical method has to be as reliable as Literature review. Interview would have been the best method if not for the time and cost constraints. It is not possible to meet many experts in the available time. Questionnaires require much less time than Interview as it could be distributed at the same time to may respondents. However, care was taken in choosing the respondents in order to achieve the reliability. The methods used to conduct the survey are explained later. The other reasons that these methods were chosen are,

• Literature review is one of the methods that are very effective to read and analyze various papers, articles and books presented on the topic.

• To have a deeper understanding of the topic, one must be aware of as many different views and opinions of the experts. Literature review is a best method to achieve this.

• On any aspect of engineering, theoretical knowledge alone is not helpful when it comes to real world applications. It is important to have practical knowledge. It is on this basis that Experimental survey was chosen as one of the perspectives for this paper.

• It is always a best approach to compare the practical and theoretical results so as to have a more reliable result. Hence, Literature review and Survey was selected.

Literature review A properly written literature review filters the necessary information from the sources that is analysed. The literature review in this paper mainly focuses on the materials gathered from different books and the articles published in the IEEE, ACM and SCIRUS by different experts in the field of requirements engineering and the software development. The literature review for this thesis work was conducted using information gathered from ten books and approximately thirty to forty papers.

18


The appropriate keywords to filter the papers in IEEE and ACM libraries were obtained by using random keywords in the GOOGLE AND YAHOO search pages. These keywords were then used in the various libraries to get the most appropriate papers on the topic. Once the papers were found, the following parameters were used to select the papers for thesis. They are, Reliability – In general, papers presented in IEEE and ACM are reliable. However, papers presented by professors and lecturers were given higher priority. The articles that were selected were also mainly written by professors. In the case of the Books, the book used for the course literature was selected. Other books used in this thesis are selected based on their relevance and expertise on the topic. Timeline – Requirements engineering is a new field when compared with other software engineering processes. But it also follows some basic principles of software engineering. The papers were chosen such that, they contain most advanced information on the topic. The papers referenced in the thesis are mostly recent papers, which were presented when the requirements engineering started to shape up. However, to explain basic principles some old and much reliable papers were selected. Reputation – The papers used in this thesis were also selected based on their reputation. Most of the papers presented in this thesis are cited many times by reliable authors. Goggle Scholar was used for this purpose. References were also gathered by studying the references used in the selected papers. The results gathered from the literature review were then tabulated. And according to the authors view on the advantages and disadvantages of the various methods, they were tabulated based on their usability for a particular type of application (sample table1) or based on their cost and time usage. This table was later used to calculate the percentage and the results were plotted as a graph (Figure 13 and Figure 14) Experiment This paper does not contain only the theoretical methods of gathering requirements. But also, a practical approach is used in order to experience the problems that are faced in the real world. A real survey is conducted among the professionals working in requirements and software development field. The survey consists of questions aimed at gathering the way the professionals feels about various requirements techniques, and the problems they face in using them in the industrial level. The results gathered from the survey is analysed and discussed. It is also compared with the outcome of literature review, so as to find out the gap between the theoretical and practical usage of the requirements elicitation techniques. The main parameters that were used for the Survey are as follows, Sample Size – The number of total respondents is an important factor to achieve a reliable result. Hundred respondents would have been much more reliable, but for the time constraint. So a more appropriate size of 35 was chosen.

19


Reliability – since this survey is about Requirements engineering elicitation, the respondents must be aware of the process and should have at least basic knowledge about the process. So the respondents were chosen from the software field and also from management group of software companies. Years of experience and the educational background was also considered. Designing of the questionnaire – The questionnaire was designed after a thorough study of the effective designing of a questionnaire [21-26]. In brief, the questionnaire that was designed had a consistent flow. General information and questions formed the first section of the questionnaire, while, the in depth questions about the topic formed the second section. Moreover, apart from the personal opinions of the respondents, the methods used in their respective companies were also collected. While most of the questions were multiple choice questions, some questions were also of grading type. Conducting the survey – since the survey was conducted among the professionals mostly from Seven Indian multinational companies, E-Mail was used for distribution of the questionnaire. The respondents, after filling out the questionnaire, returned the results via E-Mail. Analysis of the results – The results collected from the respondents, were then tabulated. The percentage was then calculated based on various parameters. In order to provide the reader with a visual representation for easy understanding, the tabulated data was plotted in a Graph (Figure 7 to Figure 12)

7. Results In this section, the results gathered from Literature Review and Experimental Survey is listed down. Graphs are used for visual representation and easy understanding.

7.1 Experimental Survey The survey was conducted among thirty five professionals working in Seven Indian software concerns. The participants were from different educational background, years of experience and the field they currently work. From the thirty five participants, twenty five answered to the questions, while ten had not responded. The respondents were selected from seven different Indian companies. The results are as follows,

20


Educational Background This graph shows the number of respondents according to their educational background. It was important to plot this as this shows that the survey was conducted among members from different educational backgrounds (based on university degree), thus eliminating the possibility of the survey being conducted among a same group, for example say software developers.

0

2

4

6

8

10

12

Computer Science

InformationTechnologyBusinessAdministrationOthers (Electrical,Electronics, etc.,)

Figure 7: Respondents - according to the educational background Years of Experience In this graph, the respondents are divided by their years of experience in their relative field. This was an important aspect as later it proved that, respondents with higher experience believed that requirements engineering were an important phase in software development.

02468

101214

1-3 Years 3-5 years More Than 5years

Figure 8: Respondents – according to the years of experience Are Requirements very important for development? The respondents were asked to express their views on the importance of requirements engineering. It was interesting to find that respondents with more experience thought that the requirements engineering was an important aspect, whereas the fresher in the field had very little idea about the process. This is shown in Figure 12.

21


0

2

4

6

8

10

12

Yes No I do not know

Figure 8: Importance of Requirements Effectiveness of the method To calculate the effectiveness of the method, question no 11 was used. The respondents who believed that the requirements engineering was an important process (Figure 9) answered this question. Then a table was drawn with each method listed. For each respondent selecting the method, the particular method was incremented by one. Then, this sum was divided by the number of total respondents for this question and the percentage was calculated. The results are plotted in the graph below.

0

10

20

30

40

50

60

70

80

90

100

in p

erce

ntag

e

Interviews

Questionnaires

Social AnalysisPrototypingScenarios

Brain storming

JAD

UCD

Reused Requirements

Figure 10: Effectiveness of method used for Requirements Elicitation Method Popularity in Industrial Usage While Figure 10 shows the view of the respondents on the effectiveness of the different methods, this graph shows the method used in their respective companies. To get this

22


result, the same method used for Figure 9 was used. However, in this, all the respondents (25) were asked to tick the methods used in their respective companies. Then the same type of table used for Figure 10 was used. And each method was incremented by one according to the selection of the respondent. Then this sum was divided by the total number of respondents and the percentage was calculated. This is plotted in Figure 10. From the comparison of figure 10 and 11, it is clear that, reusing requirements is popular both among the respondents and also in companies.

0102030405060708090

100

in p

erce

ntag

e

Interviews

Questionnaires

Social AnalysisPrototypingScenarios

Brain storming

JAD

UCD

Reused Requirements

Figure 11: Popularly used requirements elicitation method in industries Comparison of the Years of Experience and the Importance of Requirements This is a combined graph of the respondents’ years of experience (Figure 8) and their view on the importance of requirements (Figure 9). It clearly showed that the higher the experience, the more the importance for requirements engineering.

0

2

4

6

8

Yes No I do notknow

High ExperienceMedium ExperienceLow Experience

Figure 12: Comparison of years of Experience and importance of requirements

23


7.2 Literature Review In this section, the result that has been formed using the literature review of various journals and papers has been presented. These sources were read, understood, analysed and results were collected. Based on the gathered results, the effective method for the type of application developed and effective method on the basis of cost and time requirements were calculated. This result is compared and analysed with the result found by experimental survey in the Discussion sections. In order to represent the collected information, the method of grading each requirements elicitation process in a numerical of zero to ten according to the authors’ opinion on the pros and cons of the method was discussed and the data was collected accordingly. However, this was a difficult method and there was question of reliability on the grade allotted. So, to overcome this, a new method was formed using the available data on the authors’ views on the usability of the requirements elicitation processes. In this method, each process and type of applications was tabulated and the process was incremented with a one if the author expressed a positive view that the particular method can be used for the particular type of application(see sample table 1). Then using this data, percentage was calculated and plotted (Figure 13). Methods Applications General

Applications Industrial Specific Applications

Scientific Complex Applications

Interviews 1+1+1+1+1+1 1+1+1+1+1+1+1 1+1+1+1+1 Questionnaires 1+1+1+1+1+1+1+1 1+1+1+1+1+1 1+1+1+1 Social Analysis 1+1+1+1+1+1 1+1+1+1+1+1+1 1+1+1+1+1+1+1+1Prototyping 1+1+1+1+1+1 1+1+1+1 1+1+1+1+1+1+1 Scenario 1+1+1+1+1+1 1+1+1+1+1 1+1+1+1+1+1+1 Brain Storming 1+1+1+1+1 1+1+1+1+1+1+1 1+1+1+1+1+1+1 JAD 1+1+1+1 1+1+1+1+1+1+1 1+1+1+1+1+1+1+1UCD 1+1+1+1+1 1+1+1+1+1+1+1+1 1+1+1+1 Reused Requirements 1+1+1+1+1+1+1 1+1+1+1+1+1+1 1+1+1+1+1 Table 1 – sample table of the method used to calculate the usability of the method for the particular type of applications. The other parameter that was used was cost and time required by each method. To gather these results, the same method used for Figure 13 was used, except that this time the authors’ view on the cost and time required by the methods were tabulated. If the method required much time it was incremented by 1. The same was done for cost also. Then the percentage was calculated. The lower the percentage, the lesser the cost and time required by the method, thus making it a most effective method, when cost and time is considered. The results were then plotted in Figure 14.

24


0

10

20

30

40

50

60

70

80

90

100

Interviews

Questionnaires

Social Analysis

Prototyping

Scenarios

Brain storming JA

DUCD

Reused Requirements

In P

erce

ntag

e

General Applications Industrial Specific Applicatons Scientific Applications

Figure 13: Method effectiveness according to the type of application

0

10

20

30

40

50

60

70

80

90

100

Interviews

Questionnaires

Social Analysis

Prototyping

Scenarios

Brain storming JA

DUCD

Reused Requirements

In P

erce

ntag

e

Cost Time

Figure 14: Cost and Time requirement of requirements elicitation methods

25


8. Discussions

8.1 Experimental Survey In the survey conducted, there were very interesting results to be observed. They are, Experience Matters If you ask an inexperienced developer he would probably say that an application can be developed just with the knowledge of the developer, where as a seasoned programmer would be more concerned about the various parameters that affects the quality of the software. This was proved by the survey (Figure 12). People with higher experience believed that requirements gathering are a much important task in software development lifecycle. Effectiveness of the method Interviews, Questionnaires and Reusing were voted by most respondents to be the most effective methods (Figure 10). It is also interesting to note that all these methods require less interaction of the developers directly with the users. Popularity of the method in Industries The industries were more concerned with the cost effectiveness of the method. Prototyping is one of the methods in which the developed model can be further evolved and presented as the final system, thus eliminating extra cost and time. And also, it is one of the methods that actually represents the system as a working model and could be easily understood by the user. Hence Prototyping was one of the methods highly popular in industries. Apart from prototyping, Reusing, Questionnaires and Brain storming were also the mostly used methods in the Industries (Figure 11) The other results that were drawn are as follows,

• People from Management Background had a slight more priority for cost than the effectiveness, whereas people with software background had much priority for effectiveness (Figure 11 and Figure 7)

• Respondents generally voted for methods that requires less interaction possible (Figure 10)

• Questionnaire was one of the methods that were voted by most number of respondents as the most effective method. (Figure 10)

8.2 Literature Review The results from the literature review were found to be more or less similar to the conducted survey, except on some points. The results are, Cost and Time effectiveness From Figure 14, it is clear that Questionnaires and Reusing Requirements was the method with less time and cost. The other result that can be drawn from this is that, the methods that had user involvement was found to take more time and cost (Figure 14)

26


The other results that were found were, • Social Analysis and Prototyping are the methods that had an average score, for

all the types of applications (figure 13).That is, they were found to be the methods that can be effective for all type of applications.

• From Figure 13 it is clear that JAD and Prototyping are found to be good for complex systems.

8.3 Comparison of results from Literature Review and Experimental Survey In this section, we give the compare the results obtained from the two methods. They are,

• Questionnaires and Requirements Reusing were found to be the popular and less time taking methods in both literature review and the survey (Figure 10, Figure 11and Figure 14).

• Developers tend to avoid interaction and direct involvement with user, and it was found to be more costly too (Figure 10 and Figure 14 )

• Though prototyping was one of the methods that required high time and cost, it was found to be one of the popular methods used in industries (Figure 11and Figure 14)

• Questionnaires was popular, but it was generally agreed that the reliability of the method greatly depend on the respondents and the type of group the questionnaire is conducted and hence is more advantageous for general applications(Figure 10, Figure 13 and Figure 14)

• Social analysis is effective but it requires high budget and timeline (Figure 10, Figure 13and Figure 14)

8.4 Margin of Error The margin of error was estimated to be around 5 percent. The group of respondents were selected in such a way that all the possible groups that might affect the requirements elicitation method were included. The respondents are from different educational background, various levels of experience and from different companies. Respondents are from developers and also from management. However, the reasons for the margin of error are as follows,

• The eighty percent of sample size consists of professionals only from the Indian companies

• The result documented here includes people from management also, which might affect the priority for the technical excellence when discussing the appropriate method of requirement elicitation.

• The survey is conducted via E-Mail, so some doubts of the respondents might be left unanswered, thus affecting the survey.

• The respondents are from only seven companies.

27


9. Future Works The thesis work can be further extended by using different methods other than questionnaire. Also, the number of respondents can be increased to reduce the margin of error and to increase the quality of the result.

10. Conclusion In this paper, the different Requirements elicitation methods are studied, compared and discussed using Literature Review and Experimental Survey. The results gathered were analysed using various parameters and is found to be interesting. Though there are various requirements elicitation methods, only some of the methods were found to be popular among both the developers and management people (Figure 10, 11 and Figure 14). Every method has its own strength, but, the selection of the method is mostly dependent on the type of the application being developed. While JAD is effective for scientific applications as it includes experts from the specific field, questionnaire is much more effective when it comes to general applications where cost and time constraints are more (Figure 13 and Figure 14). The more experienced believed in the importance of Requirements Engineering, while the less experienced had very little knowledge about the process (Figure 12). This happens due to the practical knowledge and problems faced during the development process. The more experienced people were aware of the problems and faults that will occur when the proper requirements documentation is unavailable. It also depends on the organisational rules and the development team. The survey was mostly conducted among Indian multi national companies. It was found that the much established companies followed traditional methods of requirements elicitation, whereas new companies were much open to try new methods. The established companies were much more concerned about the effectiveness of the process even if it costs more. But for the new companies, cost was an important constraint that leads them to try out new methods that showed more result in less time and cost possible. This main aim of this paper was to compare the pros and cons of various methods of requirements elicitation using Literature Review and Experimental survey. Apart from achieving this, this paper has also succeeded in identifying the opinion of the professionals in the field and along with the popularity of the methods in the companies. The paper also opens path for further study on the topic by considering various other conditions and parameters that might affect the requirements elicitation process.

28


12. References 1. Christ of Ebert: “Practical Requirements engineering solutions”, University of twente, IEEE publications, volume 21, issue 2, April 2004, pages: 16-18 http://csdl.computer.org/comp/mags/so/2004/02/s2016.pdf 2. Suzanne Robertson, James Robertson: “Mastering the requirements process”. Addison Wesley, 1998.

3. Merlin Dorfman: “Requirements engineering”. Carnegie Mellon University, interactive publishers, 1999 http://www.sei.cmu.edu/news-at-sei/features/1999/mar/Background.mar99.pdf 4. Kotonya and Ian Somerville: “Requirements engineering process and techniques”. Edition Willey, 8th Edition

5. Bashar Nuseibeh, Steve Easterbrook: “Requirements engineering: A road map”, ACM publications, Sep 2000, pages 35-46.

http://www.doc.ic.ac.uk/~ban/pubs/sotar.re.pdf 6. Somerville: “Software engineering”. 8th edition, Addison Wesley 7. Neil maiden: “User requirements and system requirements”. City university of London, IEEE publications, volume 25, issue 2, April 2008, pages 90-91. http://ieeexplore.ieee.org/iel5/52/4455615/04455639.pdf?tp=&arnumber=4455639&isnumber=4455615 8. Ruth Malan, Dana Bred Meyer: “Functional Requirements and Use Cases”. Hewlett-Packard Company, 2000. www.digilife.be/quickreferences/PT/Functional%20Requirements%20and%20Use%20Cases.pdf 9. Pie Hsia, Alan m Davis, David C.kung: “Status Report in requirement Engineering”.IEEE publications, vol 10, issue 6, Nov 1993, pages 7-79. http://ieeexplore.ieee.org/iel1/52/6217/00241974.pdf?tp=&arnumber=241974&isnumber=6217

10. Betty h.C cheng, Joanne M.atlee: “Research directions in requirementsEngineering”.IEEE publications, pages 285-303, 2007, ISBN 0-7695-2829-5 http://delivery.acm.org/10.1145/1260000/1254725/28290285.pdf?key1=1254725&key2=2821250121&coll=ACM&dl=ACM&CFID=67531224&CFTOKEN=54899420

29

http://ieeexplore.ieee.org/iel1/52/6217/00241974.pdf?tp=&arnumber=241974&isnumber=6217



11. Nakajo, T. & Kume, H. (1991): “A Case History Analysis of Software Error Cause-Effect Relationships. Transactions on Software Engineering”. Vol 17, issue 8, 1991, pages 830-838 12.Seda G¨ursesa, Jens H. Jahnkeb, Christina Obryb, Adeniyi Onabajob,Thomas Sentence, Morgan Price “eliciting confidentiality requirements in practice”.IEEE publications, page 101-116,2005. http://delivery.acm.org/10.1145/1110000/1105642/p101-gurses.pdf?key1=1105642&key2=1460250121&coll=ACM&dl=ACM&CFID=67531224&CFTOKEN=54899420 13. Hickey, AnnM.Davis, AlanM.Kaiser, Denali: “Requirements Elicitation Techniques: Analyzing the Gap between Technology Availability and Technology Use Comparative Technology Transfer and Society”. Muse publications, Volume 1, Number 3, December 2003, pp. 279-302 http://muse.jhu.edu/login?uri=/journals/comparative_technology_transfer_and_society/v001/1.3hickey.pdf 14. Goguen, J. & Jirotka, M. (Ed.). (1994): “Requirements Engineering: Social and Technical Issues”. London: Academic Press. 15. Dardenne, A., Lamsweerde, A. v. & Fickas, S. (1993): “Goal-Directed Requirements Acquisition”. Science of Computer Programming, 20:3-50.

16. Hove, S.E.; And, B: “Experiences from conducting semi-structured interviews in empirical software engineering research”. Software Metrics, 2005. 11th IEEE International Symposium, Volume, Issue, 19-22, Sept2005, Page(s):10pp.-Digital Object Identifier 10.1109/METRICS.2005.24 http://ieeexplore.ieee.org/iel5/10089/32322/01509301.pdf?tp=&arnumber=1509301&isnumber=32322 17. Tira Cohene and Steve Easterbrook: “Contextual analysis for interview design”. Department of Computer Science, University of Toronto, Toronto Canada, IEEE publications, 2005, pages 95-104. http://ieeexplore.ieee.org/iel5/10247/32667/01531031.pdf?tp=&arnumber=1531031&isnumber=32667 18. Julio Cesar shampoos do prude liete, ana Paula piano gilvaz: “Requirements Elicitation Driven by Interviews: The Use of Viewpoints”. IEEE publications, Page: 85 Year of Publication: 1996.

30


http://delivery.acm.org/10.1145/860000/858259/73610085.pdf?key1=858259&key2=2708150121&coll=ACM&dl=ACM&CFID=67531224&CFTOKEN=54899420 19. Amy Voida & Elizabeth D. Mynatt, Thomas Erickson & Wendy A. Kellogg: “Interview over instant messaging”. ACM publications, 2004, pages1344-1347. http://delivery.acm.org/10.1145/990000/986060/p1344voida.pdf?key1=986060&key2=3618150121&coll=ACM&dl=ACM&CFID=67531224&CFTOKEN=54899420 20. Dimitrics Plexousakis: “User requirements report”. Cyclades IST - 2000 – 25456. An Open Collaborative Virtual Archive Environment http://www.ics.forth.gr/isl/projects/cyclades/d1_1.pdf 21.J. Michael Moore, Frank M. Shipman: “A Comparison of Questionnaire-Based and GUI-Based Requirements Gathering”. IEEE publications, 2000, pages 35-43. http://ieeexplore.ieee.org/iel5/7013/18910/00873648.pdf?tp=&arnumber=873648&isnumber=18910

22. J.Michael Moore, Frank M. Shipman: “A general introduction to the design of questionnaires for survey research”, University of Leeds, online document. http://www.leeds.ac.uk/iss/documentation/top/top2.pdf 23. Charles F. Manski1 and Francesca Molinari: “Skip Sequencing:A Decision Problem In Questionnaire Design”. North-western University and Cornell University, 2008, vol 2, pages 264-285. http://arxiv.org/PS_cache/arxiv/pdf/0803/0803.3875v1.pdf 24. Stuart Anderson Massimo Felici: “Requirements engineering questionnaire”. http://homepages.inf.ed.ac.uk/mfelici/doc/questionnaire.pdf 25. Wai-Ching Leung: “how to design a questionnaire”. University of East Anglia http://student.bmj.com/back_issues/0601/education/187.html 26. http://www.cc.gatech.edu/classes/cs6751_97_winter/Topics/quest-design:”Questionnaire Design”.Online document.

27. Andriole s.j:“Fast cheap requirements prototype: or else”. Drexel university, IEEE, vol 11, issue 2, Mar 19994, pages 85-87. http://ieeexplore.ieee.org/iel1/52/6703/00268964.pdf?tp=&arnumber=268964&isnumber=6703

28. Ian graham: “Structured prototyping for requirements specification in expert systems and conventional IT project”.IEEE, vol 2, issue 2, 1991, pages 82-89.

31




http://ieeexplore.ieee.org/iel1/2218/2861/00087760.pdf?tp=&arnumber=87760&isnumber=2861 29. Hassan ghoma,Douglas b.h scott:“ prototyping as a tool in the specification of user requirements”. IEEE, Pages: 333 - 342 Year of Publication: 1981 ISBN:0-89791-146-6 http://delivery.acm.org/10.1145/810000/802546/p333-gomaa.pdf?key1=802546&key2=9030250121&coll=ACM&dl=ACM&CFID=67531224&CFTOKEN=54899420 30. St.louis: “what is prototyping”. University of Missouri, Online document http://www.umsl.edu/~sauterv/analysis/prototyping/proto.html 31. Davis, A: “Operational Prototyping: A New Development Approach. Software”,IEEE,vol 9,issue 5,1992,Page: 70-78.

32. Luqi and W Royce:” Status Report: Computer-Aided Prototyping”. IEEE Software,vol 9,issue 6, Nov. 1992, pp. 77-81. 33. Stephen Viler & Ian Sommerville: “Social analysis in the requirements engineering process: From ethnography to method”.IEEE, 1999, pages 6-13. http://ieeexplore.ieee.org/iel5/6303/16860/00777980.pdf?tp=&arnumber=777980&isnumber=16860 34. Goguen, J. & Linden, C.: ”Techniques for Requirements Elicitation”. 1st IEEE International Symposium on Requirements Engineering (RE'93), San Diego, USA, 4-6th January 1993, pp. 152-164. http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=324822 35. W. Lam, J.A. McDermid and A.J. Vickers: “Ten Steps towards Systematic Requirements Reuse”. IEEE publications, 1997, pages 6-15. http://ieeexplore.ieee.org/iel3/4278/12313/00566834.pdf?tp=&arnumber=566834&isnumber=12313

36. N.A.M Maiden: “Reuse oriented requirement engineering in nature”. ACM publications, Volume 20, Issue 3 (July 1995), Pages: 90 – 93, Year of Publication: 1995, ISSN: 0163-5948. http://delivery.acm.org/10.1145/220000/219324/p90-maiden.pdf?key1=219324&key2=9601250121&coll=ACM&dl=ACM&CFID=67531224&CFTOKEN=54899420

32


37. Bretty h.c cheng: “Research Directions in Requirements engineering”. ACM publications, Pages 285-303,Year of Publication: 2007. http://delivery.acm.org/10.1145/1260000/1254725/28290285.pdf?key1=1254725&key2=2821250121&coll=ACM&dl=ACM&CFID=67531224&CFTOKEN=54899420 38. Alistair Suctliffe:“Scenario-Based Requirements Analysis Alistair Sutcliffe Centre for HCI Design”. School of Informatics, City University, London, UK.Springer London,pages 48-65,2008. http://www.springerlink.com/content/jw76516n334g8241/fulltext.pdf 39. Shari, Lawrence, pfleeger: “Software engineering theory and practices”. International Edition, 1998

40. Alistair Sutcliffe: “Scenario-based Requirements Engineering”.IEEE, “Sep 2003, pages 320-329. http://ieeexplore.ieee.org/iel5/8725/27626/01232776.pdf?tp=&arnumber=1232776&isnumber=27626 41.Julio Cesar Sampaio do Prado Leite a, Gustavo Rossi a, Federico Balaguer b, Vanesa Maiorana b, Gladys Kaplan b, Graciela Hadad b and Alejandro Oliveros b: “Enhancing a Requirements Baseline with Scenarios”.Springer link,vol 2,pages 184-198,2007. http://www-di.inf.puc-rio.br/~julio/Slct-pub/baseline.pdf 42. Henrik Behrens: “Requirements AnalysisUsing Statecharts and Generated Scenarios”. FernUniversität, Hagen, 2004. http://www.fernuni-hagen.de/se/PDFs/Re2002Paper.pdf 43. Martin Glinz: “Improving the Quality of Requirements with Scenarios”. Preceedings of Second World Congress for Software Quality,sept 2000. http://www.ifi.uzh.ch/rerg/fileadmin/downloads/publications/papers/2WCSQ.pdf 44.Jarke, M. & Kurki-Suonio, R. (1998). Guest Editorial: “Special issue on Scenario Management”. IEEE Transactions on Software Engineering, IEEE, 1998, 24(12).pages 1033-1035. 45. Chauncey e. Wilson: “Brainstorming Pitfalls and Best Practices”.ACM,vol 13,issue 5,2006.,pages 50-63. http://delivery.acm.org/10.1145/1160000/1151342/p50-wilson.pdf?key1=1151342&key2=0909760121&coll=ACM&dl=ACM&CFID=67531224&CFTOKEN=54899420

33


46. Maiden, N. &Rugg, G. (1996).ACRE: “Selecting Methods for Requirement Acquisition”.IEEE, Software Engineering Journal, 11(3):183-19247. 47. Yihwa Irene Liou: “Integrating Group Support Systems, Joint Application Development, and Computer-Aided Software Engineering for Requirements Specification”.IEEE, 1993, vol 3, pages 4-12.

Unhttp://ieeexplore.ieee.org/iel2/449/7027/00284291.pdf?tp=&arnumber=284291&isnumber=7027 48. Abras, C., Maloney-Krichmar, D., Preece, J. (2004): “User-Centered Design”. In Bainbridge, W. Encyclopedia of Human-Computer Interaction. Thousand Oaks: Sage Publications. http://www.ifsm.umbc.edu/~preece/Papers/Usercentered_design_encyclopedia_chapter.pdf 49. Karel Vredenburg, Ji-Ye Mao, Paul W. Smith, and Tom Carey: “A survey of user centered design in practice”.ACM, 2002, pages 471-478. http://portal.acm.org/citation.cfm?id=503376.503460&coll=ACM&dl=ACM&CFID=68830115&CFTOKEN=60008348 50. Zheying Zhang: “Effective Requirements Development - A Comparison of Requirements Elicitation techniques”.SQM publishers, 2007. www.cs.uta.fi/re/rem.pdf 51. Wesley James Lloyd,Mary Beth Rosson,James D. Arthur: “Effectiveness of Elicitation Techniques in Distributed Requirements Engineering”.IEEE,311-318,2002. http://csdl2.computer.org/comp/proceedings/re/2002/1465/00/14650311.pdf 52. Joseph a gorgen, charlotte linde: “Techniques for requirements elicitation”.2002. http://www.cs.brown.edu/courses/cs190/current/documents/restricted/goguen.pdf 53. Ann M. Hickey Alan M. Davis: “Requirements Elicitation and Elicitation Technique Selection: A Model for Two Knowledge-Intensive Software Development Processes”.IEEE,pages 152-164,1993. http://csdl2.computer.org/comp/proceedings/hicss/2003/1874/03/187430096a.pdf 54. Michael G. ChristelKyo C. Kang: “Issues in Requirements Elicitation issues”.IEEE, 2003, onpage 10pp-. September 1992, Technical Report, CMU/SEI-92-TR-012ESC-TR-92-012 http://www.sei.cmu.edu/pub/documents/92.reports/pdf/tr12.92.pdf 55. Michael przybilski: “Requirements Elicitation in International Research Projects”. Helsinki Institute for Information Technology (HIIT). http://www.cs.helsinki.fi/u/przybils/papers/amcis2006.pdf

34




56. Belani, H.; Pripuzic, K.; Kobas: “Implementing for web surveys for requirements elicitation”.IEEE,vol 2,pages 465-469,2004. http://ieeexplore.ieee.org/iel5/9871/31386/01458610.pdf?arnumber=1458610 57. Stephen. Bull: "Component Architecture" in the RISKS-Forum Digest: Forum on Risks to the Public in Computers And Related Systems, ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator, (Robinson, RISKS-23.73), 22 Feb 2005 http://catless.ncl.ac.uk/Risks/23.74.html#subj2.10 http://en.wikipedia.org/wiki/Ariane_5_Flight_501 58. Linn Gustafson: “Requirements Engineering Verification validation”, University West, Course slides, Feb-2008 59. Manfred Tscheligi, Peter Fröhlich, Verena Giller: “Draft Guide: First Steps to User Centred Design”.IST support measures IST-1999-29067, version 1.0,2002.

35


A. Appendix

SURVEY QUESTIONNAIRE

Preface ”The main aim of this questionnaire is to find the different views on requirements elicitation practices in the industrial level”. How to fill in the questionnaire: Answer all the questions according to your knowledge, skills and position within your organization. Each question has following multiple-choices

N/A: Not Applicable U: Unknown VL: Very Low L : Low A : Average H : High VH : Very High

General Information Please fill in the following with the relevant information. Name (optional) : E- Mail : Age : Organization : Education : Experience with RE : Date :

36


Survey on Requirements Elicitation Techniques [21-26] Mark each of the Questions with N/A or U or VL or L or A or H or VH. 1. Do you like to carry out feasibility study before starting a new project? 2. Do you like to carry requirements elicitation before going to start a project? 3. Do you like to use questionnaires for requirements elicitation? 4. Do you use prototype to elicit requirements? 5. Do you use scenarios or use cases to elicit requirements? 6. Do you use interviews to elicit requirements? 7. Do you reuse requirements from other existing systems? 8. Do you use the questionnaires for requirements elicitation? 9. Do you conduct the interviews to gather the requirements? 10. Do you conduct the observations while interviews? 11. Tick the methods which are effective for Requirement (your personal opinion, multiple selections allowed. Use ’*’ to indicate your selection)?

a. Interviews ( ) b. Questionnaires ( ) c. Observations ( ) d. Social analysis ( ) e. Prototype ( ) f. Scenario ( ) g. Brain Storming ( ) h. JAD ( ) i. User centered design ( )

12. Tick the popular methods which are used in your companies for requirements elicitation (multiple selections allowed)?

a. Interviews ( ) b. Questionnaires ( ) c. Observations ( ) d. social analysis ( ) e. prototype ( ) f. Scenario ( ) g. Brain Storming ( )

37


h. JAD ( ) i. User centered design ( )

11. How much time do you spend for the requirements engineering in a total project time? 12. Which method you prefer mostly to gather the requirements? Can you give the Rating for usage of the particular method in the industry level?

a. Interviews ( ) b. questionnaire ( ) c. Observations ( ) d. prototypes ( ) e. Scenarios () f. Reuse ( ) g. Brainstorming ( ) h. Jad ( ) i. User centered design ( )

13. Which method will take more time and cost? 14. Do you prefer user centered design to gather the requirements? 15. Can you provide any general information regarding the different methods of requirements? (I mean which method will give the good result depends on the project and the situation).

-------------------------------------------------------------------------------------------------------

-------------------------------------------------------------------------------------------------------.

38

Requirements Engineering: Elicitation Techniques - DiVA

Documents

Transcript of Requirements Engineering: Elicitation Techniques - DiVA