Exploratory Analysis of Pakistan Software Industry on Quality Improvement by Managing Requirement Related Risks in Process Methodologies

ISSN: 2312-7694
Aleeha et al. / International Journal of Computer and Communication System Engineering (IJCCSE)
69 | P a g e
© 2014, IJCCSE All Rights Reserved Vol. 1 No.02 August 2014 www.ijccse.com
Exploratory Analysis of Pakistan Software Industry on Quality
Improvement by Managing Requirement Related Risks in Process
Methodologies
Aleeha Iftikhar Amira Ahmed
Department of Computer Software Engineering Department of Computer Software Engineering
National University of Sciences and Technology National University of Sciences and Technology
Islamabad,Pakistan Islamabad,Pakistan
aleeha.mcs18@mcs.edu.pk amira.mscs18@mcs.edu.pk
Fahim Arif
Department of Computer Software Engineering
National University of Sciences and Technology
Islamabad,Pakistan
fahim@mcs.edu.pk
Abstract— Nowadays the need of risk management has been
truly augmented but its industrial perspective is very less
explored. The product quality can improve by having proper risk
management in any process methodology. In this paper, the
domain of risk management practice within 20 software
organizations in Pakistan Software Industry has been explored.
The research begins with the study of practice of risk
management in the industry and highlights some particular
criteria. After that it investigates how the companies have
integrated their risk management with software development.
The main focus of study is handling of requirement related risks.
Regarding the state of industrial risk management practice, our
results show that there are some discrepancies between the
industrial practice and the standard models studied. The
industrial organizations have not implemented all the important
activities as prescribed by the standard models. Hence, this paper
suggests a list of issues that need to be addressed particularly of
requirement related risk management.
Keywords: process model, software development process, agile
methods, requirement risk management.
I. INTRODUCTION
The basic concept to develop a quality product, on time,
within budget is about capturing proper requirements. The
more effort devoted during requirement engineering activities
assure a better software product. Every year, many types of
software are registered for not satisfying the appropriate
requirements. This situation is even more problematic for the
agile based software development. Due to agility the
requirements capturing is not considered well and that’s why a
lot of requirement related risks occurred which result in
project failure in term of cost and quality.
The context such as no proper consideration to the
requirement related risks and to the use of appropriate agile
based risk assessment raises complexities and ultimately
results in failure. The approach to handle this situation varies
from varies from company to company, country to country
and even teams to teams, since the development has been
moved from co-located form to a distributed form. Also the
agile based working is dependent on human perception, skills
and experience. The Asia is a big industry for developing
software products. This industry started with development
phases and now RE activities has also been carried out in
Asia. This paper captures the industry practices particularly in
Pakistan industries regarding the development of requirements
from scratch to implementations. A lot of researches has been
done in software risk management field, as in [1][2][4].They
have provided a number of different frameworks and models
signifying risk types, risk management strategies, process
models and various performance measures [3][5]. Despite this
the handling of requirement risk management in agile based is
not particularly focused. As agility main core lies in risk
management after each iteration for the overall software risk
management but there are no proper criteria for managing the
requirement related risks in agile methodology. In this paper
we investigate the status of management of risks associated
with requirements in agile based software development in
Pakistan industry. Our goals are (1) To find out the current
status of development methodology used by industry (2) to
evaluate that how they manage risks associated with
requirements in agile development (3) to identify issues that
might occur during their requirement risks (4) to find out the
difference between agile and other development approaches
requirement risk management. The remaining of this paper is
structured as follows. Section 2 describes the research method
taken during our study. Section 3 describes the evaluation
criteria would be used for requirement risk management in

