THE ROLE OF NATURAL LANGUAGE IN REQUIREMENT GATHERING

Click here to Get this Complete Project Chapter 1-5

CHAPTER ONE

INTRODUCTION

1.1   Background to the Study

The history of natural language in relation to the requirement gathering is laden with many unrealistic ideas and hypotheses. Given the attention-demanding and luxurious nature of the current approaches to requirement gathering, the prospect of a support system that would automatically understand a user’s needs is naturally attractive. A lot of research projects have proposed to obtain and confirm system requirements knowledge by means of a natural or “near natural” conversation with the prospective client (Berry, Kamsties, Kay and Krieger, 2001).

Natural language can be defined in contrast to artificial or constructed languages (such as computer programming languages and international auxiliary languages) and to other communication systems in nature. An unstandardized language such as African American Vernacular English, for example, is a natural language, whereas a standardized language such as Standard American English is, in part, prescribed.

Controlled natural languages are sub-sets of natural languages whose grammars and dictionaries have been restricted in order to reduce or eliminate both ambiguity and complexity (for instance, by cutting down on rarely used excellent or adverbial forms or irregular verbs). The purpose behind the development and implementation of a controlled natural language typically is to aid non-native speakers of a natural language in comprehending it, or to ease computer processing of a natural language. An example of a widely used controlled natural language is simplified English, which was originally developed for aerospace industry maintenance manuals  (Fernandes, 2008). 

The process of interaction between natural language and requirement gathering is an information rigorous activity and will involve the use of both spoken and written language. At its simplest a transcript (possibly verbatim) of an interview is converted into a written text and this text is then subjected to stepwise refinement, again possibly through further dialogue. The specification will eventually be written in a ordinary language assisted by some formal or semi-formal artificial language.

Requirement gathering is concerned with the recognition of the goals to be achieved by the envisioned system, the operationalisation of such goals into services and constraints, and the task of responsibilities for the resulting requirements to agents such as humans, devices, and software. The processes involved in requirements gathering include domain analysis, elicitation, specification, evaluation, negotiation, documentation, and evolution. Getting good quality requirements is difficult and critical. Recent surveys have confirmed the growing recognition of requirements gathering as an area of utmost importance in engineering research and practice.

A software requirement can be said to be a condition or capability to which the system must conform, i.e. as a software capacity needed by the user to solve a problem or achieve an objective. It must be possessed by the system component to satisfy a contract, specification, standard, or other formally imposed documentation. Requirements may take different forms, including scenarios, unstructured text, structured text, or a combination, and they could be stated at dissimilar levels of granularity. At the highest level of granularity, features define the services that the system must provide to resolve the customer’s problem. These are captured as structured or unstructured text in the project vision. At the next stage of granularity, use cases to define the functionality that the system must provide to deliver the required features. Use cases describe the progression of actions performed by the system to yield an observable result of value.

Object-Oriented Technology (OOT) has become a trendy approach for building software systems. Many object oriented methods have been proposed and in these methods, Object-Oriented Analysis process is considered one of the most critical and hard task. It is critical because subsequent levels rely on Object Analysis and it is difficult because most of the input to this process is in the form of natural language English which is innately ambiguous.

During the analysis phase of software development, requirements analyst engaged clients in an interview about system process, assemble data and write a description in English of the system in progress. A graphical Computer Aided Software Engineering (CASE) tool is typically used to document the outcome of the analysis. Such a tool helps developers assess if the software requirements Specification (SRS) may contains any variation or incompleteness that might negatively impact subsequent object modeling which is one of the most crucial and difficult tasks in software engineering.

The Artificial Intelligence (AI) sub-field of Natural Language Processing (NLP) suggest approaches which may aid the effectiveness of software engineers in the analysis of software development (Harmain and Gaizauskas, 2000). Many researchers have begun to see possible benefits from adding natural language processing (NLP) capabilities to CASE tools. The objective is to generate an NLP module that helps automatically identify classes, attributes, methods and relationships implied in the software requirement specification (NZCSRSC, 2008).

