Requirements Engineering in Software Houses of Pakistan

Published Online September 2014 in MECS

• I.    Introduction

  Main qualities for software are it should be on time, reliable and within budget. Requirement engineering counts very much for the success of a software product. It has been seen that if not taken seriously, requirements errors are going to be much worse in future. One study indicates that poor requirement gathering in the project is cause for more than 50 % of all errors in future [1]. Quotation by Barry Boehm discusses the cost of maintenance phase, which is $4000 per line against $30 of development cost [2]. Missing important requirements or capturing irrelevant requirements are main causes for product failure [3]. Failures during the RE process have a significant negative impact on the overall development process [4]. If the requirements errors are detected late in the development process, e.g. during maintenance, their correction can cost up to 200 times as much as correcting them during the early stages of the development process [5].

It has been proven that a large proportion of the issues in software development can be related back to requirements engineering (RE) [6]. Requirement Engineering is the process of identifying the purpose of the software by identifying stakeholders and tends to their needs, and documenting these in a form that is agreeable for the scrutiny, communication between stakeholders and for future execution of product [7]. User experience design counts very much for effective requirement engineering [8]. Requirement engineering in extreme programming environment is analyzed in [9]. Situational factors affecting the Requirement Engineering process during Global Software Development is discussed in [10]. We live in a global village and business is also experiencing globalization. Collaboration of activities for different phases of software development life cycle such as requirement engineering is very critical. Issues regarding requirement engineering are discussed in [11]. Effective requirement engineering determines the difference between a winning product and mere set of features [12].

From the above, it can be seen that missing, poor and changing requirements, have all been shown to have a negative impact on project success. It can be argued, therefore that good requirements engineering practices that minimize or manage these issues will have a positive influence on project success.

This paper comprises of different sections like introduction, then there is a brief introduction of requirement gathering, after words there is a literature review and survey results. In the end there are concluding remarks, future research opportunities and an acknowledgement is given.

• II.    Requirement gathering

The most important step in software development [14] is the collection of a set of instructions for the specification of what is needed by a customer to meet its requirements. This is generally accomplished by interviews and participatory design, which involves face to face communication, where this is not possible, there is relying on questionnaires [15].

• A.    Interpret business requirements and produce system requirements.

• B.    Bringing on the functional requirements

If the requirements are incorrect, inaccurately or incompletely specified there is little chance the answer will be what is needed. Requirements are the basis on which potential solutions are evaluated, identify what is needed. They are not the solution rather they provide a definition of what the solution needs to address.

• III.    Related Work

South Asia is going to be heaven for outsourcing, but there are not very much published studies’ regarding software development constructs [16]. In New Zealand a thorough survey resulted in four studies relating to software development practice in New Zealand, out of these only two was about requirement engineering.

In these studies there was a use of questionnaires and telephone interviews, it was sent to 65 companies and interview was also conducted with senior members of each company [17, 18].

Other studies in New Zealand covered software development process generally, in these there was a focus on the use of CASE tools, which results in support of day to day activities in the development process [19, 20].

In Australia also questionnaire was used to target 16 companies, the study focused on effort required for requirement engineering activities in projects and this study also showed a difference in effort for different kinds of project e.g. external projects and in house development [21].

In European countries, these studies focused on SMEs (small and medium enterprises). There are 3 studies which show this. In Europe SMEs have employees less than 250 and small companies have less than 10 employees. On Germany study targeted 10 companies, it focused on aspects like maturity level of software engineering, strategic issues like quality and process improvement and cooperation with external contractors, companies also found that most of their issues are of modelling, requirement document and inspections [22].

Another study [23, 24] targeted 4 companies 2 in Ireland and 2 in Sweden. The findings of this showed the belief that “small companies are less likely to have mature requirement engineering practices” is not right, risk management is less prioritized process and requirement management is least satisfactory process.

A third study targeted 12 Finnish companies. Three of them had less than 10, five have in the range of 11- 50 and four over 150 employees [25]. Survey findings were related to technology transfer in requirement engineering, automation of requirements engineering practices, development and improvement in requirement engineering practices.

