Research paperV1

Bahria University Islamabad
MS SE (1)
Requirement Specification
Techniques & Related
Problems
Submitted by: Lakht E Hassnain

Requirement Specification Techniques & Related Problems
Group 1.Hassnain & Adil Nazir Page 1
Introduction
The SRS document describes the full details behavior of the system to be developed. It is contract
between developer and customer covering the entire requirements including functional and non-functional
requirements and its constraints. It describes all the functions and their details that the user required in
product.
In this research we will study many requirement specification techniques used in our industry and issues
related to them. Issues and problems related to requirement specification can be divided into two broad
categories. Issues /constraints in adopting specific technique and Issues those encounter after using it.
There are many requirement specification methodologies available in literature like Requirements
specification using natural language, Mathematical Symbols and formulation, Excel sheets, Use case
analysis, Global analysis, O’Brien’s approach, Quality Attribute Workshop (QAW).We have covered this
part in literature review section of this paper.
In our research paper we study and analysis the different requirement specification techniques that are
used in our industry and also find out some problems that effects the software requirement specification
Process and product quality. For research we use quantitative method. After analyzing the requirement
specification methods, literature review and discussion with some requirement engineers those are expert
in this field, we are able to develop a questionnaire that cover the number of questions that we required
for our research paper.
In methodology for research part, it will be elaborated that how the initial study and data gathering has
taken place for this research. Interactive questionnaire techniques has used among many of the available.
For Data analysis part we have done some pictorial representation against responses we have collected.
We write down all the issues that we analyze through questionnaires and show them through bar chart.
For the shortage of the time we can’t give the solution of these problems, so in future we try to give some
solutions according to these problems.
In future work section, it will be elaborated that what actions can be taken to validate this research against
international market.

Literature view
There have been many researchers those already conduct work related to this topic and give also
solutions. The researcher Donald Fire smith conducts his work related to this topic. He says that he
summarize the 12 worst of the most common requirements engineering problems that he has observed
when he was working on different types of projects and his role is different like requirement engineer,
trainee or when he is work as consultant. He says that he used industry’s best practices and solves the
problem that occurred during requirement specification. These problems are very common and raise a
head when you work on any product. But our industry best practices still far from being put into practices.
[1]
Another researcher Bashar Nuseibeh’s Steve and his collogue Easterbrook present the over view of field
of requirement engineering. They described the key area of requirement engineering practices and
highlight the key future research issues also. [2]
The Michel dos Santos Soares and Jos Vrancken describe the initial phase of software engineering and
tells requirement engineering how much important in sdlc. They tell the model driven approach and the
use and importance of use case diagram. [3]
Ken Abernethy and John Kelly describe the importance and use of formal methods in requirement
engineering phase and tell how it helps to make quality SRS document. [4]
Rita Butkiene1 and Rimantas Butleris2 have described the use of case tools and its importance. They also
described how use of case tool affects the quality of requirement specification process. [5]
Christian Danger , Daniel M. Berry and Erik Kamsties presents in this paper an approach for reducing the
problem of imprecision in natural language requirements specifications with the use of natural language
patterns, which allow formulating requirements sentences in a more complete, less ambiguous and more
accurate way. To ensure the applicability of their approach they based their patterns on a Meta model for
requirements statements for embedded systems.
With this Meta model, they ensure that all forms of requirements statements are described with the
patterns. They validated the effectiveness of the patterns by using them to rewrite a substantial, previously
written, requirements specification to eliminate its imprecision. [6]
In this paper Martin Glinz identify and demonstrate various problems and deficiencies of UML,
particularly concerning use case models and system decomposition. They also investigate whether and
how the deficiencies can be overcome and how potential alternatives could look. [7]
 Ian Summerville, Sawyer describes that in this paper they used viewpoint‐oriented approaches to
requirements engineering and a presentation of new work in this area which has been designed with
practical application in mind. They describe the benefits of viewpoint‐oriented requirements engineering
and describe the strengths and weaknesses of a number of viewpoint‐oriented methods. They discuss the
practical problems of introducing viewpoint‐oriented requirements engineering into industrial software
engineering practice and why these have prevented the widespread use of existing approaches.
Then they introduce a new model of viewpoints called Preview. Preview viewpoints are flexible, generic
entities which can be used in different ways and in different application domains. They describe the novel
characteristics of the Preview viewpoints model and the associated processes of requirements discovery,
analysis and negotiation. Finally, they discuss how well this approach addresses some outstanding
problems in requirements engineering (RE) and the practical industrial problems of introducing new
requirements engineering methods. [8]

