Background of the research domain

Published: Last Edited:

This essay has been submitted by a student. This is not an example of the work written by our professional essay writers.


This chapter of thesis consists on the background of the research domain, problem area and aims and objectives, readers will also find the research questions and research methodologies for the thesis work.

1.1 Background

The basic concern of a software system is to how it meets the requirements for which it was built? In general words requirement engineering is a process of stakeholders' identification and their needs, purpose and consequence of system development. The most critical thing in system development is to find what to build? (Nuseibeh et al, 2000) Many requirements errors are skipped to the later stages of the development life cycle and rectifying these errors during or after the implementation have been found to be exceedingly costly. This is the point where requirement analysts pay more attention, because getting ambiguous idea of user's requirements may lead to wrong thing done which could be impossible to rectify later on.

The success or failure of a system development effort depends heavily on the quality of the requirements (C. Jones, 1996). The quality of the requirements is greatly influenced by techniques employed during requirements elicitation because elicitation is all about learning the needs of users, and communicating those needs to system builders. How do we select an appropriate elicitation technique out of the plethora of available techniques greatly affects the success or failure of requirements elicitation (A. Hicky et al, 2002). The requirement elicitation is a part of the requirement engineering process, usually followed by analysis and specification, integration and validation of the requirements. Requirement elicitation is the most critical phase of software development cycle. The purpose of this process is to identify the system boundaries and specify the functional and behavioral properties of a system. The success of this process bases on identifying the relevant stakeholders (end users, customers, decision-makers or developers) and discovering their needs. The stakeholders are mostly from different background and have different goals, so it is vital to include the entire stakeholders in information gathering otherwise certain viewpoints are never exposed. There are number of difficulties in achieving the requirement elicitation goal and it is important for the analyst to consider all relevant factors to better understand the application domain, system constraints, business needs and stakeholders.

In recent advancement in technology, the web projects have become more popular for business solutions. Many companies want to cover global market, so web systems can be a way to solve their problem. Today world has become a global village; people want to purchase the product at home or avail a service remotely. So, it could only be possible to give some access to your consumer by a web system. When we talk about the web, it means we consider the whole cyberspace. There are several issues in developments of these web projects, e.g. information management, global customer requirements, customer attraction, security, service availability, risk assessment etc. But in this thesis our concern is to discuss the issues regarding the requirements gathering for development of these large systems.

Analysts have different challenges regarding requirement elicitation process that involve in large web projects, only complete and structured requirements make these projects more reliable. The key issue for an analyst is to provide the product that fulfils the need of the end user. Furthermore these projects consume more time and has high development cost, so the failure of these project lead to user dissatisfaction, increase maintenance cost and loss of reputation of project team.

1.2 Purpose

The purpose of this thesis is to find out major problems in requirement elicitation process during development of large web projects. The focus of this thesis is to identify the barriers in requirement elicitation process, requirements elicitation methods and their use.

1.3 Problem domain

Large projects required high resources for development. If the requirements of such projects are unrefined and inconsistent, it may cause full project failure or would not meet the user requirements. So, the problem is how to elicit the user requirements and how to overcome the barriers in communication in requirements gathering? What procedures/ techniques should be used for requirement identification and web content organization?

The process of requirement elicitation is very crucial in project development, because unstructured requirements can easily lead to large amounts of rework when the customer simply cannot accept a system the way it was developed. That's why it is important to get structured and consistent user requirements for successful system development ().

1.4 Aims and Objectives

The research goal is to identify the obstacles in requirement elicitation process in large web projects, map these barriers to the requirement elicitation methods, and apply appropriate method(s) for requirement identification to assist the system builders of web projects. The success or failure of a system development effort depends heavily on the quality of the requirements. The quality of the requirements is greatly influenced by methods employed during requirements elicitation, because elicitation is all about learning the needs of users, and communicating those needs to system builders. How we select an appropriate elicitation method out of the plethora of available methods greatly affects the success or failure of requirements elicitation. More than 50 percent projects fail () due to bad or inconsistent requirement identification, so our research contribution would be a roadmap to consistent requirements gathering to build quality system.

1.5 Research Questions

A research question is a statement that exposes the purpose of studies or research. Below mentioned three questions will cover the boundaries of our thesis.

RQ1: What are the communication obstacles in requirement elicitation and how do you tackle them in large web projects?