ISSN: 2312-7694
70 | P a g e
agile methodologies. Section 4 describes the issues related to
requirement risk. Finally, Section 5 and 6 make concluding
remarks and future work.
II. RESEARCH METHOD
This section describes the research method taken during the
study. Subsection A lists limited literature regarding to
requirement challenges and classification of requirement
problems. Subsection B describes the questionnaire used in
our field survey of Pakistan industry. Finally, outcome of the
survey has been discussed in Subsection C.
A. Literature Survey
As our industries using agile methodologies there days so our
focus is on the requirement risk management of agility. Every
software project carries some risk, but many of these risks can
be mitigated. That's true for problems related to product
requirements – problems that are often cited as one of highest
risks for any type of software project. Either it is having
unclear requirements, lack of customer involvement in
requirements development, or defective requirements, these
troubles are a major cause in projects that go away. Project
teams can make a difference by adopting and implementing
agile practices. When implemented correctly, agile practices
greatly mitigate the most common risks associated with
requirements on software development projects. Most
commonly occurring requirement risks in agility are following
A.1. Requirement Risks
1. Unrealistic Customer Expectations and Developer
Gold-Plating
This is the risk when your customer expects n demands more
then what you can develop & demand beyond the limit of time
& resources. So in order to satisfy the customer they will add
extra features that is gold plating.
2. Insufficient Customer Involvement
The most common project risk is a lack of involvement of
customers. A precondition on agile projects is that it requires
the customer to participate in each iteration. Customer decides
the goal for each iteration & should be always available on
site for answering questions.
3. Poor Impact Analysis
A product is rarely encountered with fixed, clear requirements
changes to requirements and shifting priorities can affect the
sequence of work, introduce unexpected rework, or create
product defects. Poor impact analysis involves not
understanding the ways that new and changing requirements
affect the set of proposed requirements that make up the
baseline (the traditional requirements term) or backlog (the
agile term).
4. Scope Creep
The uncontrolled expansion of requirements throughout the
project is the highest risk of any software project [6]. In
addition, the larger the product, the more requirements grow.
Yet, scope creep might actually be considered "normal." Some
stability is, of course, necessary. Product goals, objectives,
target market and users, and a product vision need to be
articulated.
5. Defective Requirements
Requirements defects include missing, erroneous, conflicting,
or ambiguous requirements, which can lead to developing a
defective product. Even worse, it can lead to building the
wrong product. On an agile project, small, concise
requirements (stories) are sharply defined once the customer
has chosen them from the backlog. Defining story "doneness"
is essential.
6. New Processes and Tools
How do agile teams reduce the risks associated with using
new requirements practices and tools? How do teams mitigate
the normal risks of any change? They minimize these risks
through feedback, metrics, and coaching. A key metric for
agile teams is the burn down chart, showing the rate at which
stories or tasks are being completed, measured in hours per
day.
7. Real Risk Reduction
There are Myths that agile practices ignore or avoid good
requirements practices and can increase requirements risks. In
reality, agile decreases common requirements-related risks.
Adapting agile practices can allow the team to act in regularity
with the dynamic nature of requirements development and
facilitate the delivery of "solutions that meet business needs,
goals, or objectives" [14][15].
A.2. Classification of requirement problems
The commonly occurring problems are classified in literature
accordingly.
1. Application:
Unfamiliar, Complex and Dangerous
2. Stakeholders:
Incorrect assumptions, Incorrect or insufficient knowledge,
Insufficient skills or experience, Insufficient involvement,
Disruptive behavior.
3. Process
Scope too narrow or too broad, Inadequate discovery,
Incorrect derivation, Insufficient attention to nonfunctional
requirements, Confusing responsibilities, Context independent
(i.e. rigid) tasks, Ineffective communication or negotiation,
Too much or too little specification, Inadequate verification
and validation, Creeping scope, Ineffective change or info
management, Inadequate defect data collection.
4. Resource:
Critical stakeholders overlooked, unavailable, Or under
involved, arbitrary schedule as hard requirement, Inadequate
time for analysis and learning, Insufficient tool support.