One study by web based survey in China emphasizes on how elicitation and representation of requirement is done by RE persons [26]. Negligence of risk factors and conflict management in 27 Malaysian firms is shown in [27].

Point of note is that all these studies used questionnaires or interviews or mixture of these. There is much variation in adoption of requirements engineering practices; this depends on the type of project, number of employees and size of project.

Most of proposed requirements engineering techniques work only in large enterprises; these techniques appear to be ineffective for very small firms which comprised of 3.6 developers. On study in Chile tries to identify current practices and challenges to adopt appropriate requirement engineering practices in small firms [28].

According to (Pakistan Software Export Board, PSEB, 2006) IT industry is about 700 million US dollars with annual turnover of 70-80 million US dollars. Software industry in Pakistan is not performing up to its full potential. Pakistan economy is 1/5 of Indian economy, Indian industry is of 26 billion Us dollars from domestic participation of 8.2 billion US dollars and international of 17.9 billion US dollars, all these figures show that the software industry of Pakistan is not in pace with competitive countries [29].

Indian software export revenue is 218% with 17% of Pakistan export revenue; this figure signifies enormous space to increase software export revenue [30]. According to Pakistan Software Export Board (PSEB), the local software industry lags behind in characteristics like quality, low project cost, poor requirement gathering and infrastructure issues. Software houses in Pakistan are unable to attract national and international customers, there is much need to improve in quality to open their way to an international marketplace. According to (PSEB, 2008) there are 495 software houses, in Karachi, 459 in Lahore, 373 in Islamabad and 92 in other cities [31]. Percentage of software houses with ISO certification is 8 % and only 1% of software houses are CMM certified and 91 % are working without any standards [32].

Small and medium size firms of Pakistan were also assessed in context of requirement engineering practices, potential limitation in practicing and solutions in these situations were also proposed [33]. South Asia is going to be heaven for outsourcing, but there are not very much published studies’ regarding software development constructs [16]. In New Zealand a thorough survey resulted in four studies relating to software development practice in New Zealand, out of these only two was about requirement engineering.

In these studies there was a use of questionnaires and telephone interviews, it was sent to 65 companies and interview was also conducted with senior members of each company [17, 18].

Other studies in New Zealand covered software development process generally, in these there was a focus on the use of CASE tools, which results in support of day to day activities in the development process [19, 20].

In Australia also questionnaire was used to target 16 companies, the study focused on effort required for requirement engineering activities in projects and this study also showed a difference in effort for different kinds of project e.g. external projects and in house development [21].

In European countries, these studies focused on SMEs (small and medium enterprises). There are 3 studies which show this. In Europe SMEs have employees less than 250 and small companies have less than 10 employees. On Germany study targeted 10 companies, it focused on aspects like maturity level of software engineering, strategic issues like quality and process improvement and cooperation with external contractors, companies also found that most of their issues are of modelling, requirement document and inspections [22].

Another study [23, 24] targeted 4 companies 2 in Ireland and 2 in Sweden. The findings of this showed the belief that “small companies are less likely to have mature requirement engineering practices” is not right, risk management is less prioritized process and requirement management is least satisfactory process.

A third study targeted 12 Finnish companies. Three of them had less than 10, five have in the range of 11-50 and four over 150 employees [25]. Survey findings were related to technology transfer in requirement engineering, automation of requirements engineering practices, development and improvement in requirement engineering practices.

One study by web based survey in China emphasizes on how elicitation and representation of requirement is done by RE persons [26]. Negligence of risk factors and conflict management in 27 Malaysian firms is shown in [27].

Point of note is that all these studies used questionnaires or interviews or mixture of these. There is much variation in adoption of requirements engineering practices; this depends on the type of project, number of employees and size of project.

Most of proposed requirements engineering techniques work only in large enterprises; these techniques appear to be ineffective for very small firms which comprised of 3.6 developers. On study in Chile tries to identify current practices and challenges to adopt appropriate requirement engineering practices in small firms [28].