Many errors and inconsistencies in projects are due to ineffective communication among the stakeholders and the requirement analysts in the whole process of requirement gathering. These errors can lead to requirement unclear, incomplete, inconsistent and incorrect and take much time to recover them. So our first research question is to find out the communication barriers in requirement elicitation process.

RQ2: Which method or set of methods of the requirement elicitation process are appropriate for large web projects?

There are many elicitation methods for requirement elicitation process. This research question related to method selection for elicitation process in large web projects.

RQ3: How do these methods help the analysts in requirements gathering, evaluation and integration in large web projects?

1.6 Research Methodology

Research can be defined as the study that goes beyond the personal ideas and experiences. To cross these boundaries of personal ideas, researchers follow some methods/techniques for their research. Creswell mentioned two major types of research methods, quantitative and qualitative research methods. (J.W. Creswell, 2002)

Both approaches are scientific way of doing research, but quantitative approach is more statistical, it starts with hypotheses and theories, uses formal instruments, experimentation, component analysis, and reduces data to numerical indices. The quantitative approach has different methods e.g. experiment, while a qualitative approach is systematically collection of data with qualitative methods, it is more about the field research. The qualitative approach has different methods e.g. case study, interviews, survey, ground theory, phenomenology, ethnography and historical data collection. By using one are few methods researchers collect data for their research (J.W. Creswell, 2002).

In literature study, search strategy is very important. We used two well known research databases IEEE Xplore and ACM digital library for our literature study because school provides us an access to material of these search engines. The search was performed with various key points related to domain. We tried to minimize the chance of overlooking literature material with the help of above mentioned search engines. Furthermore manual search of relevant material were also performed in local school library. For general concepts we also used other search engines like Google scholar and Bing etc.

We extracted material from every source (paper, article, book etc.) that we found relevant to our domain by referring to actual author. The way in which we went through the articles was reading the abstract, introduction, conclusion and references and then assessed the relevance of particular material to literature. Several books were also consulted for literature study.

1.7 Research Design

The selected topic is related to the field of requirement engineering. We decided to use qualitative approach. It involves the use of qualitative data, such as literature study and interviews to understand and explain the actual problem. A descriptive procedure will be followed to reach the results, several milestones of our study are shown in figure 1.1.

Start with entrance in problem area and then identify and state the specific problem with the help of literature. Make a plan for study that would be followed to achieve the desired results. After planning actual work will start, data is being gathered from different sources (literature, Interview results) and processing of collected data. The final phase consists on results evaluation and reporting; the achieved results will be analyzed and documented and final contribution in the area will be presented.

1.8 Validity threats

"Validity is the best available approximation to the truth of a given proposition, inference or conclusion" (Trochim, 1999). There are several validity threats that will raise potential issues about the research study.

Internal validity examines whether correct inferences are derived from the gathered data (J.W. Creswell, 2002). The threat to internal validity is reduced to an extent by referring to multiple perspectives on a relevant topic. Furthermore, these perspectives are presented in their original form to the extent possible to further minimize the internal validity threats. Also an effort is made to provide a solid discussion on topics.

External validity addresses generalizing the results to different settings (J.W. Creswell, 2002). Threats to external validity are reduced to some extent by generalizing our study results on different situations in small scale. Threats to external validity at large scale are not handled because of cost and time limitation.

Construct validity which evaluates the use of correct definitions and measures of variables. An effort is made to mitigate the construct validity threats by analyzing the some knowledge of particular domain, collected literature material from research databases (ACM, IEEE, ScienceDirect etc.) and books.

Conclusion validity is the degree to which the relationships reached in the conclusions are reasonable or not. A search criterion was used to reduce the conclusion validity threats. In search criterion, the achieved results were analyzed with authentic results from previous similar research.

1.9 Thesis Structure.

Thesis outline will be given later

Requirements Engineering

2.1 Introduction

The chapter consists of general concepts of requirement engineering and requirement development process. This chapter will also cover the core concepts of requirement engineering and its process with reference to the literature study. This chapter will also help the reader to get deep understanding of thesis domain.

2.2 What is a Requirement?

According to [Ralph 2003] "Requirement is a statement that identifies a capability, characteristic or quality of system in order for it to have value and utility to a customer or user".