ISSN: 2312-7694
71 | P a g e
5. Complexity :
Social (stakeholder group) Application (problem), Design
(solution)
6. Change:
Individual requirements unstable, Scope expands or refocuses,
Rate of change does not decrease rapidly enough [16].
In the literature, there is no universally accepted approach to
risk management. However, this is an reasonable finding that
the process of risk management will differ across various
industries and projects ―one cannot expect that a single,
universal risk management process and its supporting set of
tools and techniques would be applicable to all types of
projects‖ there are different types of projects, we should
expect to see different kinds of risk management
practice.‖[17]
As there is no unique and universal model to mitigate the
emerging requirement risk in the project development. This is
the reason why Pakistani software industries are not handling
these risks. To address this problem a fieldsurvey of different
software houses was conducted and asked them different
questions.
A. Questionnaire
The questionnaire used in this study consisted of four parts.
As shown it in Table 1, in the first part, “Section 1 :
Introduction”, enquired about the background information
concerning the interviewees and their organizations. In the
second part, “Section 2 : Risk Management”, investigation
shows that how the risk management practice within the
organizations conducted and what its usefulness. In the third
part, “Section 3: Requirement Risk Management‖ we
explored that whether they use any methodologies regarding
to mitigate particularly requirement related risks. Finally, in
the fourth part, “Agile vs. traditional Risk management”,
integration of risk management with agile method is studied.
The questionnaire used in this study was open-ended and semi
structured. The purpose was to give freedom to respondents to
answer in their own terms [6]. Such types of interviewing has
a positive effect in a sense that while interviewing, one may
elicit more knowledge about the studied domain Its drawback
however is the fact that the interviewer must possess a good
understanding of the domain studied, in order to adequately
react to irrelevant answers.
III. EVALUATION CRITERIA
This section provides our evaluation criteria. Subsection A
lists and describes the criteria which were used to conduct the
question on risk management. Subsection B describes the
criteria used for RRM. Subsection C compares the traditional
and agile risk management.
A. Criteria for Risk management in Pakistan industrial
practice
When studying the industrial status of risk management, six
criteria were chosen that covered some of the fundamental
aspects of risk management [7]. Based on these criteria,
created the first two sections of interview questions as listed in
Table 1. The criteria and their related questions are briefly
described below.
1. Risk identification practice:
Risk is an event or a condition that may affect the outcome of
a project [8]. Its identification and classification is a
prerequisite for effective risk management [8]. Questions 7
and 8 investigate whether and how the organizations studied
identify and categorize risks.
TABLE I. DISTRIBUTION OF QUESTIONNAIRE IN THE SURVEY
Section 1:Introduction
1. What is your name?
2. What is your email?
3. What is the name of your
company
4. What is the number of
employees?
5. What is your role in company?
6. What type of product/services
does your company provide?
Section 3: Requirement Risk
Management
17. What software development
process model(s) do you use?
18. Do you consider risk
management while taking the
requirements for your product?
19. What is the most frequent
area where risk occurred?
20. What is the cost associated
with your requirement
management?
21. How much time do you give
for your Risk management
regarding requirements?
Section 2:Risk Management
7. Does your organization
identified risk?
8. What type of risks do you
generally identify and manage?
9. What roles are involved in risk
management?
10. If you have different types of
risks. Do you have model
specialized to each risk type?
11. Do you record risk and risk
management process?
12. What exact risk information
is recorded?
13. Does the recording of risk in
different phases of software
development is done?
14. Are there any problem
regarding your current risk
management process?
15. Do you think risk
management is important?
Section 4: Agile vs. Traditional
Risk Management
22. Is Requirement Risk
management is needed in agility?
If yes/no, why?
23. What is difference between
agile and traditional risk
management. Point to Ponder:
The survey is conducted from
different organization
(medium/small and
private/government) in Pakistan.
The only requirement of
choosing the organization
studied should have a risk
management process. Due to
sensitivity of material produced
do not name them however some
are major well-known
multinational organizations.
2. Roles and responsibilities:
Stakeholder roles are individual roles or role groups who have
a stake in or may be impacted by a given activity [8].
Questions 9 investigate what roles are covered by the
organizations studied.
3. Risk management process:
The risk management process consists of a set of phases and
activities that are necessary for conducting risk management