According to (Pakistan Software Export Board, PSEB, 2006) IT industry is about 700 million US dollars with annual turnover of 70-80 million US dollars. Software industry in Pakistan is not performing up to its full potential. Pakistan economy is 1/5 of Indian economy, Indian industry is of 26 billion Us dollars from domestic participation of 8.2 billion US dollars and international of 17.9 billion US dollars, all these figures show that the software industry of Pakistan is not in pace with competitive countries [29].

Indian software export revenue is 218% with 17% of Pakistan export revenue; this figure signifies enormous space to increase software export revenue [30]. According to Pakistan Software Export Board (PSEB), the local software industry lags behind in characteristics like quality, low project cost, poor requirement gathering and infrastructure issues. Software houses in Pakistan are unable to attract national and international customers, there is much need to improve in quality to open their way to an international marketplace. According to (PSEB, 2008) there are 495 software houses, in Karachi, 459 in Lahore, 373 in Islamabad and 92 in other cities [31]. Percentage of software houses with ISO certification is 8 % and only 1% of software houses are CMM certified and 91 % are working without any standards [32].

Small and medium size firms of Pakistan were also assessed in context of requirement engineering practices, potential limitation in practicing and solutions in these situations were also proposed [33].

• IV.    Questionnaires

A questionnaire is a way to gather information about a problem in the question [34]. It is a list of questions and space for answers about a problem for which one is interested to find a solution [34]. Respondents of the questionnaire should be kept informed about the outcomes of the survey [35]. When a respondent answers a question, there is a feel of face to face communication with another person.

Questionnaires are usually employed:

• A.    To collect factual data in order to classify people and their circumstances

• B.    To gather straightforward information relating to people’s behaviour

• C.    Interest of people about particular interest.

Questionnaires should not be used

• A. Investigation of complex topics in greater details B. Investigation of controversial subjects.

• C. As an ‘easy’ option which will require little time or effort (a common misunderstanding)

• V. Survey results

In this survey we decided to use the questionnaire to target as much organization as possible. The survey was limited to 20 questions with motive was to attain higher results. The questionnaire was sent to 36 software companies, out of which 17 replies were received. It was sent to one of the staff members of companies known to us. None of the companies answered a hundred percent. Some questions received maximum answers while some minimum. Below answers of each question in the survey are presented.

• A.    What is Your Job Title?

This question employed variation in its response. Only 4 respondents appeared to be from a managerial background with variation in titles like Team Lead, Solution Architect, Project Manager and CEO, etc. Only one title of the Solution Architect appears to be involved in Requirement Engineering. Rest of respondents was from a development background. All these phenomena are implicit because those respondents which identified themselves from managerial background, in reality they may be from development.

• B.    CMM Level of An Organization

This question also employed variations in its answer. 9 of the organizations have no knowledge of their CMM level. This indicates implicitly that they are at level 1. Only 2 of the target organization identified themselves on level 5. Another 2 were from level 2 and 3. One explicitly mentioned it on level 1, 58% of the organizations is at level 1. This factor is very important in the survey because it shows the following software engineering processes followed in Software development companies.

Table 1. CMM LEVEL OF ORGANIZATIONS

No of Organizations	CMM Level
10	No Knowledge about their CMM level, (Level 1)
2	2
2	3
	4
2	5

• C.    No of Employees.

In response to this question only 17% of target organizations have 4 to 10 employees. The next range involves organizations with less than 100 employees. 23% of organizations qualify for this range. The next range involves less than 500 employees, in this range 5% has 300 employees, and 11 % have 400 employees. Rest figures are above 500 and only 3 organizations fall in this category with one having 550, the other having more than 1000 and last having 3000 employees.

Table 2. No of Employees

Number of Organizations	Number of Employees
3	<10
4	<100
1	<300
2	<400
3	>500
1	>1000
1	=3000

• D.    No of Employees dedicated for Requirement Engineering.

