Abstract design process using either synchronous (Face to

Abstract

In software development the
requirements engineering is the most importance part. Efficient and correct
requirements made the solid foundation of system. Any weakness in requirements
elicitation or analysis phase may lead to many problems like failure of system,
customer’s dissatisfactions, delay in time frame and increase in cost. Now the
projects are developed and deployed internationally then the distributed
development has become more popular. This paper will show how the distributed
requirement engineering is important, main risk and threat associated with
distributed requirements engineering and finally discuss the techniques for
efficient distributed RE.

Introduction

In this era world has become
global village. Software are developed for broad prospective. Customers demand
high quality products. Competition is very high and customers have more options
in market. Now it become very important to maintain quality on affordable
price. Companies cannot afford bugs or errors in their developed systems so
they tries to hire best team members from all over the world. But at the same
time some diversity issues are also come into the system when team members
belongs different locations.

In this paper at the beginning I
discussed the importance of distributed requirements engineering at this time.
Along with the importance and need of distributed RE process I also shortly
discussed the activities involved in distributed requirement engineering
process.

After that in the last section of
paper I discussed the issues related to distributed system development because
where distributed development has some benefits where it also has some
drawbacks and risks. After that I listed and discussed the techniques for
distributed requirements engineering by using them organizations can come up
with risks associated with this approach.

 

Why Distributed Requirements Engineering?

There are many organizational
factors demand for distributed software development. These factors have been
identified including 1;

·        
Some skilled and
specialized project members don’t want to travel.

·        
Specialized hardware is
located somewhere else.

·        
Lack of skilled and
specialized workers in a specific geographical area.

·        
The cost of travel and
relocation is too much.

These factors are motivating for
distributed software development, but this does not automatically produce gain
in productivity and quality. However software engineering related researches
and literature has identified advantages of distributed software
development. 2, 3, 4, 5

A software design experiment
conducted 3 by some software engineers and designers team. In
their experiment they compared the creativity and quality of work achieved by
two different meeting groups (face to face and distributed environment). Forty-one
groups of teams participated into experimental study, they carried out a design
process using either synchronous (Face to face) or asynchronous (distributed)
meetings. The results were amazing. They proposed that distributed groups
produced more creative and possibly higher quality software design as compared
to synchronous face to face groups. The study proposed that the better
performance of asynchronous distributed groups is due to the availability of
computer support tools to facilitate the process. Here the use of email has
been found as a rich communication tool for asynchronous collaboration. Use of
email has some notable advantages like, management of communication, files
transfer, low cost, flexible, easy access to information resources and
broadcasting capability.

At Fujitsu Corporation a study
found that, software development cycle time was reduced 75% by applying the
asynchronous software development methods. When software development team
members are distributed in different locations, the development process will
continue around the clock across time zones.

 

Distributed Requirements Engineering Process

Basically here are two main tasks
which needs to be performed during requirement engineering process.

       
i.           
Problem analysis:                               Analyze the software problem.

     
ii.           
Product functional Description:          Required external behavior of
software system.

To perform these two tasks during
distributed requirements engineering process the whole process is divided into
four activities. These four activities are,

        
i.           
Requirement Elicitation

       ii.           
Requirement analysis and
Negotiation

     iii.           
Requirements Specifications

     iv.           
Requirements Validation

Figure 1
– Requirements Engineering Process

 

 

 

 

 

 

 

 

 

 

 

 

       i.           
Requirement Elicitation

This is the practice of
collection of requirements of system. This is done through consultation with
customers, users and other stockholders. This is also known as requirements
gathering. Some other sources of requirements gathering are system documents,
domain knowledge and market study. Requirements elicitation is considered as
most crucial part of requirements engineering process.

    ii.           
Requirement analysis and
Negotiation

Analysis is performed to
understand the requirements and relationship among different requirements. Negotiation
needs to be done among requirements engineer and stockholders on incomplete and
inconsistence information and budgetary issues.

 iii.           
Requirements Specifications

Requirements specification is to
build a detailed model of requirements using natural language and figures. This
representation of requirement should be detailed as this can be used for
correctness, consistency and completeness of requirements.

  iv.           
Requirements Validation

This is the stage to detect the
problems, incompleteness and inconsistency into the requirements, before these
requirements are used for development of the system.

Risks and Threats associated with Distributed RE

Riga Information Technology
Institute, Latvia 4 performed a research to evaluate the risks and
threats associated with distributed requirements engineering. They manage the
results and classified them into Risk levels from 0 to 5.

These levels (0-5) are assessed
as a combination of frequency of occurrence of the threat and the scale of its
consequences for each of the following cost related issues, time related or
morale related project results; Budget overrun, Late product delivery, Unexpected
management costs, Customer dissatisfaction from performance or product,
Undermined morale, Customer costs escalation, Disputes and litigations.

Scale

Percentage

Magnitude

5

(81-100%)

Disastrous

4

(61-80%)

Significant

3

(41-60%)

Moderate

2

(21-40%)

Minor

1

(1-20%)

Negligible

0

(0%)

None

Table 1- Risk and Threats Evaluation Scale

The researchers
take a threat significant if it is significant for cost related issues and
insignificant for e.g. moral related issues.

Survey Results

The researchers evaluated
following results for top 5 threats faced by distributed projects developments.

Threat

R.L*

F**

M***

Poorly defined or inconsistent software
requirements specifications

3

4(62%)

3

Faulty effort estimates

3

4(62%)

3

Diversity in process maturity and/or inconsistency
in work practices between the partners

3

3(52%)

3

Increased level of unstructured poorly-defined
tasks

3

3(45%)

3

Poor or disadvantageous distribution of software
development activities between the customer and supplier(s)

3

3(41%)

3

Table 2-
Threats faced by distributed projects

*Risk Level     **Frequency   ***Magnitude

The results shows
that requirements management related to the top most risks. By comparing these
results we can see that these are correlated and started from poorly defined
software requirements. Researchers also notify following threats those can also
be mentioned as the reason of poor requirements engineering.

·        
Diversity in process
maturity

·        
Inconsistency in work
practices

·        
Lack of version control

·        
Relatedness with other
suppliers

·        
Lack of language skills

·        
Terminology differences

·        
Customer employee
unwillingness to collaborate

·        
Lack of team spirit

·        
Lack of clarity about
responsibility share

·        
Poor cultural fit

·        
Lack of experience and
expertise

These results
demands the requirements engineering techniques by using them distributed
requirements engineering become more efficient, effective, correct and complete.

 

Techniques for Distributed Requirements Engineering

1.    
Meeting Facilities

In the distributed requirements
engineering process the actors of software elicitation are expected to
participate from verity of locations. So all participants should use software
to conduct and manage meetings. Some software provides online meeting facility
which make participant able to connect into meeting from anywhere through
internet browser. These online meetings among different stockholders of system
like requirements engineers and customers decrease the risk of
misunderstandings.

2.    
Evaluation Methods

Information gathered from
meetings and discussion should be evaluated carefully. The record of different
software used for meetings and conversation and emails among different
participants should be examined and monitored carefully during the elicitation
process. Some times stockholders send their requirement in their terms than it
is required to translate them in natural language.

3.    
SRS Quality

In the distributed requirements
engineering process the development of high quality SRS is most important. In
distributed RE during the virtual meetings the clients or customers doesn’t
provide explained information about system. Studies shows that they show less
interest in virtual elicitation process. Among different techniques of
requirements elicitation for SRS it is found that question answers are most
effective method. Requirements engineers can get more accurate and precise information
from client through question answer session.

4.    
Traceability

Traceability is very important in
requirements engineering. During distributed RE process some time requirements
become untraceable. But for efficient requirements engineering it is important
to maintain the records properly. Every requirement should be traceable.
Without the traceability negotiation and change management becomes difficult.

5.    
Reduce Diversity

In the
distributed development the diversity is main issue. Peoples involved in the
process belongs from different location, interests and priorities etc. There
way of thinking may also be different. So it is important to conduct some
workshops and provide proper training to staff members that will decrease the
diversity factor and increase their understandings.

6.    
Requirements elicitation
template

The participants
into the elicitation process belongs to different locations, having different
educational background and different style of thinking and observing. Then it
can be produced some problems with the development team expectations.

So it is
therefore useful to discuss what kind of specifications are required from
client at the beginning of requirements elicitation and analysis phase. A
template should be developed and used for gathering requirements.

7.    
Develop a glossary

In distributed
system linguistic and context difference can cause misunderstandings in the
process of requirement analysis. Some project managers or other team members
reports what they understand but their report may be hard to understand for
other team members due to terminology difference in a certain business sphere.

There for it is
useful to come to a general agreement on terminology by developing a joint glossary.

8.    
Clear Responsibilities and priorities

Between the
virtual team members of a joint project the chance of miscommunication always
remain high. To deal with this issue it is better approach to clarify the role
and responsibility of each and every person at the beginning of project.

Sometime a
manager do not allow team members to communicate directly with each other. In
this case it become difficult to manage requirements and analyze them. So the
organizational priorities are also established and cleared to every participant
of project.

9.    
Maintain constant
communication

It should
understand that all problems and issues can not discussed through emails or
phone calls. It is important to experienced managers should conduct face to
face meetings with all team members to understand their problems and issues and
also guide and teach them through his experience. Advance video conferencing
tools are also effective and should be used whenever possible.

Conclusion

It was difficult
to find resources with expertise. But now the world has connected through
internet it is efficient approach to use resources from different locations.
But issue is to use these resources efficiently. Requirement engineering is the
crucial stage of software development life cycle. In distributed RE there are
some threats and risk are found. But these can be handled by using different
techniques of distributed requirement engineering. 

Written by