ISSN: 2312-7694
72 | P a g e
on software projects [9]. Using Question 10, investigated
whether they tailor them to specific types of risks.
4. Risk recording and documentation practice:
To aid in maximizing the quality of the risk information, one
should document the risk and provide guidelines for what
information should be managed during the risk management
process [10]. Using this criterion in Questions 11,12,13, we
explore whether and what kind of risk management
information is recorded.
5. Risk management process problems: Problems
related to the risk management process provide a good
platform for evaluating the process, identifying its
deficiencies, and for making process improvements. For this
reason, using Question 14, we elicit risk management process
problems within the organizations studied.
6. Importance of risk management:
Many voices have been heard regarding the importance of
risk management [11]. These voices have mainly been raised
within the academia. Little is however known about the
attitude towards risk management within the industry. Hence,
we find it out using Question 15.
B. Criteria for Requirement Risk Management
After having a glance on their risk management activities, we
ponder towards the main focus of our research about handling
of requirement related risk in Pakistan software industry. For
this authors used four particular criteria are that covered our
research. Based on these criteria, section 3 and 4 of our
questions were created as listed in Table 1.
1. Risks consideration of requirement elicitation:
Most of the risks occur during the initial period of software
development so the risk associated with the requirement must
be considered. Question 18 investigates that whether they
tailor with these risks.
2. Frequent area of risk occurrence:
The important area of risk occurrence should be considered
and this is explored in Question 19.
3. Cost and time associated with Requirement Risk
Management:
Every software development needs a specific project planning
for their software development. So the cost and time
associated with Requirement related risk must be considered.
So question 20 and 21 explored this thing
4. Applicability of risk management in agile context:
Due to the fact that agile methods claim to be risk driven
[12][13], we wished to hear the industrial point of view about
this issue. For this reason, inquired about the differences
between the agile and other traditional development
approaches with respect to the risk management practice. Also
the use of requirement risk management is analyzed. And
what are more beneficial for them. So Question 22 & 23 was
explored and the difference between these two approaches was
conducted.
IV. STATUS OF REQUIREMENT RISK MANAGEMENT IN
PAKISTAN SOFTWARE INDUSTRY
This section presents the status of risk management
particularly of requirement related in Pakistan industry.
Section IV.A describes the overall risk management status
while Section IV.B explains the requirement related risk
management.
A. Risk Management State of practice
In this section, paper presents the state of risk management
practice within the 20 organizations studied. When doing it,
we follow the order of the comparison criteria as listed in
Section III.A.
1) Risk Identification Practice
All the 20 organizations studied identify various risk types.
The types identified include Business, Financial, Project,
Process, Planning, Resource, Technical, Organizational,
Legal, Country Product and Quality risks. The technical risk is
further classified into Requirement definition and management
and developing Skills of developer.
2) Roles and Responsibilities
The majority of the organizations studied put the Project
Manager role in charge of risk management.
3) Risk Management Process
Almost all of the studied organizations, 14 out of 20, have
defined a risk management process model. The remaining four
companies do not have any documented model. However, they
conduct risk management in their respective companies. In
one organization, it is claimed that their risk management
process relies on tacit knowledge, whereas the other three
organizations claim that their risk management is implicit in
their agile Analysis of Question 10, 2 out of 20 organizations
have specialized their general process models for managing
specific types of risks. The remaining 18 companies have not
implemented any specialized models. They claim that (1) most
of their risks are similar in nature; hence, their management is
similar (2) it is too costly to develop and maintain several
models, (3) it is unnecessary to create specialized models
when there is a generic process model already, and (4) it is
difficult to scope the specialization.
4) Risk Recording and Documentation
Practice Almost all the companies state that they record risks
and risk management activities. But this is not a particular
type of risk management it’s just the recording of risk on excel
sheet to keep in track that the risk occurred but no proper
documentation is done. As most of companies use agile
processes. They claim that there is no procedure for recording
risks in these models.
5) Problems with Risk Management
As almost in all companies the agile methodology is used but
they still face some kind of risks and management to these risk
are quite risky. They are the following:
• Attitude towards risk management process:
Many employees do not take risk management process
seriously.

