ASSUMPTION MANAGEMENT SYSTEM A Project Presented to the ...

ASSUMPTION MANAGEMENT SYSTEM
A Project
Presented to the faculty of the Department of Computer Science
California State University, Sacramento
Submitted in partial satisfaction of
the requirements for the degree of
MASTER OF SCIENCE
in
Software Engineering
by
Ayush Chadha
FALL
2012

© 2012
Ayush Chadha
ALL RIGHTS RESERVED
ii

Approved by:
ASSUMPTION MANAGEMENT SYSTEM
A Project
by
Ayush Chadha
__________________________________, Committee Chair
Ahmed Salem, Ph.D.
__________________________________, Second Reader
Bob Buckley, MS.
_________________________
Date
iii

Student: Ayush Chadha
I certify that this student has met the requirements for format contained in the
University format manual, and that this Project is suitable for shelving in the
Library and credit is to be awarded for the Project.
, Graduate Coordinator
Nik Faroughi, Ph.D Date
Department of Computer Science
iv

Abstract
of
ASSUMPTION MANAGEMENT SYSTEM
by
Ayush Chadha
Capturing and documenting quality software requirements is a major challenging task in
the software development lifecycle. Requirements typically are misunderstood and
misinterpreted by the various stakeholders and often contain hidden assumptions.
These “hidden assumptions” can be very costly to detect and correct and may lead to
serious software failures. The aim of this project is to design an Assumption Management
System which will facilitate a process of detecting hidden assumptions within software
requirements.
The system is divided into three components:
1. A Risk Management Framework which provides a comprehensive approach to
design the proposed system.
v

2. A methodology which consists of a Fishbone and Tag Management techniques,
when applied to the Risk Management Framework, helps in detecting the hidden
assumptions within the software requirements.
3. A Web based tool to help engineers detect hidden assumptions within software
systems.
Ahmed Salem, PhD
Date
, Committee Chair
vi

DEDICATION
I would like to dedicate my project to my family members, especially to my brother
Ankur without the support of whom I would not have reached this level. I really
thank them for all their support.
vii

ACKNOWLEDGEMENTS
I would like to extend my gratitude to my project advisor Dr. Ahmed Salem for
guiding me throughout this project and helping me complete this project successfully.
I would also like to thank Nancy Talamantes of the FTB Corporation and Bob Guzik
of Amdocs Corporation and Dale Fletter for their valuable inputs and guidance.
In addition, I would like to thank The Department of Computer Science at California
State University for extending this opportunity for me to pursue this program and
guiding me all the way to become a successful student.
Finally, to all my wonderful friends who helped me during course of this project and
master’s program. Special thanks to my friends Sarjit and my roommate Avinash who
stood by me in hard times and made sure this project is completed successfully.
viii

TABLE OF CONTENTS
ix
Page
Dedication……………………………………………………………………………......vii
Acknowledgements…………………………..………….………………………………viii
List of Tables……………………………………..……………………………………...xii
List of Figures………………………………….……..……………………………........xiii
Chapter
1. INTRODUCTION ……………...…..………………………………..……………......1
2. BACKGROUND…………………………………….………………...……………....4
2.1. Proposed Solution Assumptions..………………………………………………...10
3. METHODOLOGY……………………………………….……………...………........11
3.1. Cause and Effect Method……………………………………………...................11
3.2. Risk Management Methodology…………………...…………...……...…….…..13
3.2.1. Understanding the Business Context……………………….…....……...14
3.2.2 .Identifying Business and Technical Risks……………............................15
3.2.3. Synthesize and Prioritize the Risks……………………….......................16
3.2.4. Define Risk Mitigation Strategy………………………………...……....16

3.2.5. Execute Process and Validate the Results………………………..….......17
.
3.3. Assumption Management by Tag Detection…………………..............................17
4. PROPOSED SOLUTION ……………………….…….….…….....…………..…......19
4.1. Solution Details….………………………………………………..……………...21
4.2. Solution Strengths and Benefits.……………………………..…………..…........28
4.3. Solution Constraints…………………………………………...………..………..29
5. TAG DETECTOR SYSTEM…………….…………….………….….….....……........30
5.1. Tag Detector Requirements………………………………….…...........................30
.
5.1.1. User Management Requirements……………..........................................30
5.1.2. Tag Management Requirements…………...............................................32
5.1.3. NFR Management Requirement……………...........................................32
5.1.4. Assumption Management Requirements…….……….............................32
5.1.5. Tag Detector Assumptions…………….……………......…….………...33
5.1.6. Other Information………………………….…………….…...................33
5.2. Use Cases…………………………………….…….…………....…....................34
5.2.1. User Management Use Case…………………………...…....................34
.
5.2.2. Tag Management Use Case……………………..………......................35
5.2.3. NFR Management Use Case………………………………..................36
x

5.3. Data Flow Diagram…………………………………..................……...............37
5.4. Database Structure………………………………......…………………............38
5.5. Architecture of the Tag Detector………….…..……….....................................39
5.6. Tag Detector Screens…………………………….….…..……..........................40
5.6.1. User Management Screen…………….......…...……………..................40
5.6.2. Tag Management Screen……………………….....……....…….….…..43
5.6.3. NFR Management Screen………………….......……….……………...45
5.6.4. Assumption Management System…………………………….…….....48
5.7. Tag Detector Strengths and Weaknesses...…….…….….…………...…………50
6. CONCLUSION………………...……….…...…………..…..…….….….……..….....51
6.1. Conclusion……………………………………………………………………….51
6.2. Future Work……………………………………………………….…....……….51
Appendix A.……………………………..………………….………..………….….……….52
Appendix B……………………………………………………….…...……………....….....54
Appendix C…………………………..…………………………………....………………...59
References……………………………...………...…………………...……….....….….……61
xi

LIST OF TABLES
Tables Page
1. Representation of Different Set of NFR’s with the Words Attached…..………............18
2. Action Words With the Conjugates……………………………….....…………………18
xii

LIST OF FIGURES
Figures Page
1. Simple Framework for a Single Project……...…...……………..……...….......9
2. Creating the Cause and Effect Diagram..……………………….…….............12
3. Creating the Cause and Effect Diagram for Assumption……………..............12
4. The BSI Risk Management Framework………..……………..........................14
5. Four Stages of Solution …………………..……..………….………...............19
6. Solution Diagram………….……………………...……..…………................20
7. Cause and Effect Analysis of the Quantum of Data in Excel...........................25
8. Cause and Effect Analysis of the Requirements 2, 3 and 4…...……..…….....27
9. Use Case Diagram for the User Management Module….……...…….............34
10. Use Case Diagram for the Tag Management Module..……............................35
11. Use Case Diagram for the NFR Management Module...……….………........36
12. Data Flow Diagram……………………………………….………….............37
13. Database Structure for Tag Detector……………………...…….….……..…38
14. Architecture of Tag Detector…..……………………….…………...….........39
15. Register User Screen…………….…………………………………....….…..40
16. Forget Password Screen..……………………………………………....…….40
17. Change Password Screen……..………………………………….…….…….41
18. Login Screen………………..……………………………………….……….41
xiii