This question relates very much to the last question. This is very interesting reality that 100% of the organizations have some staff dedicated to the tasks of requirement engineering. Variation lies in the percentage of staff dedicated to this. One organization has only 0.36% of staff for requirement engineering. 35% of organizations have 10% to 12% of their total employees dedicated to requirement engineering. One organization has 25, the other has 50% and one has 20% of their staff for requirement engineering.

Table 3. Dedicated employees for Requirement Engineering

No of Organizations	Percentage of Staff
1	36
6	10-12
1	25
1	50
1	20

• E.    No of Employees engaged for short term in Requirement Engineering.

In response to this question, 10 organizations engage less than 50% of their employees dedicated to requirement engineering for short term in requirement engineering. All the above establishments have less than 100 employees, with the exception of 2 having 300 and 400 employees. Shocking reality observed in this survey that organization with above 1000 employees engage 500 times more employees, even in the short term for requirement engineering.

• F.    Is There a Use Of automated Tools for Requirement Engineering?

The results of this question have an astonishing reality that 3 out of 17 respondent organizations use automated tools for requirement engineering with one using Microsoft Project, Rational Rose, other using client message board and the last one using Microsoft Visio and Visual Studio. The rest of the organizations have no idea of using automated tools for this important activity in software development.

Table 4. Automated tools used by organizations

No of Organization	Name of Tool
1	Microsoft Project, Rational Rose
1	Client message board
1	Microsoft Visio  and Visual Studio

• G.    Training of Automated Tools

This question in a survey got a very unique answer with only 1 of organization using Microsoft Visio and Visual Studio provides training of only 1 week to its employees. The rest of the organizations have no idea of training of automated tools.

H. Primary Activity for Requirement Engineering

Each of the respondent organizations employs different activity for requirement engineering. 1 organization employs mock-ups, other 1 uses interviews using echo technique, other 1 of organizations in web projects creates a prototype of website to show to the client that he needs actually, other 1 uses communication with the company representative, other 1 incorporates meeting with the customer for requirement gathering, other 1 communicates design of the project by interaction with client, other 1 uses the requirement document sent by customer and discussion of work flow on software on Skype or any instant messenger, other 1 generates Software Requirement Specification by client interaction, other 1 submits proposal, generates Inception report, conducts site visits and uses questionnaire to elicit requirements and staff of other 1 does brainstorming, make use cases and uses reusable components of old projects. Rest of companies didn’t answer for this.

• I.    Are Use Cases being used?

• 10 of respondents showed that they use Uses Cases in order to elicit requirements from the customers. 1 uses Use Cases only in large projects which involve large user interaction, other 1 uses Use Cases for design and documentation purposes. Remaining (4) doesn’t use this important activity of requirement engineering.

J. Are Data Flow Diagrams being used?

One organization in Web Projects uses Website Wire Frames, other 1 uses this important activity in only large projects. 78% of respondent organizations use this important activity to show the processing of data by different inputs and outputs of the future system. Remaining 2 don’t use this important activity.

K. Are Class Diagrams being used?

Static diagram to show participating classes with their properties, methods and mutual relationship among objects.

This survey shows that 1 organizations use class diagrams for only large projects. 8 respondent organizations use class diagrams as their normal routine in requirement engineering. The remaining 9 of the organizations doesn’t use class diagrams in requirement engineering.

L. Type of Project frequently done by Your Organization.

This question got a 100% response. Only 2 organizations specialize in Mobile applications like mobile games. 1 only specializes in Desktop projects. 4 specialize only in Web projects. 8 organizations specialize in the multiple types of platforms like Desktop; Web and Mobile platforms with one out of them specialize additionally in Enterprise Web and Enterprise Data Warehousing.

M. Type of Project Following Intense Requirement Engineering Practices.

Referring to the answer of the above question, organizations specializing in Mobile Applications follow intense requirement engineering practices in Mobile platform projects. Same is the case for Web Projects, additionally one organization specializing in multiple type also conduct intense requirement engineering practices for Web projects. One reply states that it depends upon the nature of the product not the type of product. For rest of organization this is done for Desktop applications.