Martin Glinz says in this paper that UML has become a standard language for modeling software
requirements and design. He investigates the suitability of UML as a semiformal requirements
specification language, using the Teleservices and Remote Medical Care (TRMCS) case study as an
example, he identify and demonstrate various problems and deficiencies of UML, particularly concerning
use case models and system decomposition. He also investigates whether and how the deficiencies can be
overcome and how potential alternatives could look. [9]
 Linda Macaulay andChris Fowler said in this paper that many of the problems comes from an insufficient
user orientation on the part of the specifies. A number of current approaches to software requirements
specification are reviewed and the need for a methodological approach to requirements capture and
specification is discussed. The approach they used for software requirement specification is the User
Skills and Task Match (USTM) methodology. USTM is assessed against other current approaches and the
specified criteria. The aim of the USTM methodology is to provide a user-centered approach to
requirements specification. It focused on the user’s environment and the starting stage of product. [10]
The above all the researchers work very well and perform excellent job. But the main difference between
their research and our research is that they only relay on their own experience and they don’t include the
any type of survey research or questionnaire. But we work on different software houses and meet
different experts of this particular field and get knowledge and on the basis of this knowledge we analyze
the problems those occurred during requirement specification implementation. After analyzing problems
we design the questionnaires we send it to different software houses. After getting response we gather this
empirical data, we work on it and design this research paper.

Problem statement
The problem that we mentioned in this paper is “Requirement Specification Approaches in industry and
associated problems”. We have many approaches those are used in industry but using these approaches
we are facing lot of problems and without solving these problems we don’t make a quality software
product.
In our country software industry is not that much mature and big in size. For that matter, there is less R &
D involved in applying new methodologies and also there are budget constraints. In addition to this, there
is also issue of project length. Mostly in Pakistan there are smaller projects w.r.t global market so there is
not as much need of state of the art techniques and methodologies to be applied for software development.
They have not proper experts for every field. Especially in software requirement engineering field. Mostly
there is single resource performing many tasks because of low budge of Project.

Methodology
First decide that what approach for research, we should be followed so we select quantitative research
method. We study different approaches that can be used in industry to make software requirement
specification and after this select the best and common seven approaches those are given below.
a) Requirements specification using natural language
b) Mathematical Symbols and formulation
c) Excel sheets
d) Use case analysis
e) Quality Attribute Workshop (QAW)
f) O’Brien’s approach
After a brief discussion and study of some research papers those related to this topic, we select different
questions and design a questionnaire.
After completing questionnaire check it from different experts and after some modification sends it to
top software development organizations of country by email, TCS and by hand. When we receive the
response from these organizations, we gather the information and analyze it. We analyze every question
one by one with detail and check the response about this question and compare with other questionnaire
and after checking all questions we find some data, with help of this data we find result and show it with
text form and also pictorial representation.

Findings
After gathering information in the form of questionnaires we select the questions from these
questionnaires and interpret the questions and get data. We discuss the all question one by one in detail
and also show the response of all questions with bar charts.
1-Please choose Requirement Specification method(s) which is applies in your organization?
In this question we ask about the requirement specification method from all the organizations and give
the many options like Requirements specification using natural language, Mathematical Symbols and
formulation, Excel sheets, Use case analysis, Quality Attribute Workshop (QAW), O’Brien’s approach
and also give option that if none of all then please specify if they have some different method. So
different software organizations select different methods and all organization selects one option from our
option no one specify another. We get good response against this question. Bar chart shows the response
of organizations against options and over this entire question.
2- Please choose reason(s) for adopting above method(s).
In this question we ask reason for adoption above methods and also give some options for selection
like management decision, organizational culture (SOP), Success stories, experts availability, varies
project by project, understandability for all Stakeholders, constraints (Effort, Time, Budget etc.),
availability of specialized CASE Tools and also give option if they choose for another reason that is not
in these options please specify. We get good response against this question. Bar chart shows the response
of organizations against options and over this entire question.
0
1
2
3
4
5
6
7
8
Responses
Req Spec using natural language
Mathematical Symbols and
formulation
Excel sheets
Use case analysis
(QAW)
O’Brien’s approach