19. User Management Screen…...…………………………………………….....42
20. Edit User Screen……………..………………………………………….….. 42
21. Tag Management Screen…….……………………………………………….43
22. Add Tag Screen………………………………………………………………44
23. Edit Tag Screen….……..………………..…………………...…………....…44
24. Delete Tag Screen……………….………………...………………...……….45
25. NFR Management Screen..……….….……………...……………………….46
26. Add NFR Screen….…………..…………………………….…………..……46
27. Edit NFR Screen…….…..………………………………….………...............47
28. Delete NFR Screen……………..………..…………………..…….……........47
29. No Requirement Uploaded Screen………….……………………...…..…….48
30. Requirement Uploaded Screen……...………………….………....…..….......49
31. Assumption Management Screen..……..……………….………….…….......50
xiv

CHAPTER 1
INTRODUCTION
As the businesses across the world become more and more complex, the needs for
sophisticated software, which can handle complex scenarios, are increasing rapidly.
This has led to an ever-increasing demand for better software development
approaches, which are robust enough to handle the complex and dynamic
requirements [1]. Consequently, the software must be developed and integrated faster
than ever by bringing together diverse and distributed components, which are owned
and built by multiple teams. The challenges lie in creating those components or
services in such a manner that they can interact seamlessly and are scalable in nature.
Poorly managed software leads to an increasingly bloated project timelines and blown
IT budgets that in turn lead to exploding manual costs, high failure probability among
others. The success of the software hinges primarily on how well the software
addresses the needs of the marketplace. Software requirements must drive the design
and development decisions throughout the product development lifecycle and a
thorough product testing must be done against the specified requirements to make
sure we are not just delivering software that works, but also the software that we set
out to build. This calls for a well-defined requirement engineering process that
enables to manage the requirements throughout the entire product lifecycle.
Requirements engineering is a systems and software engineering process, which
covers all of the activities involved in discovering, documenting and maintaining a set
of requirements for a computer-based system [2]. While there are differing definitions
of the term, common factors are that requirements engineering is a sub discipline of
1

system and software engineering and is concerned with establishing the goals,
functions and constraints of hardware and software system [2].
Software requirements, both functional and non-functional, contain assumptions,
which if not managed successfully, intrude and impose themselves between design
and deployment of a system and can lead to serious software failures in the later part
of development life cycle. An assumption in literal terms is defined as, “the act of
taking for granted, or supposing a thing without proof; supposition; unwarrantable
claim” [3]. There can be many reasons for having assumptions; lack of knowledge
domain , poor communication , ambiguous requirements , lack of domain expertise
and too much expertise are only a few of them. Assumptions can lead to
inconsistencies and incompatibilities, which can cause failure and other post
deployment problems. Furthermore, individual assumptions may become invalid
because of changes in the environment in which the system is to be deployed.
To address this problem, the following elements are necessary:
1. A method to identify assumptions, even those that are “hidden”.
2. An approach to record identified assumptions in a “real-time” manner that is
not disruptive to the developer.
3. A mechanism to validate the identified assumptions by the people that possess
the knowledge to declare each assumption valid or invalid.
4. A tool to search for recorded assumptions by other developers and people
involved in the development effort.
2

Assumption management system presents an approach that helps the user to detect the
hidden assumptions inside the software requirements in very early stages of Software
development life cycle [3]. The system uses a series of approaches to drill down
hidden assumptions inside the software requirements. It includes the Cause and effect
approach or more famously called as the fishbone technology, Risk mitigation
strategy along with tag detection methodology to drill down deep into the requirement
and reveal the hidden assumptions [4].
3

CHAPTER 2
BACKGROUND
Every software requirement, be it be in form of project plan, task list or user story
always contains certain hidden assumptions inside them. As stated previously also, an
assumption usually occurs when the software teams presume something for granted
that it is true. Some assumptions are obvious but some are obscure. An assumption
differs from the risk in a way that risk may be considered the adverse effect of the
assumption, which we usually believe, is unlikely to occur.
The hidden assumptions inside the software requirements and their impact is
something that is been a well-known problem in the software domains for years. We
all make a variety of assumptions when making plans and commitments. Usually,
those assumptions prove to be correct but not always [5]. In addition, the more
assumptions the team makes, the greater the likelihood that something will not go as
planned. (A risk event will be realized).One reason why so many development
projects take longer than planned is simply because one or more assumptions proves
wrong and the team has to scramble to address the issues they were not aware of. For
that reason, it is a good idea to take a moment to think through the development
team’s assumptions.
To understand it more clearly let us take some examples of the hidden assumptions
inside the software system [3].
1. The team will remain intact for the duration of the project.
2. Computer systems and data will be available to the team when needed.
4

3. Development tools and technology infrastructure will be adequate to support
the project.
4. People outside the core team will be available when needed.
5. Outside parties (e.g. vendors, suppliers, business partners, etc.) will deliver as
promised.
6. User stories have been properly scoped and estimated.
7. Task lists are thorough.
8. The definition-of-done covers the needs of every story.
9. Any team member will be able to select any story and complete it.
10. Team members have adequate knowledge and training to complete the project.
The stated assumptions though obvious can be really risky and dangerous for the
project. For instance, the assumption that the team will remain intact for the duration
of the project. The reason we make that assumption is that they have over the period
been intact for most of the time. However, any aberration from the stated normal
behavior can lead to fatal consequences, which can become a risk to the project. If
some people in team are displaced or leave the project, this can lead to problems like
resource shortage and re-estimation, which can delay the project considerably.
The impact of hidden assumptions can be quite severe in the field of testing too. Linda
Hayes analyzes the very structure in which most of the automated batch testing
techniques works and how dangerous it can be if there are any hidden assumptions in
the process [6] [3]. The way batch testing works is it simply automates the captured
production data and uses it as baseline to compare the results against it. It may be easy
for describing a lot of functionality in the shorthand but unfortunately, it also means
5

that an error introduced in the baseline can actually go undetected for a long period
and can cause a lot of damage. This can be a common scenario presuming if the
system is working in production for a long period then any documentation for the
system becomes long out of date and it is hard to tell if anything is going wrong in the
system until someone really digs deep into it.
A real time classical example of the impact of the hidden assumption can be taken
from a firm called Home Side Lending; a New Jersey mortgage broker company
acquired by the Australia bank was under pricing mortgages for long period due to a
computer error in which the wrong interest rate was used [3] [6]. The eventual
outcome was a loss of $4 billion to the bank and the bank almost went bankrupted
because of that. Aside from the damage in cost, it is amazing how long the error went
undetected. Mortgage pricing is essential to Home Side’s core business and alleged to
be their special competency. How it happened is a mystery but obviously someone,
somewhere, and at some time decided the software was correctly pricing mortgages
when it was not. No one questioned it until the Australian banking authority audited
the software and found it to be working incorrectly for many years.
As more and more sober stories of impact of hidden assumption keep coming up
there is more than ever need to come up with techniques to find the hidden
assumptions in the early phase of the project. Assumption management system tries to
make a shot at that by suggesting a consolidated approach for finding the hidden
assumptions inside the software requirements. Hidden assumptions uncover further
foreseen problems inside the project. Once detected the discovered assumptions must
be dealt with otherwise they can derail the functioning of the project.
6