N. Type of Project Following Normal Requirement Engineering Practices.

This question also relates very much to a last one. An organization which is specialized for Enterprise Applications follows normal requirements engineering practices in Data Warehousing Applications. Same is for Desktop technologies, Web and Mobile platform. One from the organization specializes in multiple platforms does the same for ERP, other for very large projects, others follow these practices in short mobile applications and in projects which has fixed deadlines. One organization sometimes follows normal requirements engineering practices in Web projects.

O. Type of Project Do Not Follow Requirement Engineering Practices.

This question also got a varying response. 5 respondents replied that they don’t do any kind of project in which they don’t do requirement engineering. 1 organization specializing in Desktop projects answered this question with Web projects, 1 replied with Training projects in which they don’t follow requirement engineering. 1 replied with the answer of the small business’s introductory site, 1 mentioned simple mobile applications, 1 mentioned project with the time frame of less than 2 days. 3 didn’t answer this question.

P. The success ratio of Projects Following Intense Requirement Engineering Practices.

8 respondents of this survey indicated the ratio of above 90% success ratio of projects following intense requirement engineering practices. 3 indicated this ratio above 80%. Only 1 mentioned this ratio as 70%. 5 of respondents didn’t answer this question seems they are not aware of this.

Q. The success ratio of Projects Following Normal Requirement Engineering Practices.

In response of this question one replied only with the words of average, the percentage of other respondents is above 50 and less than 80%. One exception is that percentage of this question match with the percentage of the last question. 4 of the organizations didn’t answer to this question.

R. The success ratio of Project Don’t Follow Requirement Engineering Practices At All.

When discussing the percentage for this question every respondent replied with 0% to less than 50%, one mentions with the only exception of 60% from above organization. Only one mentioned that we don’t get anything without requirement engineering. 4 of the organizations didn’t answer to this question.

S. Median Length of Projects.

This question also got a varying response. 8 Organizations have employees less than 60 mostly involved in the projects of duration which ranges from days to weeks to less than 6 months with one takes 6 months to 2 years. The astonishing fact is that these organizations’ main focus is on Web projects. One organization with more than 1000 employees, 30

employees works at a time on a specific project to complete in 3 to 5 months. One with 300 employees takes time about 1 week to 7 years.

T. Significance of Using Requirement Engineering Practices in Organization.

Respondents in the survey answered this by the bunch of statements, i.e. which are that without requirement engineering they wouldn’t be able to complete a single project, considering this as a backbone in a company’s working model, other specified, it of immense importance in Government projects, another one specified it for timely deliverables and quality assurance that leads to achieve business goals. Answer from another organization names requirement engineering for clearance of software requirements, manageable projects, job divisions, results within the anticipated time frame, one praises requirement engineering for helping in bringing at a point to reach an agreement between customer and organization. One organization names it as a must process which must be done with it, other terms, it's a symbol of success for success in projects. One mentions it as the most important part in software development life cycle, absent requirements; they wouldn’t be able to find an exhaust system. One mentions it with the words of highly significant. One specifies that Requirement engineering process helps a lot in avoiding surprises to stakeholders and, indeed, it has a big impact on the success of projects in every organization wherever this methodology is being applied. Specifically talking about this organization, most of the projects have been successfully completed and deployed in client environment by following requirements engineering practices. 4 of the organizations didn’t answer for this.

• VI. Conclusion and Future Work

The main objective of the above research is to show how much of requirement engineering principles are being followed in the software industry of Pakistan. Thing of note is that most of the standards of requirement engineering are not pursued in small and medium size companies. Processes are immature and need enhancements. There is not much use of automated tools for activities relating to overall software development. There is no concept of training of employees, even in large software houses. It is generally an adhoc approach employed in every activity of software engineering specially requirement engineering. Above is response from only 17 organizations, in future this will be extended to more than 50 organizations.

Acknowledgment

The authors are most grateful to a CEO’s, project directors and staff involved in requirement engineering for their precious time and information contributed by them to carry out this research.