ISSN: 2312-7694
73 | P a g e
• Scalability problem:
Informally defined risk management process models suit well
for small projects. However, they are difficult to adapt to large
projects.
• Shortage of experienced risk managers:
The personnel do not possess satisfactory knowledge and
experience within the risk management domain.
• Lack of or insufficient tool/repository support:
Some organizations do not have tools for recording risk
information or tools that provide enough feedback for making
various analyses e.g., historical analyses.
• Integration problems:
Risks are mainly considered in the context of software
development. Other risks, such as environmental or
organizational ones, are not always managed.
• Lack of resources:
Organizations lack resources for performing risk management.
Because of this, they may not be able to pay enough attention
to identifying all risks and to fully monitor and control risks
that may create serious problems.
• Terminology problem:
People have their own terminology which makes it difficult to
communicate risks effectively [19].
• Lack of formal and standard documents for recording
information about risks:
Organizations do not have any guidelines for how to
document information about risks. This in turn leads to non-
uniform way of documenting risks, thus obstructing effective
risk management.
6) Importance of Risk Management
All the companies agree that risk management is important.
More than half of them claim that risk management is very
important for the following reasons:
• The earlier you find the risk, the easier it is to mitigate it,
thus leading to a lower total development cost.
• By controlling and mitigating the potential threat, one
becomes preventive instead of reactive to various risks. In
this way, one may avoid many serious problems in the
future. •
• A properly defined risk management process model is of
great aid when prioritizing various types of risks, a task
that is experienced to be very difficult by the
organizations studied.
A. Requirement Related Risk Management
This section presents the result regarding the Requirement
related risk management in the industry which is mostly using
agility. When describing them we follow the order of criteria
as listed in Section III.
B. .Risks consideration of requirement elicitation
Only 2 of the large companies out of 20 consider the risk
management while eliciting the requirements by using the
traditional risk management techniques. While other
companies’ slogan the state that ―Techniques of agile methods
themselves are about reducing the risks of project failures and
no matter what the nature of the agile method, a risk
management framework will always be in place‖[17].But this
is not always right because requirement related risk occurred
and they have no proper management to these types. Mostly
the requirement related risks which they mostly occurred are:
 Miscommunication of requirements
 Unclear scope/objectives
 Changing requirements
 Improper change management
 Unrealistic schedule and budget
 Misunderstanding of requirements
 Unrealistic expectations
 Gold platting
 Inaccurate estimation of schedule or cost
2. Frequent area of risk occurrence
Almost all the companies are unable to suggest a particular
area of risk occurrence. But on the basis of our analysis it was
seemed that if requirements-related risk factors are not
controlled, it might result in either building the wrong product,
or building the right product badly. Either situation results in
unpleasant surprises and unhappy customers.
3. Cost and time associated with Requirement Risk
Management
There is no particular time and cost estimation given to the
requirement risk management which results in an inaccurate
initial estimation can lead to inadequate allocations of budget,
or time, or both, to the project, which can then cause it to fail.
The estimate drives every aspect of the project, constrains the
actions that can be taken in the development or upgrade of a
product, and limits available options. It is believed that most
impromptu estimates of project scope based on the
engineering or management experience are incorrect and are
often based on simple assumptions and over-optimism; or
worse are made to accord with what others want to hear.
Needless to say, such estimates often lead to disaster. If the
estimate is unrealistically low, the project will be understaffed
from its outset and, worse still, the resulting excessive
overtime or staff burnout will cause attrition and compound
the problems facing the project
4. Applicability of Requirement Risk Management in
Agile Context
The answers to the question regarding the use of requirement
risk management in there agility. They are the following:
• Seven companies claim that risk management
is not useful in agile projects. They motivated it with the
following (1) the particular risk management model is too
complex; (2) the agile model with its iterative approach
already has risk management by its nature. Hence, the need for
separate requirement risk management is limited.
They are the following:
• Two companies did not respond to this question because
they were not familiar with the agile process model.