As per many studies, it has been found that no matter what approach we use it is
almost impossible to find all the hidden assumptions inside the software requirement.
To mitigate it some says the best thing to do is to do a proof of concept approach to
project. While even this does not guarantee all round elimination but it will help ferret
out a sizable fraction.
The repercussions of a system going into production with hidden assumptions can be
immense. They may not be exposed for years but the potential is always there. By
definition, we will not be aware of it until the problem occurs. The best effective way
is to find the hidden assumptions during the requirements/design phase of the
software development. At each interaction, understand why and how the data will be
used. How the data will get from point A to Point B. As data moves from tier to tier
(database to middleware to web server to presentation) what assumptions are carried
out at each tier
From the Project Management software side, the system is always viewed in through
three different levels. i.e.: Technology, Business and Behavior. Unfortunately,
software assumptions are found in all the three areas. In terms of behavioral side, the
assumptions creep up because all the stakeholders think they are all thinking the same
thing. They all think they know the best and they know the customer’s intentions well.
Which is not true in most of the cases? As per technology the reason why our
assumptions are more prevalent in software is lack of engineered “blue print” type
design or details. Poor communications in a communication centric world or if the
customer requirements are intangible, difficult to define and verbalize. In addition,
fast-paced business does not allow for design freeze. Some typical assumptions here
7

are technology can solve our key problems, People are interchangeable and its
technology that is important. Also assuming that the estimates are accurate enough.
From business point of view some typical assumptions are there is always a funding
available from somewhere, we know what’s/who is driving our project. The ‘paying’
customer is happy among others. Assumptions affect all aspects of project planning
and are part of progressive elaboration of the project.
Many experts of software engineering have tried to study this problem and have come
up with many theories, which aim at suggesting the negative impact of the hidden
assumptions and how critical it is to detect them at the earliest. Though most of the
work done in this area aims mainly at highlighting the impact of the hidden
assumptions inside the project but not much research has been done in defining some
definite set of techniques that aim to find the hidden assumptions inside the project .
Andy Steingruebl and Gunnar Peterson for instance take a shot at creating a
methodology for revealing hidden assumptions by coming up with better approach for
discovering and documenting them. They classify the hidden assumptions into three
categories of design time, run time and implementation time and come up with
techniques for how to apply different techniques for different types of the assumptions
and what can be done to eliminate the same [7]. GA Lewis comes up with
Assumption management software that stores the assumptions in a repository and
integrates it with the project management and system administration modules to
reveal the hidden assumptions [8].
8

Our approach aims to present an approach for finding out hidden assumptions inside
the project during the early life cycle of the project. All the technical and business
stakeholders to uncover “hidden assumptions” in early phase of the project should use
the underlying approach / methodology easily. . This will help avoid the problems
that are discovered later in the development life cycle when they become more
expensive. This new methodology will need to provide a vehicle to encourage
stakeholders to think about and vocalize assumptions, even obvious ones, early in the
analysis phase of product development.
Close
Execute
Control
Many Possible Assumptions
Figure 1 - Simple Framework for a Single Project [5].
Initiate
Plan
9

2.1 Proposed Solution Assumptions
The proposed approach has the following underlying assumptions:
1. All the stakeholders are involved in the requirement gathering process.
2. All concerned parties have in-depth expertise of domain and their respective
vertical.
3. Abidance to the solution especially in the early stages of the process.
4. Improving the quality involves taking action on the root causes of the
problem.
5. There always are hidden assumptions.
10

CHAPTER 3
METHODOLOGY
The project solves the problem of the hidden assumption with the help of three main
techniques i.e. Cause and effect or fishbone technology, risk management technique
and the tag detection method. The description of three is as follows:
3.1 Cause and Effect Method
Cause and effect analysis methodology is a method, which was developed by
Japanese professor Kaoru Ishikawa, a pioneer of quality management. The process
includes creating a cause and effect diagram, which is also called as the fishbone
diagram. Originally developed as a quality control tool this technique however can be
applied to a range of other areas. As an example, it can be used to discover the root
cause of the problem, uncover bottlenecks in the processes and identify where and
why a process is not working properly [9].
Cause and effect analysis provides a structured way to think through all possible
causes of a problem. This helps carry out a thorough analysis of a situation and uses
an idea-generating technique to identify the factors within each category that may be
affecting the problem / issue and/or effect being studied. For those items identified as
the “Most likely causes”, the team should be able to reach a consensus on listing those
items in priority order with the first item being the most probable cause.
Application of cause and effect method in the detection of the hidden assumptions
inside the software requirement can be effective. The root cause of assumptions is the
way in which the requirements are drafted. A short and ambiguous statement of
11

software requirement may contain many assumptions, which can be costly especially
in the later stages of the software development life cycle. Cause and effect helps
decipher those assumptions at a very early stage by revealing all possible risks that
may be involved with that requirement.
To illustrate it let us consider an example of how we will create a fishbone diagram
for a problem-hidden assumption for instance.
Step 1: The Developer starts with the effect to be investigated (hidden assumption)
and draws a backbone arrow to it.
Hidden
Assumptions
Figure 2 - Creating the Cause and Effect Diagram
Step 2: We identify all the broad areas of inquiry in which the cause and effect being
investigated may lie. For hidden assumptions, the diagram may then become (see Fig.
2).
Step 3: In this step, we dig down deep into each area of inquiry and see what can
cause that to happen. The result will be representation of all factors related to the
effect being explored and the relationships between them.
12

Faulty functional requirements
Arrogance of experts
Lack of domain competence
Faulty NFRs Trying new Methodology
Time Shortage
13
Lack of knowledge
Ambiguou
s
Requirem
ents
Assumptions
Communication Gap
Figure 3 - Creating the Cause and Effect Diagram for Assumptions.
3.2 Risk Management methodology
Risk analysis is often viewed as a black art. Successful risk analysis is however
nothing more than a business level decision support tool. It is a way of gathering the
requisite data to make a good judgment call based on knowledge about vulnerabilities,
threats, impacts and probability.
Risk management approach helps to assess risk, manage cost and control quality of
software and data from vendor; measure effectiveness of people, processes and
supporting frameworks in the software supply chain; and helps to find and govern the
risk to us, our business and our organization [4].

Now for the question how this risk management strategy does helps in finding out the
hidden assumptions. When we talk about the assumptions, finding them alone does
not add value to the process unless we attach risk to them and rank them accordingly.
Risk management framework gives us the power to do that.
The Risk management framework consists of five fundamental activity stages as
shown in Figure 4 [4].
Figure 4 - The BSI Risk Management Framework [4]
3.2.1. Understand the Business Context
Software risk management occurs in a business context. Risks are often unavoidable
and are integral part of the software development process. This stage of the process
focuses on handling the business situation. Commonly, business goals are neither
obvious nor explicitly stated. In some cases, we may even have difficulty expressing
these goals clearly and consistently. During this stage the analyst must extract the
business goals, priorities and circumstances in order to understand what kind of risks
14