Requirement is an important factor for the development of any project and it defines what different stakeholders (users, customer, manager and developer) need and how system will fulfill these needs. They are generally expressed in natural language for the reason that everyone can well understand it. It helps the analyst to better understand which element and function are necessary in the development of particular project. Requirements are used as input in a design, implementation and validation stage of product development. So, a project can be succeed or failed at any time during project life cycle because of poor requirement gathering and managing process. A survey conducted by Standish group in 1995 and 1996 shows that large number of project were failed to satisfy the required stakeholder because of poor requirement. Every software application has a user and the time spent understanding the user need will help to make a successful project. So because of its importance, requirement analyst should develop a plan to determine how requirement will be evolved and addressed in system life cycle.

According to [Brooks]

"The hardest single part of building a software system is deciding precisely what to build. No other part of the conceptual work is as difficult as establishing the detailed technical requirements, including all the interfaces to people, to machines, and to other software systems. No other part of the work so cripples the resulting system if done wrong. No other part is more difficult to rectify later."

2.2.1 Functional requirements

Functional requirements of the system are a statement of services or functionality that system should provide and how the system should in a particular situation. Functional requirements are the interactions between the system and its environment independent from implementation. Sometime functional requirements are also stated as system constraints (Lauesen, 1999). These requirements generally depend on user of the software and type of software and type of system being developed.

2.2.2 Non Functional requirements.

These are the constraints on the services or functions offered by the system such as timing, development process and standards. These requirements define system properties like reliability of the system, response time and storage requirements etc. Process requirements may also be specified mandate a particular system, programming language or development method. Non-functional requirements may be more crucial than functional requirements if these are not met, the system is useless. User visible aspects of the system not directly related to functional behavior. Also known as quality attributes of the system (Lauesen, 1999).

2.2.3 Constraints

These are also known as Pseudo requirements, imposed by the client or the environment in which the system will operate. They can be input/output device capability, system representation in the environment (Lauesen, 1999).

2.3 Requirement Engineering Concept

Requirement Engineering is the branch of software engineering and the earliest phase of the software development life cycle. Zave defined the requirement engineering. (Zave, 1988).

"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 behavior, and to their evolution over time and across software families."

In broad context, the requirement engineering deals with not only technical issues but it also supports the managerial, organizational, economic, and social issues. It is used to design software that meets the goal for which it was intended. By identifying the need of stakeholders , understanding the context in which the developed software will be used, modeling, analyzing, negotiating, and documenting the stakeholders' requirements; validating that the documented requirements match the negotiated requirements; and managing requirements evolution (Betty et al, 2006).

The end users, customer, decision maker and developer are involved in a requirement engineering process as stakeholders. These stakeholders are from different background and have different individual and organizational goals due to the environment in which they work. It is not easy to produce a complete, consistent and well-structured requirement from incomplete, imprecise and conflicting sources. Stakeholder not only means human being but it also refer to the environment in which the system will operate. So the requirement is incomplete without considering the physical and organizational environment in which the system will be used.

Requirement engineering is a difficult process because challenges faced by requirement engineering communities are distinct from those faced by software engineering community as requirement reside in problem space whereas software resides in solution space. Furthermore, the requirement engineering deals with defining those problems that the software has to solve whereas software engineering concerns with defining and refining proposed software solution (Betty et al, 2006).

Requirement engineering process has a great impact on software quality because the most expensive, frequent and dangerous type of software errors are related to poor requirements. These errors affect the cost of software development because the cost to correct these error increases as the time delay in finding them. In view of such difficulties, requirement engineering process should be more disciplined.

2.4 Requirement Engineering Process

The requirement engineering development process consists of feasibility study, requirements elicitation and analysis, requirement specification, requirement integration and validation. The purpose of these activities are to identify the user, customer and stakeholder needs follow by specifying these in a form that is amenable to analysis and validating the documented requirement. Figure2.1 demonstrates requirement engineering development process (G. Kotonya et al, 1998). It starts from the feasibility study of the system. All results of the feasibility study are documented in feasibility report. The next phase of this process is requirement elicitation and analysis (some authors stated this phase into two separate phases as requirement elicitation and requirement analysis). The requirement specification and validation followed by elicitation process. Our major focus in this process will be the requirement elicitation. These activities are described in more detail below based on description and technique found in literature (G. Kotonya et al, 1986).

The purpose of figure is not to give the impression that each process is separated from other but rather present an overview of the whole process.

2.4.1 Feasibility Study