3- Is your organizational culture allows you to adopt some other method or technique for Requirement
Specification?
In this question we ask to an organization about its culture and ask how much it flexible to adopt some
other method or technique for requirement specification. We give some option like YES, NO and don’t
know. We consider the only those response in that user give answer in form of yes or no. we don’t
consider the option of don’t know. We get good response against this question. Bar chart shows the
response of organizations against options and over this entire question.
4-What are the possible issue(s) in managing the SRS Document?
In this question we ask about the issues those occurred during managing SRS document and for this
question’s answer we give no of possible issues that we find out after literature review like Size of
document, Understandability for all stockholders, Methodology flaws, Achieving Traceability is
difficult, Achieving Testability is difficult, Achieving Requirements consistency, Achieving
Requirements continuity, Support for Variability and also give option if not please specify. We get good
response against this question. Bar chart shows the response of organizations against options and over
this entire question.
0
0.5
1
1.5
2
2.5
3
3.5
4
4.5
Responses
Management Decision
(SOP)
Success stories
experts availability
varies project by project
understandability for all
Stakeholders
constraints
0
2
4
6
8
10
Responses
YES
NO
Don't Know

5-Which Specification approach is used in your organization?
In this question we ask about the specification approach that is used in organization and give number of
options like Natural language, Mathematical modeling, Graphic base, Mixing natural language and
graphics base. We gather data and get response from in this question and also show into form of bar
chart.
6-which factors are important for selecting appropriate specification approach?
In this question we discuss the factors those are important for selection an appropriate specification
approach and give also options like Prior experience in that approach, Nature of project and also give
option if other than these two please specify. We get good response against this question. Bar chart
shows the response of organizations against options and over this entire question.
0
1
2
3
4
5
6
7
8
Responses
Size of document
Understandability for all
stockholders
Methodology flaws
Achieving Traceability is difficult
Achieving Testability is difficult
Achieving Requirements
consistency
Support for variability
0
1
2
3
4
5
6
7
Responses
Natural language
Mathematical modeling
Graphic base
Mixing natural language and
graphics base

7-Do you maintain another document from this requirement specification?
In this question we ask the about the maintainability issue and also discuss the option if we have SRS
and we want to make another SRS from this document then this requirement specification and get
response in the form of yes, no and don’t know. We gather data and get response from in this question
and also show into form of bar chart.
8-Is your adopted method for requirement specifications facilitates you to extract Architectural
significant requirements?
In this question we ask that how much support requirement specification method your organization to
extract architectural significant requirements. We get the response in the form of yes, no and don’t know.
We get good response against this question. Bar chart shows the response of organizations against
options and over this entire question.
0
2
4
6
8
10
Responses
Prior experience in that
approach
Nature of project
OTHERS
0
2
4
6
8
10
Responses
YES
NO
Don't Know
0
2
4
6
8
10
Responses
YES
NO
Don't Know

9-Is your adopted method for requirement specification facilitates you to apply any requirement
prioritization technique to prioritize requirements?
In this question we ask that how much facilitates you your requirement specification when you want to
prioritize your requirements. We get good response in the in the form of yes, no and don’t know. We
gather data and get response from in this question and also show into form of bar chart.
10- Is adopted method for Requirement specification allows Requirements Derivation from the business
and mission goals for the system?
In this question we ask that how much helpful your method that you adopted to drive mission goal from
business goal. It’s a good question to know about the any method that any organization adopted. We give
choice in the form of yes, no and don’t know. We get good response against this question. Bar chart
shows the response of organizations against options and over this entire question.
11-Which of problem often arise in requirement specification?
In this question we want to find some problems that arise in requirement specification that affect the
quality of product. We give some problem for choice in this question that would be occurred like Poorly
structured, which leads to confusion and misinterpretation, Include ambiguities, inaccuracies, and
inconsistencies, Use words that have dual meanings and lack context for proper interpretation, Written at
varying levels of granularity across system elements ,Use a large number of “shells” and “wills,” which
makes reading difficult, Reflect an unstructured view of the desired operation of the system and also give
choice if they face any other that we not mention in this question they can specify. We gather data and
0
2
4
6
8
10
Responses
YES
NO
Don't Know
0
2
4
6
8
10
12
Responses
YES
NO
Don't Know

get response from in this question and also show into form of bar chart.
12-Is standardized template is followed for SRS.
In this question we talk about the standard of template that SRS follows it is a short question so we
give better response then other questions. We give the choice of yes and no for selection. We get good
response against this question. Bar chart shows the response of organizations against options and over
this entire question.
13- How you include testability aspect in requirement specification?
In this question we discuss the testability aspect in requirement specification and how they include in
requirement specification we asked them. We give some choices those we get from literature review like
Mathematical model, Quantify and if they have another technique they can specify. We gather data and
0
1
2
3
4
5
6
7
8
Responses
Poorly structured
confusion and misinterpretation
Include ambiguities
dual meanings and lack context for
proper interpretation
varying levels of granularity across
system elements
Reflect an unstructured view of the
desired operation of the system
0
2
4
6
8
10
Responses
YES
NO
Don’t Know