to care about and which business goals are paramount. Business goals include
increasing revenue, meeting service level agreements. Reducing development costs
and generating high return on investment.
3.2.2 Identify Business and Technical Risks
Business risks are a danger to the business goals. The identification of such risks
helps to clarify and measure the impact those will have on the business goals.
Business risks may have impacts that include direct financial loss, damage to brand or
reputation, violation of customer or regulatory constraints, exposure to liability and
increase of the development costs. The severity of a business risk should be expressed
in terms of financial or project management metrics. These include but are not limited
to market share, direct cost, and level of productivity and cost of rework.
Business risk identification helps to define and steer use of particular technical
methods for extracting, measuring, and mitigating software risk given various
software artefacts. The identification of business risks provides a necessary
foundation that allows software risk (especially impact) to be quantified and described
in business terms. The key to making risk management work for business lies in tying
technical risks to business context in a meaningful way. The ability to identify and
deeply understand risks is thus essential. Uncovering and recognizing technical risks
is a high-expertise undertaking that usually requires years of experience.
Central to this stage of the Risk Management Framework lays the ability to discover
and describe technical risks and map them (through business risks) to business goals.
A technical risk is a situation that runs counter to the planned design or
15

implementation of the system under consideration. For example, a technical risk may
give rise to the system behaving in an unexpected way, violating its own design
strictures, or failing to perform as required. Technical risks can also be related to the
process of building software. The process an organization follows may offer too many
opportunities for mistakes in design or implementation. Technical risks involve
impacts such as unexpected system crashes, avoidance of controls (audit or
otherwise), unauthorized data modification or disclosure, and needless rework of
artefacts during development.
3.2.3 Synthesize and Prioritize the Risks
This stage involves synthesizing all the risks identified in the stage 2 and prioritizing
them as to which of them can really affect the business goals the most. Clearly, the
prioritization process should take into effect which of the goals of firm is the most
important ones. According to the priority, all the risks identified should be ranked in
order of the most critical to the least ones.
3.2.4 Define Risk Mitigation Strategy
Stage 3 gives the information of all the risks that are associated in order of their
criticality. This stage aims to mitigate those risks by clearly defining the strategies to
weep out the risks. Typical metrics includes likelihood, risk impact, risk severity and
number of risks emerging and mitigated over the period.
16

3.2.5 Execute Process and Validate the Results.
Once a plan is set, it is the time to execute them. This stage does that. Risk mitigation
should be carried out in accordance to the plan that has been set in the earlier stage.
This stage also involves application of those validation techniques previously
identified. The validation stage provides some confidence that risks have been
properly mitigated through artifact improvement and that the risk mitigation strategy
is working. Testing can be used to demonstrate and measure the effectiveness of risk
mitigation activities. The central concern at this stage is to validate those software
artifacts and processes no longer bear unacceptable risks. This stage should define and
leave in place a repeatable, measurable, verifiable validation process that can be run
from time to time to continually verify artifact quality. Typical metrics employed
during this stage include artifact quality metrics as well as levels of risk mitigation
effectiveness.
3.3 Assumption Management by Tag Detection.
It has been found that the set of non-functional requirements that contains a certain set
of words or tags are more susceptible to have hidden assumptions inside them as
compared to the ones that do not have them. The tag detection technique aims at
parsing the software requirements and aiming to find those words or tags inside them.
A quick parse can tell which parts of the requirements can be faulty and needs further
assessment.
17

Table 1 displays the different set of NFRs and the commonly used tags attached to it.
Table 2 displays the keyword and its conjugate both of which can be source of hidden
assumptions.
Table 1 - Representation of the Set of NFRs and the Words.
Functionality Usability Reliability Efficiency Maintainability Portability
system system system system system installation
external software resource scaling resource system
resource data data software software installed
data allow software
unnecessary
Log software
available configuration gracefully limits Error patch
resources provide behave workload change upgrade
consumers user
application
extended configuration likelihood
application valid failure time procedures mismatches
restarted affecting event application processes between
processing users error tier Data configurations
procedures profile time distribution information patches
Table 2 - Action Words with the Conjugate.
Keyword Conjugate
Can Can not
Must Must not
Shall Shall not
Should Should Not
Will Will not
18

CHAPTER 4
PROPOSED SOLUTION
The proposed solution to solve the problem of hidden assumption makes use of the
three methodologies discussed in the chapter four. How they are combined together
and how the combination helps in solving the hidden assumption problem is
something we will discuss in this chapter. The combined approach takes a shot at
finding the hidden assumptions that too at the early phases of the SDLC [2].
This is how it works. First we apply the RMF framework process that we discussed in
chapter 3 and amalgamate the 2 other methodologies in the risk identification and
mitigation stage of the process [4].
Assuming the stakeholders understand the Business Context well. The solution
involves 4 steps: -
STAGE 1
Identify the Technical / Business risks involved with the requirements.
STAGE 2
Prioritize the risks involved.
STAGE 3
Define the risk mitigation strategy.
STAGE 4
Problem solving and requirement validation.
Figure 5 - Four Stages of Solution.
19

Functionality Usability
system system
external software
resource data
data allow
available configuration
resources provide
consumers user
1. Tag Detection Method 2.Fishbone Diagram
Figure 6 – Solution Diagram: The diagram explains the approach the system uses for
the hidden assumption removal. It is an extension to the traditional RMF discussed in
chapter four. Here the processes of risk identification and risk mitigation are extended
with the tag detection and fishbone diagram approach respectively. The tag detection
method helps in revealing more risks inside the requirements and the fishbone
methodology helps in enhancing the mitigation process of the requirements [4].
20

In order to understand how our approach works let us apply this on real time
requirements and see how this works. The following is the example of the real time
project used as a test sample to be applied to our solution.
4.1 Solution Details
To see how our solution works let us consider a sample project and try to apply our
solution to it.
Sample Project Statement:
Our organization relies heavily on the support of our community through volunteer
work. We have many volunteers who teach our classes, mentor our clients, and assist
with fundraising and events. Our volunteer base is about 300 volunteers, who work
weekly, monthly, or annually. We need a system to be able to input volunteer’s
contact information/employer information and track hours that volunteers work. The
system should provide a way to calendar the volunteers into a staff/office calendar
system. Our staff should be able to view and make changes to a certain extent, but the
Volunteer Coordinator would have ultimate editing/changing abilities. The system
should allow users to export the data into an excel file so it can be imputed into
another database we use for donors.
Sample Project Organization Computer Environment:
The organization has a server/shared drive that each staff member can access. The
staff is not all that computer savvy so the program/database would have to be very
user friendly, at least for those just accessing the information.
21

