Requirements Engineering And Reality In Pakistan

Published Date: 02 Nov 2017

Abstract—Requirement engineering is a heart of software development life cycle. More time we spend on requirement engineering, higher the probability of success. This paper presents the adaptation of requirement engineering practices in small and medium size companies of Pakistan. Study is conducted by questionnaires to show how much of requirement engineering models and practices are followed in Pakistan.

Keywords— Requirement engineering, Pakistan, models, practices, organizations.

Introduction

Main qualities for software are it should be on time, reliable and within budget. Requirement engineering counts very much for the success of 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 40-60% of all defects found in software projects can be traced back to poor requirements [1]. Boehm (1975) quotes a pathological case where the development cost of an avionics system was $30 per line of code but the maintenance cost was $4000 per instruction [2]. Missing important requirements or capturing irrelevant requirements are main causes for product failure [3]. Each year, many cases are registered for not fulfilling the appropriate requirements. Failures during the RE process have a significant negative impact on the overall development process [4]. If the requirements errors are discovered 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 shown that a large proportion of the issues in software development can be related back to requirements engineering (RE) [6]. RE "is the process of discovering the purpose [of the software], by identifying stakeholders and tend to their needs, and documenting these in a form that is agreeable for the scrutiny, communication between stakeholders and future execution of product" [7].

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 minimise or manage these issues should have a positive influence on project success.

Now to know what is consider as good practice in requirement engineering, we see that Davis & Zowghi [6] define a good requirements practice as "a requirements practice that either reduces the cost of the development project or increases the quality of the resulting product when used in specific situations".

requirement gathering

The collection of a set of statements which define what needs to be provided by a solution to meet the expectations of the sponsor, stakeholders and users. The collection of requirements is obtained by interviews, RAP sessions and/or workshops. A requirement gathering is used in

Producing the business requirements

Producing the functional requirements

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

questionnaires

A questionnaire is simply a ‘tool’ for collecting and recording information about a particular issue of interest. It is mainly made up of a list of questions, but should also include clear instructions and space for answers or administrative details [8]. Questionnaires should always have a definite purpose that is related to the objectives of the research, and it needs to be clear from the outset how the findings will be used. Respondents also need to be made aware of the purpose of the research wherever possible, and should be told how and when they will receive feedback on the findings [9].

Questionnaires are commonly used:

To collect factual information in order to classify people and their circumstances

To gather straightforward information relating to people’s behaviour

To look at the basic attitudes/opinions of a group of people relating to a particular issue

To measure the satisfaction of customers with a product or service

Questionnaires should not be used

To explore complex issues in great depth

To explore new, difficult or potentially controversial issues

As an ‘easy’ option which will require little time or effort (a common error)

implementation

When we look at the previous surveys conducted in foreign countries most of these were conducted by the means of questionnaires, interviews or the combination of both. One study in Australia employed observation [11] and other relied upon focus groups [10].

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

What is Your Job Title?

This question employed variation in its answer. Only 23% (4) of respondents appeared to be from managerial background with variation in titles like Team Lead, Solution Architect, Project Manager and CEO etc. Only one title of Solution Architect appears to be involved in Requirement Engineering. Rest of respondents were from development background. All this phenomena is implicit because those respondents which identified themselves from managerial background, in reality they may be from development.

CMM Level of An Organization

This question also employed variation in its answer. 52% (9) of the organizations have no knowledge of their CMM level. This indicates implicitly that they are on level 1. Only 11% (2) of the target organization identified themselves on level 5. Only 11% (2) of were from level 2 and 3. One explicitly mentioned itself on level 1, by sum of above numbers 58% of the organizations are level 1. This factor is very important in the survey because it shows following of standards followed in Software development.

No of Employees.

In response to this question only 17% of target organizations have 4 to 10 employees. Next range involves organizations with less than 100 employees. 23% of organizations qualify for this range. 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, other having more than 1000 and last having 3000 employees.

No of Employees dedicated for Requirement Engineering.

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

No of Employees engaged for short term in Requirement Engineering.

In response of this question, 58% (10) of organizations engage less than 50% of their employees dedicated for requirement engineering for short term in requirement engineering. All the above organizations 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 in important part of requirement engineering.

Is There A Use Of automated Tools for Requirement Engineering.