get response from in this question and also show into form of bar chart.
14-Do you use different specification approaches for bespoke and MDRE (Market Driven Requirement
Engineering)?
In this question we ask about the specification approaches for bespoke and market driven requirement
engineering and the organization use different approaches for both or not or they don’t know about that.
We get good response against this question. Bar chart shows the response of organizations against
options and over this entire question.
15-What level of Expressiveness which your method/technique provided?
In this question we ask about the level of expressiveness which method or technique provided that
used in your organization. We give different choices like highest, high, normal, low, very low, don’t
know. We gather data and get response from in this question and also show into form of bar chart.
16-Are any CASE Tools available to support the requirement specification?
0
2
4
6
8
10
Responses
Mathematical model
Quantify
Any Other
0
1
2
3
4
5
6
Responses
YES
NO
Don't Know
0
1
2
3
4
5
6
7
Responses
highest
high
normal
low
very low
don’t know

In this question we ask about case tools those are use in organization to support requirement
specification. We give choice yes, no and if yes then please specify with details. Bar chart shows the
response of organizations against options and over this entire question.
0
2
4
6
8
10
Responses
YES
NO
Don't Know

Conclusion
In industry there are different approaches used for requirement specification. These are Requirements
specification using natural language, Mathematical Symbols and formulation, Excel sheets, Use case
analysis, Quality Attribute Workshop (QAW), O’Brien’s approach. From all these the Requirements
specification in natural language, use cases and excel sheets. These approaches have the problem of
ambiguity e.g. traceability issues and pictorial representation of only functional properties in
specification. There should be combinations of approaches in use so that it can cover all aspects of
requirements
Other important factor that should be under consideration is the reason for adopting a specific technique.
We found that there are lots of responses for organization SOP, Success stories and understandability for
all stakeholders. It shows that there is less budget allocation for using a new specification methodology
for a project. Moreover there is level of fear involve at management level that kept them away from
taking risk which can linger deadlines. Solution is better planning that can help in forecasting for project
in terms of time and budget.
Organization culture plays a vital role in bringing any change in strategy, planning or execution. In
survey it shows that lots of responses are in favor of argument that organizations allows in their culture
to adapt new methodology but again there must be very precise planning and forecasting before taking
any decision.
Different Specification methodologies have different representations some can produce a big document
and some can depict concept in few images. In our survey we found that there are issues for
understandability for stakeholders and requirements traceability by using mentioned methodologies.
These can be eliminated by using combination of different techniques. Mostly organizations prefer their
previous experience to adopt a methodology for specifications. They can derive requirement
prioritization by using these techniques also they are enabling to extract architectural significant
requirements from specification document. Issues those can be arisen are level of granularity achieved
by specification document made by commonly used methodology and with this ambiguities,
inaccuracies, inconsistencies confusions and misinterpretations.
Concluding above, what can be derived is that in local industry there are lots of organizations those are
relaying on natural language excel sheets and use cases methodologies for specifications. What they are
facing is ambiguities, inconsistencies, and expressiveness for non-functional attributes. Organization’s
culture is also supportive in technology adaptation. They are getting good results although they have
problem with these methodologies. What we have found that the project on which most of the
organizations are working are not as longer so that there is not a requirement of top of the line
specification technique. Tools in use are MS VISIO,MS Office and SRS Builder.

Future Work
This research is mainly based on Pakistani market where there are SMEs. For future work what we
suggest is to globalize this research and then compare results. It will give clearer picture that what are
top of the line methodologies using in big projects by large multi geo existing organizations.
References
[1] Common Requirements Problems, Their Negative Consequences, and the Industry Best Practices to
Solve Them.
[2] Requirements Engineering: A Roadmap.
[3] Model-Driven User Requirements Specification using SysML.
[4] Technology Transfer Issues for Formal Methods of Software Specification.
[5] The Approach for User Requirements Specification.
[6] Higher Quality Requirements Specifications through Natural Language Patterns.
[7] Problems and Deficiencies of UML as a Requirements Specification Language.
[8] Viewpoints: principles, problems and a practical approach to requirements engineering.
[9] Problems and Deficiencies of UML as a Requirements Specification Language.
[10] USTM: a new approach to requirements specification.

Research paperV1

Recommended

Recommended

More Related Content

What's hot

What's hot (18)

Viewers also liked

Viewers also liked (7)

Similar to Research paperV1

Similar to Research paperV1 (20)

Research paperV1