Sample Project Aim:
Develop a system to manage and track office volunteer information and transactions.
Functional and nonfunctional requirements:
The system should/Shall allow:
1. Ability to export data to MS Excel.
2. Allocate volunteer interest (volunteer is interested in special events, teaching a
class, childcare, sorting clothes, etc.).
3. Allocate volunteer “area of service” (example: teacher, mentor, special events,
childcare certified, etc.)
4. Notify staff of volunteer birthday.
5. Email volunteers a reminder they will be teaching (date and time as imputed in
the database).
6. Email volunteers of upcoming volunteer opportunities specified by staff.
7. Interact with a client database (not yet created) so we can assign volunteer
mentors to clients).
8. Calculate volunteer hours.
9. Needs to run on website for universal access.
10. Can run on any operating system.
11. Software must be reliable and not crash.
Applying Our Approach to the Sample Problem Described Above:
Applying STAGE 1 of our approach to the set of requirements
22

To start with, let us analyze the requirements and try to find out which requirements
can have technical and business risks involved.
Requirement 1: Ability to export the data in MS excel.
1. Analysis: The requirement is not very clear as it does not point out what all
fields of the data are to be captured in the Excel –Sheet.
2. Tag Found: Looking at table 7 we found that the requirement has a tag data
associated with it. Data is a generic word and unless specified very clearly can
lead to possible hidden assumption.
3. Risks involved: A major risk involved here could be the quantum of data that
goes into the excel sheet.
Requirement 2: Notify staff of volunteer birthday.
1. Analysis: The requirement is not very concise, what kind of notification is to
be send (email, sms, pop up).
2. Tag Found: Looking at table 7 we found that the requirement has a tag notify
associated with it. If the word ‘notify’ is not used in the conjunction with the
notification type than it can lead to hidden assumptions.
3. Risks involved: What If the volunteer declines to mention his/her birthday. In
addition, different notifications can have different technical and business
repercussions.
23

Requirement 3 : Allocate volunteers on a special date of service.
1. Analysis : The line special date of service needs to be more elaborative and
explicit
2. Tag found : None
3. Risks involved: Although no tags found in this requirement but it still may
have a risk associated with it. What if volunteer is not available on that day or
the mail server goes down and application is not able to notify the Volunteer.
Requirement 4: Interact with a client database (not yet created) so we can assign
volunteer mentors to clients.
1. Analysis: No clear mention of how the volunteers will be assigned to the
clients.
2. Tag Found : None
3. Risk involved: How will we manage the volunteer sharing in case multiple
clients require the same volunteer.
Applying STAGE 2 of our approach to the set of risks identified in stage 1
In this stage we prioritize, the risks identify in stage 1. Considering the business goals
of the system, we rank them according to the most severe ones to the minor ones.
24

After analyzing the business goals, we come up with the following list of risks
according to priority.
1. Allocation of the resources
2. Quantum of data in the excel sheets.
3. Notification type to the volunteers.
4. Mail server down.
Applying STAGE 3 on the risk identified
Now after we identify the risks involved we go to the risk mitigation stage of the
RMF where we try to find out the mitigation strategies to solve the risks. Here we
would be applying the cause and effect fish bone methodology to dig more on what
can cause these risks to happen.
Requirement 1: Ability to export the data in MS Excel.
1. Risk identified: Quantum of data in excels.
2. Cause and Effect analysis :
Poor data normalization in the database
User selected all data with no filters
25
Quantum of data in excels.
Redundant data was not taken care.
Figure 7 - Cause and Effect Analysis of the Quantum of Data in Excel.

Possible Assumptions: The possible hidden assumptions for the risk after applying the
cause and effect analysis are:
1. While generating the report the user will use one of the filters for the report.
2. There will be unique data inserted in the database.
3. Database is robust enough to handle huge chunks of data.
4. Client has MS office installed on its machine.
The possible effect of the above causes can be quite serious.
1. It can lead to a buffer overflow error in case the number of records is more
than 65,000. This is because the Microsoft excel does not support more than
65,000 rows of data.
2. There could be some fields in the report that are not supported by the
Microsoft API; this can lead to introduction of corrupt data.
3. The reports will cease to work if the system does not find the Microsoft APIs
on the client.
Conclusion: Using our risk mitigation strategy we have successfully revealed that
if not catered properly the bulk of data in the excel sheet can lead to some serious
problems. Similarly, we can apply the cause and effect approach to other set of
requirements to dig into the real causes of the risks. Here are the cause and effect
analysis for other requirements.
26

Popup
Email
SMS
Natural Calamity.
Hardware Failure
Power outage.
Notification Type
Mail Server down
27
Resource for required technology not available
Resource is already allocated
Resource Allocation.
Figure 8 - Cause and Effect Analysis of the Requirements 2, 3 and 4.

Applying STAGE 4 to the risk mitigation strategy identified in stage 3
Let us take the first requirement and apply stage 4 on that.
We redraft our requirement into set of 4 requirements so that it does not have any
hidden assumptions.
1. The system should have the ability to export the data generated in the
volunteer Work hours screen into the MS excel sheet 2007.
2. If the number of records exported is more than 65000 records the first 65000
records should be inserted into the first sheet of the sheet and any other
records should be put into the other worksheet of the excel file.
3. Proper type checking should be done so that there is no data mismatch or
corrupted data in the sheet.
4. The client should have MS office 2007 installed on its system.
4.2 Solution Strengths and Benefits
1. Risk analysis is good general-purpose yardstick by which we can judge our
security design’s effectiveness. Because roughly 50% of our problems are the
result of requirement flaws, we perform our technique at the requirement
phase identify hidden assumptions as early possible.
2. By considering the resulting ranked risks, business stakeholders can determine
how to manage particular risks and what could be the most cost effective
controls.
28

3. The major factor that makes fishbone strategy successful is the increased
knowledge of the process, helping everyone to learn more about the factors at
work and how they relate to each other. It easily identifies areas for further
study where there is lack of sufficient information.
4.3 Solution Constraints
Thus we see through the examples that applying the 3 methodologies does yield
hidden assumptions which otherwise would have been hidden and could have caused
damage in the later stages of the SDLC.
However, the solution also has some constraints, which may restrict it to find all the
hidden assumptions. Some of them are:
1. The scope of the solution is limited to the three methodologies; Risk
management, Fish bone cause and effect and the tag detection methodology
[4] [9].
2. Risk analysis output is difficult to apply directly to modern software design
structures.
3. Solution does not provide an easy guide of all potential vulnerabilities and
threat to consider at a component/environment level. This is why a large
knowledge base and lots of experience is required.
4. The major constraint with the fishbone technique is it is inefficiency for
extremely complex problems, where many causes and many problems are
interrelated.
5. Fish bone diagrams does not clarify the sequence of the causes.
29

CHAPTER 5
TAG DETECTOR SYSTEM
Tag detector is a web-based tool made in ASP.net, which helps in detecting the
hidden assumptions inside the non-functional software requirement by using the tag
detection approach discussed in Chapter 4. The system scans all the requirements line
by line and tries to find the tags inside the requirements, which can cause the system
to fail. This section talks about the requirements of the system in detail, its design, its
constraints followed by the detailed description of the screens and the database
structure.
5.1 Tag Detector Requirements
The Tag Detector requirements are classified into three parts. User Management
Requirements, Tag Management Requirements and NFR Management Requirements.
This is followed by the requirements for the main
5.1.1 User Management Requirements
The following are the functional requirements of the Tag Detector, which a registered
user for the Tag Detector should be able to perform.
1. The system should allow the new user to register to the Tag Detector system in
case he/she has not been registered.
2. The system shall check the database for any existing entry in the database for
the same user.
30