The answers of this questions has astonishing reality that (17%) 3 out of 17 respondent organizations use automated tools for requirement engineering with on using Microsoft Project, Rational Rose, other using client message board and the last one using Microsoft Visio and Visual Studio. Rest of the organizations have no using automated tools for this important activity in software development.

Training of Automated Tools

This question in a survey got a very unique answer with only 5% (1) of organization using Microsoft Visio and Visual Studio provides training of only 1 week. Rest of the organizations have no idea of training of automated tools.

Primary Activity for Requirement Engineering

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

Is Use Cases Are Used?

One of important activities in Requirement Engineering. % (10) of respondents showed that they use Uses Cases in order to elicit requirements from the customers. 5% (1) uses Use Cases only in large projects which involve large user interaction; other 5% (1) uses Use Cases for design and documentation purposes. Remaining 28 % (4) don’t use this important activity of requirement engineering.

Is Use Data Flow Diagrams Are Used?

Very important construct in Requirement Engineering showing inputs and outputs of a data to analyse a system.

5%(1) of respondent organizations in Web Projects uses Website Wire Frames, other 5% (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 future system. Remaining 11 % (2) don’t use this important activity.

Is Class Diagrams Are Used?

Kind of static diagrams using participating classes their attributes, methods and mutual relationship between classes.

This survey shows that 5% (1) of organizations use class diagrams for only large projects. 47% (8) of the respondent organizations use class diagrams as their normal routine for requirement engineering. Remaining 52% (9) of the organizations don’t use class diagrams in requirement engineering.

Type of Project frequently done by Your Organization.

This question also got a 100% response from the respondents. Only 11% (2) of organizations specialize in Mobile applications like mobile games. 5% (1) only specialize in Desktop projects. 23% (4) specialize only in Web projects. 47% (8) of 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.

Type of Project Following Intense Requirement Engineering Practices.

Referring to the answer of above question, organizations specializing in Mobile Applications follow intense requirement engineering practices in Mobile platform projects. Same is the case with for Web Projects, additionally one organization specializing in multiple type also conduct intense requirement engineering prac tices for Web projects. One reply stated that it depends upon the nature of product not the type of product. Remaining follow this mostly desktop projects with main focus in desktop applications.

Type of Project Following Normal Requirement Engineering Practices.

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

Type of Project Do Not Following Requirement Engineering Practices.

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

Success ratio of Projects Following Intense Requirement Engineering Practices.

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

Success ratio of Projects Following Normal Requirement Engineering Practices.

In response of this question one replied only with the words of average, percentage from other respondents is above 50 and less than 80%. One exception is that percentage of this questions matches with the percentage of last question. 23% (4) of organizations didn’t answer for this question.

Success ratio of Project Don’t Following Requirement Engineering Practices At All.

When talking about the percentage for this question every respondent replied with 0% to less than 50%, one mentions with only exception of 60% from one organization. One only mentioned that we don’t develop anything without requirement engineering. 23 % (4) of organizations didn’t answer for this question.

Average Length of Projects.

This question also got a varying response. 8 Organizations having 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 year. Astonishing fact is that these organizations’s main focus is on Web projects. One organization with more than 1000 employees, 30 employees at time working on specific project completes in 3 to 5 months. One with 300 employees takes 1 week to 7 years.

Significance of Using Requirement Engineering Practices in Your Organization.

Respondents in the survey answered this by the bunch of statements 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 timely deliverables and quality assurance that leads achieve business goals. Answer from another organization name requirement engineering for clearance of software requirement, manageable project, task divisions, results within predicted time frame, one praises requirement engineering for helping in bringing and organization at one point and reaching an agreement between customer and organization. One organization names it as must process which must be done in it, another terms it a symbol of success for success in projects. One mentions it as most important part in software development life cycle, absent requirements they wouldn’t be able to build an exact 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 great impact on success of projects in every organization wherever this methodology is being used. Specifically talking about this organization, most of the projects have been successfully completed and deployed on client environment by following requirement engineering practices. 23% (4) of organizations didn’t answer for this.

CONCLUSION AND FUTURE WORK

Main objective of the above research is to show how much of requirement engineering principles are followed in software industry of Pakistan. Thing of note is that most of the standards of requirement engineering are not followed in small and average size companies. Above is response from only 17 organizations, in future this will be extended to more than 50 organizations. All the above figures indicate that Pakistan is far from to reach the level to excel in information technology. There is a long way to go.