The decision to express requirements in documents deserves some thought. On the one hand, writing is a widely accepted form of communication and, for most people, a normal thing to do. On the other side, the main aim of the project is to create a system, not documents. Common sense and experience teach that the decision is not whether but how to document requirements. Document templates offer a consistent format for requirements management. For example, the system Rational Requisite Pro offers these templates and the additional attribute of linking requirements within a document to a database including all project requirements. This unique feature allows requirements to be documented naturally, making them more easy to get and manageable in a database.

1.2       Statement of Problem

Diverse problems can arise when requirements are written in natural language sentences, in a text document:

Lack of clarity: It is sometimes difficult to use language in a precise and unmistakable way without making the document wordy and difficult to read.

Requirements confusion: Functional requirements, non-functional requirements, system main target and design information may not be adequately distinguished.

Requirements amalgamation: Several different requirements may be expressed together as a sole requirement.

Natural language is frequently used to write system requirements specifications as well as user requirements. On the other hand, because system requirements are more detailed than user requirements, natural language specifications can be puzzling and hard to comprehend.

Natural language understanding relies on the specification readers and writers using the same words for the same concept. This leads to mix-up because of the ambiguity of natural language. Jackson (1995) gives a good example of this when he discusses signs displayed by an escalator. These said ‘Shoes must be worn’ and ‘Dogs must be carried’.

A natural language requirements specification is over flexible. It can be said in completely different ways. It is up to the reader to find out when requirements are similar and when they are distinct.

There is no easy way to modularise natural language requirements. It may be difficult to find similar requirements. To discover the consequence of a change, you may take into consideration every requirement rather than at just a group of related requirements.

Because of these issues, requirements specifications documented in natural language are prone to misunderstandings. These are often not known until later phases of the software process and may then be very difficult to resolve.

Automated detection of requirements errors has been a much tougher issue to resolve. Most requirements documents are still written in natural language, and often, it’s the inbuilt ambiguities of natural language that cause requirements errors. Finding ways to examine natural language text and identify possible sources of requirements errors has been a problem to solve.

1.3       Purpose of the Study

The purpose of the study is to examine effect the role of natural language in requirement gathering. Basically the study will look into:

1. The effect of natural language processing on requirement gathering
2. The effect of British requirement gathering on Germans culture and natural languages.
3. The effect of British requirement gathering on Nigerians culture and natural languages.
4. The major problems of natural language in requirement gathering.

1.4       Research Questions

The study is guided by the following research questions:

1. How effective is natural language processing on requirement gathering?
2. To what extent will British requirement gathering influence Germans culture and natural languages?
3. To what extent will British requirement gathering affect Nigerians culture and natural languages.
4. What are the major problems of natural language in requirement gathering?

1.5       Research Hypothesis

The following hypothesis was developed for the study:

H_o:       There is no significant relationship between natural language processing and requirement gathering.

H_1:       There is significant relationship between natural language processing and requirement gathering.

1.7       Scope of the Study

The study examines the role of natural language in requirement gathering. The scope of the study covers three selected countries, namely, Nigeria, Germany and United Kingdom.

1.8       Operational Definition of terms

 Natural Language: Natural language can broadly be defined in contrast to artificial or constructed languages (such as computer programming languages and international auxiliary languages) and to other communication systems in nature.

Requirement gathering: Requirement gathering is concerned with the identification of the goals to be achieved by the envisioned system, the operationalization of such goals into services and constraints, and the assignment of responsibilities for the resulting requirements to agents such as humans, devices, and software.

Natural language processing: Natural language processing is a field of computer science, artificial intelligence, and computational linguistics concerned with the interactions between computers and human (natural) languages.

System Requirement: A system requirements is often accompanied by system compatibility.

 Get the Complete Project

This is a premium project material and the complete research project plus questionnaires and references can be gotten at an affordable rate of N3,000 for Nigerian clients and $15 for International clients.

Click here to Get this Complete Project Chapter 1-5