3. The system should notify the user if the username already exists and should
ask them to opt for a different user name.
4. The system should make sure that the user enters all the required fields while
adding the user to the system.
5. The system should notify the user when the user is successfully registered into
the system.
6. The user should be able to login into the system with the registered user name
and password.
7. The system shall provide the forget password functionality to the user in case
the user forgets the password.
8. The system shall email the user the password on the basis of the username
entered.
9. The system shall provide the user the change password functionality to change
the password whenever they want.
10. The system should have the User Management screen for the admin users
where they can view all the usernames and their email ids for system
maintenance purpose.
11. The system shall allow the admin user to add, edit or delete the user from the
Tag Detector System.
31

5.1.2 Tag Management Requirements
The following are the functional requirements for the Tag Management module for
the Tag Detector tool.
1. The system shall allow the user to add more tags into the database based on
the non-functional requirement parameter selected.
2. The system shall check if the tag already exists in the database.
3. The system should notify the user in case the tag already exists in the
database.
4. The system shall allow the user to edit the existing tags in the database.
5. The system shall allow the user to delete the tags from the database.
5.1.3 NFR Management Requirements
The following are the functional requirements for the NFR Management module for
the Tag Detector tool.
1. The system shall allow the user to add more NFR into the database.
2. The system should notify the user in case the NFR already exists in the
database.
3. The system shall allow the user to edit the existing NFR in the database.
4. The system shall allow the user to delete the NFR from the database.
5.1.4 Assumption Management Requirements
1. The system shall allow the user to upload the requirements using the upload
document functionality.
32

2. The system shall display the requirements uploaded in the screen in the
following format :
1. Req ID.
2. Requirement.
3. The system shall perform the tag detection for one requirement per time.
4. The system shall allow the user to clear the requirements.
5. The system shall provide the dropdown for all the NFR in the system.
6. The system shall scan all the lines of the requirements and search for the tag
based on the NFR criterion selected in the dropdown.
7. The system shall summarize the findings on the screen in the following
format:
1. Req ID.
2. Requirement.
3. Faulty Word.
4. NFR Type.
5.1.5 Tag Detector Assumptions
1. The requirements for the analysis should be in the .xls template format.
2. Client has MS office installed on its system.
5.1.6 Other Information
Tag detector is built in ASP.net 4.0 with SQL Server 2008 as the database. The
system uses Telerik ASP.net AJAX suite for displaying the information in the grid
and is compatible in all the browsers.
33

5.2 Use Cases
5.2.1 User Management Use Case
Figure below shows the use case for the User Management module. There are 2 main
actors in the User management module i.e. Tag Detector user and Admin. The Admin
user has the access to all the users and can add/edit/delete any user from the system.
Individual Tag Detector user can register itself, login and can use the modules like
forget password and change password.
Figure 9 - Use Case Diagram for the User Management Module
34

5.2.2 Tag Management Use Case
The use case diagram for the Tag Management module consists of one actor and three
components. Actor comprises of the Tag Detector user and it has the ability to add a
tag to the system, edit the existing tag in the system and delete the tag from the
system.
Preconditions
The following pre-conditions must be true to initiate this Use Case.
1. User has logged into the System.
Figure 10 - Use Case Diagram for the Tag Management Module
35

5.2.3 NFR Management Use Case.
The use case diagram for NFR Management module consists of one actor and three
components. Actor comprises of the NFR Management user and it has the ability to
add, edit and delete the NFRs inside the system.
Preconditions
The following pre-conditions must be true to initiate this Use Case.
1. User has logged into the System.
Figure 11 - Use Case Diagram for the NFR Management Module
36

5.3 Data Flow Diagram
Figure 12 displays the data flow diagram between the different components of the Tag
Detector system and its attributes.
ID
Users
Name
NFR
NfrDescription
eMail
Password
NFR Type
Description
Req Mapping
nfrTypeID
NfrWord
Desc
Figure 12 - Data Flow Diagram for the Tag Detector.
RiskID
37

5.4 Database Structure
The Database is composed of three main tables namely NFRDescription table, Users
table and Reqmapping table. NFRDescription is the lookup table that consists of the
record of all the NFRs that is being used in the mapping. The Requirement mapping
table consists of the mapping of all the NFR types and the words associated with it.
Users table consists of the record of the users in the system along with their email IDs
and password.
Figure 13 - Database Structure for Tag Detector.
38

5.5 Architecture of the Tag Detector.
The Tag Detector systems architecture consists of two basic layer, the web pages and
the user controls composes the Presentation layer , the code behind page forms the
business logic layer which consists of all the logic which in turn interacts with the
SQL server database. ADO.net is used for the communication between the web pages
and the database.
Presentation Layer
ASP.net Webpages, User Controls and Telerik Grids.
Business Logic Layer
ASP.net Code behind
SQL Server
Figure 14 - Architecture of Tag Detector.
39

5.6 Tag Detector Screen
5.6.1 User Management Screens
1. Register User Screen.
The Add user screen allows the user to register into the Tag Detector system.
The go back button takes the user back to the login page.
2. Forget Password Screen.
Figure 15 - Register User Screen.
The Forget Password screen allows the user to retrieve the lost password
based on the correct username entered. The password is send to the user in the
email entered during the registration.
Figure 16 - Forget Password Screen.
40

3. Change Password Screen.
The change password screen allows the user to change his/her password. The
system prompts the user to re-enter the old password twice and notifies the
user in case the old password is incorrect.
4. Login Screen
Figure 17 - Change Password Screen.
The login screen allows the user to log in to the system if the credentials
entered are correct.
Figure 18 - Login Screen.
41

5. User Management Screen
The user management screen is used by the admin for adding, editing and
deleting any user from the Tag Detector system. (This is additional to the
register user discussed in 1)
Figure 19 - User Management Screen.
Figure 20 - Edit user Screen.
42

5.6.2 Tag Management Screen
1. Tag Management Grid (View)
The Tag Management Screen has all the tags displayed on the screen along
with the NFR type. We can view the different tags for the different NFR type
by selecting the different NFR type from the dropdown.
2. Tag Management Grid (Add View)
Figure 21 - Tag Management Screen.
On clicking the add Tag link in the grid the system opens the add view and
allows the user to add the new Tag.
43

3. Tag Management Grid (Edit View)
Figure 22 - Add Tag Screen.
On clicking the edit tag button from the grid, the grid opens in the edit mode.
On clicking the update tag button the tag description in the database is
updated. Cancel button cancels the operation and takes user back to the view
grid mode. (See figure below).
Figure 23 - Edit Tag Screen.
44