ISSN: 2312-7694
74 | P a g e
• Eleven company’s claims that it might be a good horizon
to reduce the risk from quite at its start and that will
definitely helpful in reducing the project failure.
Concerning the question about the differences between
projects using agile and other types of process models, 16
out of 20 companies claim there are differences in how
risk management is carried out in agile versus traditional
projects. Four companies claim there are no differences
and companies did not respond to this question. The
differences identified are:
• Time aspects: The risk is not exposed until late in the
traditional projects. The iterative nature of agile projects
allow them to identify risk areas sooner rather than later
• Development approach and risk management effort: The
iterative development approach minimizes risks and the
total risk management effort.
• Follow-up and control mechanisms: The risk
management process activities are conducted sequentially
in traditional approaches and usually managed via various
documents and formal inspections, whereas risks are
managed through other types of controls in agile models,
e.g. via the backlog and daily meetings. The team
continuously manages risks at the daily and other review
meetings rather than via documents as in many traditional
approaches
• Frequency of risk management: In the agile context, risk
management is conducted more frequently than in the
traditional context. The agile cycle is shorter than in other
models
V. CONCLUSION
In this paper, we have studied the industrial practice of risk
management particularly for requirements in 20 software
organizations. Regarding the industrial status of the risk
management process. No particular organizations have
implemented the entire process. They have just done it where
required which resulted in ultimate failure.
Our study also reveal the main focus on the handling of
requirement related risks should also be considered because
they are mostly neglected specially in agile methodologies.
We have found that risk management is needed in any
development model, whether traditional, agile or other.
Although, there are claims that the agile models include risk
management by nature, the agile models provide very general
guidance for managing risks [18]. In Pakistan software
industry adopting agility is a good way to avoid the risk as low
as possible. It is only in this way, one may make sure that risk
management is implemented and run in an effective manner.
VI. FUTURE WORK
The findings made in this study indicate that the standard risk
management have not sufficiently reflected the practice and
needs of the organizations studied. The small sample size and
the convenience sampling method should not allow us to
generalize these findings. However, we believe that they
provide a valuable feedback about the status of requirement
risk management process. To confirm our results, it is
suggested that similar studies be conducted on a vast scale.
REFRENCES
[1] Charette R., ―Software Engineering Risk Analysis and
Management‖, McGraw Hill, New York, NY, 1989.
[2] DeMarco T., ―Risk Management for Software Projects‖.
The Atlantic Systems Guild, Camden, ME, 2004.
[3] Carr M.J. et al., ―Taxonomy-Based Risk Identification‖.
SEI Technical Report CMU/SEI-93- TR-006 ESC-TR-93-
183, SEI/CMU, Pittsburg, PA, 1993
[4] Jones C., Patterns of Software Systems Failure and
Success. Boston, MA, International Thomson Computer Press,
1995.
[5] Fairley, R., ―Risk Management for Software Projects‖
IEEE Software, Vol. 11 (3), 1994, pp. 57–67.
[6] Walker R., Applied Qualitative Research, Gower
Publishing Company Ltd, 1985.
[7]Nyfjord J. and Kajko-Mattsson M., ―Commonalities in Risk
Management and Agile Process Models‖. Proc. of 2nd
Int.
Conf. on Software Engineering Advances, France, 2007.
[8]IEEE 1540, IEEE 1540 Standard for Lifecycle Processes-
Risk Management. IEEE, New York, NY, 2001.
[9]Project Management Institute, A Guide to the Project
Management Body of Knowledge (PMBoK), 3rd Ed.
ANSI/PMI 99-001-2004, PMI, Newton Square, PA, 2004.
[10] Hulett D.T., ―Key Characteristics of a Mature Risk
Management Process‖. Proc. of the European Project
Management Conf./PMI Europe, 2001
[11] IEEE Software, ―Managing Risk‖ (special issue). IEEE
Software, Vol. 14 (3), 1997.
[12] Beck K., Extreme Programming Explained: Embrace
Change. 2nd Ed. Upper Sadle River, NJ, Addison-Wesley,
2004
[13] Eclipse Process Framework (EPF), OpenUP Process.
URL: http://www.eclipse.org/epf/. Accessed November 2007.
[14] ―International Institute of Business Analysis (IIBA) A
Guide to the Business Analysis Body of Knowledge‖, version
2.0,
[15] Ellen Gottesdiener,―The Software Requirements Memory
Jogger‖, 2005.
[16] David Gelperin ,―Identifying and Controlling
Requirements Risk‖,
[17] ―A case study of risk management in agile systems
development‖ by Coyle, Sharon, Centre for Innovation and
Structural Change, J.E. Cairnes Graduate School of Business
& Economics, National University of Ireland, Galway
(NUIG), Ireland
[18]International Standardization Organization (ISO), ISO
9000:2005 Quality management systems-Fundamentals and
vocabulary. ISO, Switzerland, 2005.
[19] W Abbas, N Abbas, U Majeed, ―Performance
enhancement of End to End Quality of Service in WCDMA
wireless networks, Science International Journal Vol. 26 issue
02, Pp 613-620, 2014.

Exploratory Analysis of Pakistan Software Industry on Quality Improvement by Managing Requirement Related Risks in Process Methodologies

Recommended

Recommended

More Related Content

What's hot

What's hot (19)

Similar to Exploratory Analysis of Pakistan Software Industry on Quality Improvement by Managing Requirement Related Risks in Process Methodologies

Similar to Exploratory Analysis of Pakistan Software Industry on Quality Improvement by Managing Requirement Related Risks in Process Methodologies (20)

More from International Journal of Computer and Communication System Engineering

More from International Journal of Computer and Communication System Engineering (20)

Recently uploaded

Recently uploaded (20)

Exploratory Analysis of Pakistan Software Industry on Quality Improvement by Managing Requirement Related Risks in Process Methodologies