Feasibility study is earliest step before proceeding towards requirement engineering process. Some authors include it in requirement engineering process (B. Hrvoje et al, 2005) but some say it prerequisite for process (G. Kotonya et al, 1998). It is an analysis of the practicality of an idea. It focuses on trying to answer the essential question of "Will the idea work and should you proceed with it?" (D. Hofstrand et al, 2009). All activities of the study are directed toward helping answer this question. Feasibility studies can be used in many ways but primarily focus on proposed business ventures. Farmers and others with a business idea should conduct a feasibility study to determine the viability of their idea before proceeding with the development of a business. Determining early that a business idea will not work saves time, money and heartache later (D. Hofstrand et al, 2009). Feasibility study is done on the basis on the following factors; technology and system feasibility, economic feasibility, legal feasibility, operational feasibility and schedule feasibility.

2.4.2 Requirement Elicitation

Requirement elicitation is the initial (after feasibility study) and the most important activities in the requirement engineering process which can not be separated from the subsequent activities. It is used to explore the requirement of customer, user, decision maker, developer and other stakeholders and to identify the system boundaries and specify the functional and behavioural properties of a system in order to meet the goal for which the intended system is developed (Z. Zhang, 2006). The success or failure of this process is based on identifying the relevant stakeholders and discovering their needs. Stakeholders are mostly from different background and have different goals, so it is vital to include the entire stakeholders in information gathering otherwise certain viewpoints are never exposed. The most common sources for this phase are:

  • Clients
  • Customer requirements specifications
  • Documentation related to pre-existing systems
  • Users of pre-existing systems
  • Users of the new system

There are number of difficulties in achieving the requirement elicitation goal and it is important for the analyst to consider entire relevant factors to better understand the application domain, system constraint, business needs and stakeholders. The common challenge that analyst phase during elicitation process is to ensure effective communication between stakeholders as well as the elicitation of tacit knowledge. The output of this process is a collection of elicitation notes which describe the elicited requirement. Several techniques are used for elicitation process, some example are (Z. Zhang, 2006)

  • Conversational Methods
  • Conversational methods consist on interview, survey and questionnaires to gather data from stakeholders and other sources.

  • Observational Methods
  • This method is used to explore the non-tactic (those requirement that are apparent but difficult to verbalize) requirement from the stakeholder. Social analysis, ethnographic study and protocol analysis are examples for Observational method.

  • Analytical Methods
  • In this methods requirement are gathered by exploring the existing documentation and knowledge. Requirement reuse, Content Analysis, Documentation Studies are common example of Analytical method.

  • Synthetic Methods

This process is a combination of all above methods. Stakeholder and analyst use different way to explore the requirements. Joint Application Development, Scenarios, Passive Storyboards are common examples of Synthetic method.

2.4.3 Requirement Analysis

Requirement analysis is used to analyze and model those requirements that are captured in requirement elicitation process. Requirement elicitation process is an input to requirement analysis and the output of this process is a consistent and complete set of requirements. It is used to detect the inconsistence and missing requirements provided by the stakeholders for the purpose of necessity, consistency, completeness and feasibility. The main goal of the process is to answer the question "have we got the right requirement" [7]. Different techniques are used for requirement analysis but JAD sessions, Prioritization, and Modeling are the most important and common (F. Paetsch et al, 2003).

  • Joint Application Development (JAD)
  • JAD is a process that consists of workshop and group session in which the knowledge worker and IT specialist meets to discuss the desired product feature. This type of discussion is very productive because it resolves any difficulties between two parties while developing new system for a company.

  • Requirements Prioritization
  • Requirement prioritization is used in a situation where most valuable features are delivered as early as possible within tight schedule. Both the customer and developer provide input to this process by mentioning their priority for the system. Technique (K.E. Wiegers, 1988) like Pair-Wise Comparison and Analytical Hierarchy Process are used to access the prioritization of software requirements.

  • Modeling

Modeling is another important technique of requirement analysis that acts as bridge between the analysis and design phase. Techniques (G. Kotonya et al, 1986) like data-flow models, semantic data models and object-oriented approaches are used to describe system requirement.

2.4.4 Requirement Documentation

Once a requirement is elicited, modeled and analyzed it should be documented in clear and unambiguous terms. Requirement analysis is an input to requirement documentation and the output of this process is a well-structured and defined specification. It is used to communicate the requirement between stakeholder and developer. A good requirement document should be correct, complete, consistent and feasible because it is used as a baseline for evaluating subsequent process and products. An unambiguous, concise and clear stated document is also used as a base for validating the stated requirement and resolving stakeholder conflicts. Both the functional and non functional requirements are represented in requirement specification. Set of use cases are used to describe all the interaction that the user have with software. The most common approaches for requirement specification are [7]:

  • Natural language
  • Structured natural language
  • Design description language
  • Requirements specification language
  • Graphical notation
  • Formal specification