4. Tag Management Grid (Delete)
On clicking the red delete icon in the tag management grid, the system
prompts the user with the message that “Are you sure you want to delete this
tag”.
5.6.3 NFR Management Screen
1. NFR Management Grid (View)
Figure 24 - Delete Tag Screen.
The NFR Management Screen has all the NFR displayed on the screen along
with the NFR type ID.
45

2. NFR Management Grid (Add View)
Figure 25 - NFR Management Screen.
On clicking the add NFR link in the grid the system prompts the add view and
allows the user to add the new NFR. On clicking Add NFR, the new NFR is
added into the database.
Figure 26 - Add NFR Screen.
46

3. NFR Management Grid (Edit View)
On clicking the edit tag button from the grid, the grid opens in the edit mode.
On clicking the update tag button the NFR description in the database is
updated. Cancel button cancels the operation and takes user back to the view
grid mode. The system notifies the user that the NFR has been updated
successfully.
4. NFR Management Grid (Delete)
Figure 27 - Edit NFR Screen.
On clicking the red delete icon in the tag management grid, the system
prompts the user with the message that “Are you sure you want to delete this
tag”. On affirmation, the system deletes the tag from the database and cancels
it otherwise (See figure below).
47

5.6.4 Assumption Management Screen.
Figure 28 - Delete NFR Screen.
When no requirement is selected by the user than the system displays a
“No Requirement “found message. This screen is also displayed when the
requirements are cleared by clicking the clear requirement button.
Figure 29 - No Requirement Uploaded Screen.
48

When the user selects the requirement and clicks the upload requirement button.
The requirements are displayed in the grid with the Req ID and Requirement
description columns respectively.
Figure 30 - Requirement Uploaded Screen.
When user selects the NFR type from the NFR type dropdown. After selecting
and uploading the requirements when the user selects the NFR type from the
dropdown than the user scans the requirement word by word and tries to find a
match for the tag in the requirement for the NFR type selected in the
dropdown. At any point of time, the user believes that the tag for that NFR
49

type needs to be updated / added or deleted then he can go to the NFR
management module and can do the same.
5.7 Tag Detector Strengths and Weaknesses
Strength
Figure 31 - Assumption Management Screen.
1. Tag Detector system provides an intuitive way of risk and assumption
detection inside the requirements.
2. With configurable tag functionality, we can add / edit or delete any number of
tags inside the requirements.
3. By detecting the Tags at very early stages of the requirement we prevent the
project from risks which otherwise could have been detected at very later
stages of the project.
50

Weaknesses
1. The system uses the tags, which are stored and maintained based on the NFR
type, there is no intuitive way to apply this approach on the functional
requirements.
2. The tag detection if not followed by risk mitigation and risk validation can still
lead to assumptions inside the requirements.
51

6.1 Conclusion
CHAPTER 6
CONCLUSION
This project solution provides all together a new way of detecting the hidden
assumptions inside the software requirements by applying the fishbone methodology
and tag detection approach to the Risk Management Framework. If applied properly
the solution can be a great tool to detect some of the hidden assumptions inside the
requirements. The approach is complemented by the Tag Detector software, which
helps in detecting the faulty words inside the requirements with ease.
6.2 Future Work
There can be a lot of work that can be done further on this topic. Elaborative analysis of the
impact of tag detection on finding the assumptions in the requirements, a software tool
implementing the suggested new model for the risk management system, Analysis of the
impact of the new framework on the software failures are some of the areas where we can do
further research. A lot of future work can also been done on the Tag detector tool ,
associating risks , integrating the whole RMF and reporting are some of the areas where the
application can be further extended.
52

APPENDIX A
CODE SNIPPET: ASSUMPTIONMANAGEMENT.ASPX
53

54

APPENDIX B
CODE SNIPPET: ASSUMPTIONMANAGEMENT.CS
using System;
using System.Collections.Generic;
using System.Linq;
using System.Web;
using System.Web.UI;
using System.Web.UI.WebControls;
using System.Data.OleDb;
using System.Data;
using System.Configuration;
using System.Reflection;
using Excel = Microsoft.Office.Interop.Excel;
using System.Data.SqlClient;
using Telerik.Web.UI;
using System.IO;
public partial class Webpages_AssumptionManagement : System.Web.UI.Page
{
public class myTags
{
public string RequirementID { get; set; }
public string Requirement { get; set; }
public string FaultyWord { get; set; }
public string nfrType { get; set; }
}
public bool isRequirements { get; set; }
protected void Page_Load(object sender, EventArgs e)
{
if (!Page.IsPostBack)
{
populateNFRTypes();
}
}
protected void GridDataSource(object source, GridNeedDataSourceEventArgs e)
{
PopulateRequirements();
}
private void populateNFRTypes()
{
SqlConnection conn = new SqlConnection(@"Data Source=AYUSH-PC\SQLEXPRESS;Initial
Catalog=AssumptionManagement;Integrated Security=True");
SqlDataAdapter da = new SqlDataAdapter();
SqlCommand cmd = conn.CreateCommand();
cmd.CommandText = "Select nfrtypeID,nfrtypedescription from nfrDescription";
da.SelectCommand = cmd;
DataSet ds = new DataSet();
conn.Open();
da.Fill(ds);
conn.Close();
cboNFRTypes.Items.Clear();
cboNFRTypes.DataTextField = "nfrTypeDescription";
cboNFRTypes.DataValueField = "nfrTypeID";
cboNFRTypes.DataSource = ds.Tables[0];
cboNFRTypes.DataBind();
cboNFRTypes.Items.Insert(0, new RadComboBoxItem("- Select NFR Type -", string.Empty));
55

}
private void PopulateRequirements()
{
lblmessage.Text = "";
var file = Directory.GetFiles(Server.MapPath("~/Requirements"))
.FirstOrDefault();
if(file == null)
{
isRequirements = false;
lblmessage.Text = "No Requirements found.Please upload it to continue.";
}
else
{
isRequirements = true;
gridRequirements.DataSource = GetRequirements();//DataSource to GrigView(Id:gvOne)
}
}
private DataTable GetRequirements()
{
var file = Directory.GetFiles(Server.MapPath("~/Requirements"))
.FirstOrDefault();
Excel.Application appExl;
Excel.Workbook workbook;
Excel.Worksheet NwSheet;
Excel.Range ShtRange;
appExl = new Excel.ApplicationClass();
workbook = appExl.Workbooks.Open(file, Missing.Value, Missing.Value, Missing.Value, Missing.Value, Missing.Value,
Missing.Value, Missing.Value, Missing.Value, Missing.Value, Missing.Value, Missing.Value, Missing.Value, Missing.Value,
Missing.Value);
NwSheet = (Excel.Worksheet)workbook.Sheets.get_Item(1);
int Cnum = 0;
int Rnum = 0;
ShtRange = NwSheet.UsedRange; //gives the used cells in sheet
//Reading Excel file.
//Creating datatable to read the containt of the Sheet in File.
DataTable dt = new DataTable();
dt.Columns.Add("ID");
dt.Columns.Add("Requirement");
for (Rnum = 1; Rnum

\
protected void cmdUpload_Click(object sender, EventArgs e)
{
var fileExists = Directory.GetFiles(Server.MapPath("~/Requirements"))
.FirstOrDefault();
RadUpload RadUpload1 = uploadRequirement;
UploadedFile file = RadUpload1.UploadedFiles[0];
if (fileExists == null)
{
string targetFolder = Server.MapPath(RadUpload1.TargetFolder);
string targetFileName = System.IO.Path.Combine(targetFolder,
file.GetNameWithoutExtension() + file.GetExtension());
file.SaveAs(targetFileName);
}
else
{
System.IO.DirectoryInfo downloadedMessageInfo = new DirectoryInfo(Server.MapPath("~/Requirements"))
foreach (FileInfo files in downloadedMessageInfo.GetFiles())
{
files.Delete();
}
string targetFolder = Server.MapPath(RadUpload1.TargetFolder);
string targetFileName = System.IO.Path.Combine(targetFolder,
file.GetNameWithoutExtension() + file.GetExtension());
file.SaveAs(targetFileName);
gridRequirements.Rebind();
}
}
private void findTagsForHiddenAssumptions(DataTable dtRequirements)
{
if (cboNFRTypes.SelectedItem.Value != string.Empty)
{
gridRequirements.DataSource = null;
int nfrTypeID = int.Parse(cboNFRTypes.SelectedItem.Value.ToString());
AssumptionPanel.Visible = true;
string connectionString = @"Data Source=AYUSH-PC\SQLEXPRESS;Initial
Catalog=AssumptionManagement;Integrated Security=True";
string sql = "SELECT * FROM ReqMapping where nfrtypeid = " + nfrTypeID;
DataTable myTable = new DataTable();
List TagsFound = new List();
List newList = new List();
List tagList = new List();
using (SqlConnection myConnection = new SqlConnection(connectionString))
{
using (SqlCommand myCommand = new SqlCommand(sql, myConnection))
{
myConnection.Open();
using (SqlDataReader myReader = myCommand.ExecuteReader())
{
}
}
}
myTable.Load(myReader);
myConnection.Close();
for (int j = 0; j < dtRequirements.Rows.Count; j++)
{
string[] str = dtRequirements.Rows[j][1].ToString().Split(' ');
for (int i = 0; i < str.Length; i++)
57

{
for (int k = 0; k < myTable.Rows.Count; k++)
{
if (str[i].Contains(myTable.Rows[k][1].ToString()))
{
TagsFound.Add("ReqID " + (j + 1) + "," + dtRequirements.Rows[j][1] + ",Faulty Words : " +
myTable.Rows[k][1].ToString());
}
}
}
}
int counter = 1;
foreach (string s in TagsFound)
{
if (!newList.Contains(s))
{
newList.Add(s);
}
counter++;
}
string[] strFetchAssumption = null;
for (int i = 0; i < newList.Count; i++)
{
strFetchAssumption = newList[i].Split(',');
tagList.Add(new myTags { RequirementID = strFetchAssumption[0], Requirement = strFetchAssumption[1],
FaultyWord = strFetchAssumption[2], nfrType = cboNFRTypes.SelectedItem.Text.ToString() });
}
}
}
AssumptionPanel.Visible = true;
GridAssumptions.DataSource = tagList;
protected void cmdClear_Click(object sender, EventArgs e)
{
try
{
System.IO.DirectoryInfo downloadedMessageInfo = new DirectoryInfo(Server.MapPath("~/Requirements"));
foreach (FileInfo file in downloadedMessageInfo.GetFiles())
{
file.Delete();
}
58

}
RadAjaxManager1.Alert("Requirements cleared Successfully");
gridRequirements.Rebind();
GridAssumptions.Rebind();
}
catch
{
RadAjaxManager1.Alert("Error Removing the Requirements");
}
}
protected void GridAssumptionDataSource(object source, GridNeedDataSourceEventArgs e)
{
var file = Directory.GetFiles(Server.MapPath("~/Requirements"))
.FirstOrDefault();
if (file != null)
{ findTagsForHiddenAssumptions(GetRequirements()); }
}
protected void IndexChanged(object o, RadComboBoxSelectedIndexChangedEventArgs e)
{
var file = Directory.GetFiles(Server.MapPath("~/Requirements"))
.FirstOrDefault();
}
if (file != null)
{ GridAssumptions.Rebind(); }
else
{ RadAjaxManager1.Alert("No requirements found .. !!!"); }
59

Login Screen
APPENDIX C
USER GUIDE
1. First page of the application is login page. Enter correct username and password to
proceed.
2. For new users, click on the “Register” link on login page, enter the
3. Information required and click on submit button. After creating a new username,
user can log into the system using new username and password.
4. In case of user forgetting the password, the user can go to the forget password link
and can enter its user name and click send password. The password would be send
to the user to the email address entered at the time of registering.
5. In case, the user wants to change the password than the user can go to the change
password link and do the same.
Management Screen
1. At any point in time if the user feels that any Tag or NFR needs to be added /
updated or deleted than we can always go to the Tag Management or NFR
management screens and do the same.
Assumption Management
1. After logging in the user sees, the assumption management page opened up .To
start searching for tags first upload the requirement document that needs to be
analyzed and click the upload requirement button.
60

1. Please make sure the requirements are in the excel sheet in the desired
template form.
2. After uploading the requirement, the requirement should show up in the
screen in the grid beneath the Requirements heading.
3. Select the NFR type from the dropdown for the type of NFR for which the
requirement needs to be analyzed.
4. The assumption screen shows up below the dropdown in the grid with the
requirement, faulty word and type shown in the grid.
61

REFERENCES
[1]. Requirements Engineering for Time-To-Market Projects. McPhee, Alta.
Eberlein.
http://ieeexplore.ieee.org/xpl/articleDetails.jsp;jsessionid=hkzxQq0ZSpnhJkmvgRplT
m5PL226n8SKM51CGvlxcMT5vNTPqMDn!1271855879?arnumber=999818&conte
ntType=Conference+Publications
[2]. Requirements Engineering for Product Development. IBM Corporation.
ftp://ftp.software.ibm.com/software/plm/solutions/Requirements_Engineering.p df
[3]. Hidden Assumptions Inside Requirements. MICRA, Inc. 1998.
[4]. Risk Management Framework. Gary.E. McGraw.
https://buildsecurityin.us-cert.gov/bsi/articles/best-practices/risk/250-BSI.html
[5]. Assumption Management. Robert C.Seacord
http://www.sei.cmu.edu/library/abstracts/news-at-sei/cotsspot1q03.cfm
[6]. Hidden Assumptions: What You Do not Know Can Hurt You. Linda Hayes.
http://www.stickyminds.com/sitewide.asp?ObjectId=11067
[7]. Software Assumptions Lead to Preventable Errors. Andy Stengruebl.
http://www.thesecuritypractice.com/the_security_practice/papers/84-87.pdf
62

[8]. Assumptions Management in Software Development. G.A.Lewis
http://www.dtic.mil/cgi-bin/GetTRDoc?AD=ADA443152
[9]. Cause and Effect Analysis. Mid Tools Corporation.
http://www.mindtools.com/pages/article/newTMC_03.htm
63