2.4.5 Requirement verification and validation

This process is used to clarify that the requirement document are unambiguous, consistent and complete and that the stakeholder are satisfied with the final requirements specification. This process is used to validate that each stage of development process follow processes and standards as well as the process and product meets user needs. It is performed a bit later in the process because it concerned with validating the final draft rather the raw data gather in requirement elicitation process. Requirement documentation, organizational standards, and organizational knowledge are inputs to requirement verification and validation and the output of this process is the finalized requirements specification document agreed and authorized by all stakeholders. The goal of this process is to answer the question 'have we got the requirement right' (D. A. Cook, 2002). Techniques like requirement inspection, requirement checklist and requirement testing are used to find the defect to improve the quality of a requirement as well as to make sure that certain criteria meet regarding information elicited and specified.

2.4.6 Requirement Management

Requirement management is used to identify, organize and track the entire changing requirement in a project as well as impact of these changes. It is continuous process whose goal is to make sure that organization meets the expectation of both the customer and stakeholders (F. Paetsch et al, 2003).

2.5 Importance of Requirement Engineering Process.

Requirement engineering process gives much about the project development. It indicates several things; first, it highlights the importance of goals that motivate the development of a software system. Second, it refers to "precise specifications". These provide the basis for analyzing requirements, validating that they are indeed what stakeholders want, defining what designers have to build, and verifying that they have done so correctly upon delivery. Finally, the definition refers to specifications' "evolution over time and across software families", emphasizing the reality of a changing world and the need to reuse partial specifications, as engineers often do in other branches of engineering.(B. Nuseibeh et al, 2000)

2.6 Summary

The concept and overview of requirement engineering process was given in start of this chapter. Then each step of requirement development process was briefly discussed. Further we discussed the requirement engineering process model in detailed and at the end we highlighted the importance of requirement engineering process. The following chapter will carry out the web projects, importance of implication of engineering concepts in web development and problems in elicitation process and elicitation methods.


  1. P. Zave, Classification of Research Efforts in Requirements Engineering, ACM Computing Surveys (CSUR), v.28 n.4, 1988, p.315-321.
  2. H. Betty, C. Cheng , M. J. Atlee, Research Directions in Requirements Engineering, Future of Software Engineering, May 2006, p.275-303.
  3. Z. Zhang, Effective Requirements Development - A Comparison of Requirements Elicitation Techniques, INSPIRE , Tampere, Finland, 2006
  4. F. Paetsch, A. Eberlein, F. Maurer, Requirements Engineering and Agile Software Development, "Proceedings of the 12th IEEE International Workshop on Enabling Technologies: Infrastructure for Collaborative Enterprises", Linz, Austria, June 2003, p. 307-313.
  5. K.E. Wiegers, Software Requirements, Microsoft Press, 1988
  6. G. Kotonya, I. Sommerville, Requirements Engineering: Processes and Techniques, John Wiley & Sons, 1986.
  7. last checked 2009-10-28
  8. D. A. Cook, Verification & Validation of Requirements, Software Technology Support Center (STSC), 2002.
  9. G. Kotonya, I. Sommerville, Requirements Engineering: Processes and Techniques. John Wiley & Sons, 1998.
  10. B. Nuseibeh , S. Easterbrook, Requirements Engineering: A Roadmap, Proceedings of the Conference on The Future of Software Engineering, 2000, p.35-46
  11. C. Jones, Patterns of Software Failure and Success, Thomson Publications, 1996.
  12. A. Hickey, A. Davis, The Role of Requirements Elicitation Techniques in Achieving Software Quality, Requirements Eng. Workshop: Foundations for Software Quality (REFSQ), 2002.
  13. J. W. Creswell, Research Design. Qualitative, Quantitative and Mixed Method Approaches, 2nd Edition, Sage Publications, 2002.
  14. S. Lauesen, Software Requirements - Styles and Techniques, Samfundslitteratur, Denmark, 1999, p. 217-360.
  15. B. Hrvoje, P. Krešimir, K. Katarina, "Implementing Web-survey for software requirements elicitation", Proceedings of the 8th International Conference on Telecommunications ConTEL, 2005, p. 465-469.
  16. D. Hofstrand, M. Holz-Clause, Ag Decision Maker: What is a feasibility study? , 2009.