ASSUMPTION MANAGEMENT SYSTEM A Project Presented to the ...
ASSUMPTION MANAGEMENT SYSTEM A Project Presented to the ...
ASSUMPTION MANAGEMENT SYSTEM A Project Presented to the ...
You also want an ePaper? Increase the reach of your titles
YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.
<strong>ASSUMPTION</strong> <strong>MANAGEMENT</strong> <strong>SYSTEM</strong><br />
A <strong>Project</strong><br />
<strong>Presented</strong> <strong>to</strong> <strong>the</strong> faculty of <strong>the</strong> Department of Computer Science<br />
California State University, Sacramen<strong>to</strong><br />
Submitted in partial satisfaction of<br />
<strong>the</strong> requirements for <strong>the</strong> degree of<br />
MASTER OF SCIENCE<br />
in<br />
Software Engineering<br />
by<br />
Ayush Chadha<br />
FALL<br />
2012
© 2012<br />
Ayush Chadha<br />
ALL RIGHTS RESERVED<br />
ii
Approved by:<br />
<strong>ASSUMPTION</strong> <strong>MANAGEMENT</strong> <strong>SYSTEM</strong><br />
A <strong>Project</strong><br />
by<br />
Ayush Chadha<br />
__________________________________, Committee Chair<br />
Ahmed Salem, Ph.D.<br />
__________________________________, Second Reader<br />
Bob Buckley, MS.<br />
_________________________<br />
Date<br />
iii
Student: Ayush Chadha<br />
I certify that this student has met <strong>the</strong> requirements for format contained in <strong>the</strong><br />
University format manual, and that this <strong>Project</strong> is suitable for shelving in <strong>the</strong><br />
Library and credit is <strong>to</strong> be awarded for <strong>the</strong> <strong>Project</strong>.<br />
, Graduate Coordina<strong>to</strong>r<br />
Nik Faroughi, Ph.D Date<br />
Department of Computer Science<br />
iv
Abstract<br />
of<br />
<strong>ASSUMPTION</strong> <strong>MANAGEMENT</strong> <strong>SYSTEM</strong><br />
by<br />
Ayush Chadha<br />
Capturing and documenting quality software requirements is a major challenging task in<br />
<strong>the</strong> software development lifecycle. Requirements typically are misunders<strong>to</strong>od and<br />
misinterpreted by <strong>the</strong> various stakeholders and often contain hidden assumptions.<br />
These “hidden assumptions” can be very costly <strong>to</strong> detect and correct and may lead <strong>to</strong><br />
serious software failures. The aim of this project is <strong>to</strong> design an Assumption Management<br />
System which will facilitate a process of detecting hidden assumptions within software<br />
requirements.<br />
The system is divided in<strong>to</strong> three components:<br />
1. A Risk Management Framework which provides a comprehensive approach <strong>to</strong><br />
design <strong>the</strong> proposed system.<br />
v
2. A methodology which consists of a Fishbone and Tag Management techniques,<br />
when applied <strong>to</strong> <strong>the</strong> Risk Management Framework, helps in detecting <strong>the</strong> hidden<br />
assumptions within <strong>the</strong> software requirements.<br />
3. A Web based <strong>to</strong>ol <strong>to</strong> help engineers detect hidden assumptions within software<br />
systems.<br />
Ahmed Salem, PhD<br />
Date<br />
, Committee Chair<br />
vi
DEDICATION<br />
I would like <strong>to</strong> dedicate my project <strong>to</strong> my family members, especially <strong>to</strong> my bro<strong>the</strong>r<br />
Ankur without <strong>the</strong> support of whom I would not have reached this level. I really<br />
thank <strong>the</strong>m for all <strong>the</strong>ir support.<br />
vii
ACKNOWLEDGEMENTS<br />
I would like <strong>to</strong> extend my gratitude <strong>to</strong> my project advisor Dr. Ahmed Salem for<br />
guiding me throughout this project and helping me complete this project successfully.<br />
I would also like <strong>to</strong> thank Nancy Talamantes of <strong>the</strong> FTB Corporation and Bob Guzik<br />
of Amdocs Corporation and Dale Fletter for <strong>the</strong>ir valuable inputs and guidance.<br />
In addition, I would like <strong>to</strong> thank The Department of Computer Science at California<br />
State University for extending this opportunity for me <strong>to</strong> pursue this program and<br />
guiding me all <strong>the</strong> way <strong>to</strong> become a successful student.<br />
Finally, <strong>to</strong> all my wonderful friends who helped me during course of this project and<br />
master’s program. Special thanks <strong>to</strong> my friends Sarjit and my roommate Avinash who<br />
s<strong>to</strong>od by me in hard times and made sure this project is completed successfully.<br />
viii
TABLE OF CONTENTS<br />
ix<br />
Page<br />
Dedication……………………………………………………………………………......vii<br />
Acknowledgements…………………………..………….………………………………viii<br />
List of Tables……………………………………..……………………………………...xii<br />
List of Figures………………………………….……..……………………………........xiii<br />
Chapter<br />
1. INTRODUCTION ……………...…..………………………………..……………......1<br />
2. BACKGROUND…………………………………….………………...……………....4<br />
2.1. Proposed Solution Assumptions..………………………………………………...10<br />
3. METHODOLOGY……………………………………….……………...………........11<br />
3.1. Cause and Effect Method……………………………………………...................11<br />
3.2. Risk Management Methodology…………………...…………...……...…….…..13<br />
3.2.1. Understanding <strong>the</strong> Business Context……………………….…....……...14<br />
3.2.2 .Identifying Business and Technical Risks……………............................15<br />
3.2.3. Syn<strong>the</strong>size and Prioritize <strong>the</strong> Risks……………………….......................16<br />
3.2.4. Define Risk Mitigation Strategy………………………………...……....16
3.2.5. Execute Process and Validate <strong>the</strong> Results………………………..….......17<br />
.<br />
3.3. Assumption Management by Tag Detection…………………..............................17<br />
4. PROPOSED SOLUTION ……………………….…….….…….....…………..…......19<br />
4.1. Solution Details….………………………………………………..……………...21<br />
4.2. Solution Strengths and Benefits.……………………………..…………..…........28<br />
4.3. Solution Constraints…………………………………………...………..………..29<br />
5. TAG DETECTOR <strong>SYSTEM</strong>…………….…………….………….….….....……........30<br />
5.1. Tag Detec<strong>to</strong>r Requirements………………………………….…...........................30<br />
.<br />
5.1.1. User Management Requirements……………..........................................30<br />
5.1.2. Tag Management Requirements…………...............................................32<br />
5.1.3. NFR Management Requirement……………...........................................32<br />
5.1.4. Assumption Management Requirements…….……….............................32<br />
5.1.5. Tag Detec<strong>to</strong>r Assumptions…………….……………......…….………...33<br />
5.1.6. O<strong>the</strong>r Information………………………….…………….…...................33<br />
5.2. Use Cases…………………………………….…….…………....…....................34<br />
5.2.1. User Management Use Case…………………………...…....................34<br />
.<br />
5.2.2. Tag Management Use Case……………………..………......................35<br />
5.2.3. NFR Management Use Case………………………………..................36<br />
x
5.3. Data Flow Diagram…………………………………..................……...............37<br />
5.4. Database Structure………………………………......…………………............38<br />
5.5. Architecture of <strong>the</strong> Tag Detec<strong>to</strong>r………….…..……….....................................39<br />
5.6. Tag Detec<strong>to</strong>r Screens…………………………….….…..……..........................40<br />
5.6.1. User Management Screen…………….......…...……………..................40<br />
5.6.2. Tag Management Screen……………………….....……....…….….…..43<br />
5.6.3. NFR Management Screen………………….......……….……………...45<br />
5.6.4. Assumption Management System…………………………….…….....48<br />
5.7. Tag Detec<strong>to</strong>r Strengths and Weaknesses...…….…….….…………...…………50<br />
6. CONCLUSION………………...……….…...…………..…..…….….….……..….....51<br />
6.1. Conclusion……………………………………………………………………….51<br />
6.2. Future Work……………………………………………………….…....……….51<br />
Appendix A.……………………………..………………….………..………….….……….52<br />
Appendix B……………………………………………………….…...……………....….....54<br />
Appendix C…………………………..…………………………………....………………...59<br />
References……………………………...………...…………………...……….....….….……61<br />
xi
LIST OF TABLES<br />
Tables Page<br />
1. Representation of Different Set of NFR’s with <strong>the</strong> Words Attached…..………............18<br />
2. Action Words With <strong>the</strong> Conjugates……………………………….....…………………18<br />
xii
LIST OF FIGURES<br />
Figures Page<br />
1. Simple Framework for a Single <strong>Project</strong>……...…...……………..……...….......9<br />
2. Creating <strong>the</strong> Cause and Effect Diagram..……………………….…….............12<br />
3. Creating <strong>the</strong> Cause and Effect Diagram for Assumption……………..............12<br />
4. The BSI Risk Management Framework………..……………..........................14<br />
5. Four Stages of Solution …………………..……..………….………...............19<br />
6. Solution Diagram………….……………………...……..…………................20<br />
7. Cause and Effect Analysis of <strong>the</strong> Quantum of Data in Excel...........................25<br />
8. Cause and Effect Analysis of <strong>the</strong> Requirements 2, 3 and 4…...……..…….....27<br />
9. Use Case Diagram for <strong>the</strong> User Management Module….……...…….............34<br />
10. Use Case Diagram for <strong>the</strong> Tag Management Module..……............................35<br />
11. Use Case Diagram for <strong>the</strong> NFR Management Module...……….………........36<br />
12. Data Flow Diagram……………………………………….………….............37<br />
13. Database Structure for Tag Detec<strong>to</strong>r……………………...…….….……..…38<br />
14. Architecture of Tag Detec<strong>to</strong>r…..……………………….…………...….........39<br />
15. Register User Screen…………….…………………………………....….…..40<br />
16. Forget Password Screen..……………………………………………....…….40<br />
17. Change Password Screen……..………………………………….…….…….41<br />
18. Login Screen………………..……………………………………….……….41<br />
xiii
19. User Management Screen…...…………………………………………….....42<br />
20. Edit User Screen……………..………………………………………….….. 42<br />
21. Tag Management Screen…….……………………………………………….43<br />
22. Add Tag Screen………………………………………………………………44<br />
23. Edit Tag Screen….……..………………..…………………...…………....…44<br />
24. Delete Tag Screen……………….………………...………………...……….45<br />
25. NFR Management Screen..……….….……………...……………………….46<br />
26. Add NFR Screen….…………..…………………………….…………..……46<br />
27. Edit NFR Screen…….…..………………………………….………...............47<br />
28. Delete NFR Screen……………..………..…………………..…….……........47<br />
29. No Requirement Uploaded Screen………….……………………...…..…….48<br />
30. Requirement Uploaded Screen……...………………….………....…..….......49<br />
31. Assumption Management Screen..……..……………….………….…….......50<br />
xiv
CHAPTER 1<br />
INTRODUCTION<br />
As <strong>the</strong> businesses across <strong>the</strong> world become more and more complex, <strong>the</strong> needs for<br />
sophisticated software, which can handle complex scenarios, are increasing rapidly.<br />
This has led <strong>to</strong> an ever-increasing demand for better software development<br />
approaches, which are robust enough <strong>to</strong> handle <strong>the</strong> complex and dynamic<br />
requirements [1]. Consequently, <strong>the</strong> software must be developed and integrated faster<br />
than ever by bringing <strong>to</strong>ge<strong>the</strong>r diverse and distributed components, which are owned<br />
and built by multiple teams. The challenges lie in creating those components or<br />
services in such a manner that <strong>the</strong>y can interact seamlessly and are scalable in nature.<br />
Poorly managed software leads <strong>to</strong> an increasingly bloated project timelines and blown<br />
IT budgets that in turn lead <strong>to</strong> exploding manual costs, high failure probability among<br />
o<strong>the</strong>rs. The success of <strong>the</strong> software hinges primarily on how well <strong>the</strong> software<br />
addresses <strong>the</strong> needs of <strong>the</strong> marketplace. Software requirements must drive <strong>the</strong> design<br />
and development decisions throughout <strong>the</strong> product development lifecycle and a<br />
thorough product testing must be done against <strong>the</strong> specified requirements <strong>to</strong> make<br />
sure we are not just delivering software that works, but also <strong>the</strong> software that we set<br />
out <strong>to</strong> build. This calls for a well-defined requirement engineering process that<br />
enables <strong>to</strong> manage <strong>the</strong> requirements throughout <strong>the</strong> entire product lifecycle.<br />
Requirements engineering is a systems and software engineering process, which<br />
covers all of <strong>the</strong> activities involved in discovering, documenting and maintaining a set<br />
of requirements for a computer-based system [2]. While <strong>the</strong>re are differing definitions<br />
of <strong>the</strong> term, common fac<strong>to</strong>rs are that requirements engineering is a sub discipline of<br />
1
system and software engineering and is concerned with establishing <strong>the</strong> goals,<br />
functions and constraints of hardware and software system [2].<br />
Software requirements, both functional and non-functional, contain assumptions,<br />
which if not managed successfully, intrude and impose <strong>the</strong>mselves between design<br />
and deployment of a system and can lead <strong>to</strong> serious software failures in <strong>the</strong> later part<br />
of development life cycle. An assumption in literal terms is defined as, “<strong>the</strong> act of<br />
taking for granted, or supposing a thing without proof; supposition; unwarrantable<br />
claim” [3]. There can be many reasons for having assumptions; lack of knowledge<br />
domain , poor communication , ambiguous requirements , lack of domain expertise<br />
and <strong>to</strong>o much expertise are only a few of <strong>the</strong>m. Assumptions can lead <strong>to</strong><br />
inconsistencies and incompatibilities, which can cause failure and o<strong>the</strong>r post<br />
deployment problems. Fur<strong>the</strong>rmore, individual assumptions may become invalid<br />
because of changes in <strong>the</strong> environment in which <strong>the</strong> system is <strong>to</strong> be deployed.<br />
To address this problem, <strong>the</strong> following elements are necessary:<br />
1. A method <strong>to</strong> identify assumptions, even those that are “hidden”.<br />
2. An approach <strong>to</strong> record identified assumptions in a “real-time” manner that is<br />
not disruptive <strong>to</strong> <strong>the</strong> developer.<br />
3. A mechanism <strong>to</strong> validate <strong>the</strong> identified assumptions by <strong>the</strong> people that possess<br />
<strong>the</strong> knowledge <strong>to</strong> declare each assumption valid or invalid.<br />
4. A <strong>to</strong>ol <strong>to</strong> search for recorded assumptions by o<strong>the</strong>r developers and people<br />
involved in <strong>the</strong> development effort.<br />
2
Assumption management system presents an approach that helps <strong>the</strong> user <strong>to</strong> detect <strong>the</strong><br />
hidden assumptions inside <strong>the</strong> software requirements in very early stages of Software<br />
development life cycle [3]. The system uses a series of approaches <strong>to</strong> drill down<br />
hidden assumptions inside <strong>the</strong> software requirements. It includes <strong>the</strong> Cause and effect<br />
approach or more famously called as <strong>the</strong> fishbone technology, Risk mitigation<br />
strategy along with tag detection methodology <strong>to</strong> drill down deep in<strong>to</strong> <strong>the</strong> requirement<br />
and reveal <strong>the</strong> hidden assumptions [4].<br />
3
CHAPTER 2<br />
BACKGROUND<br />
Every software requirement, be it be in form of project plan, task list or user s<strong>to</strong>ry<br />
always contains certain hidden assumptions inside <strong>the</strong>m. As stated previously also, an<br />
assumption usually occurs when <strong>the</strong> software teams presume something for granted<br />
that it is true. Some assumptions are obvious but some are obscure. An assumption<br />
differs from <strong>the</strong> risk in a way that risk may be considered <strong>the</strong> adverse effect of <strong>the</strong><br />
assumption, which we usually believe, is unlikely <strong>to</strong> occur.<br />
The hidden assumptions inside <strong>the</strong> software requirements and <strong>the</strong>ir impact is<br />
something that is been a well-known problem in <strong>the</strong> software domains for years. We<br />
all make a variety of assumptions when making plans and commitments. Usually,<br />
those assumptions prove <strong>to</strong> be correct but not always [5]. In addition, <strong>the</strong> more<br />
assumptions <strong>the</strong> team makes, <strong>the</strong> greater <strong>the</strong> likelihood that something will not go as<br />
planned. (A risk event will be realized).One reason why so many development<br />
projects take longer than planned is simply because one or more assumptions proves<br />
wrong and <strong>the</strong> team has <strong>to</strong> scramble <strong>to</strong> address <strong>the</strong> issues <strong>the</strong>y were not aware of. For<br />
that reason, it is a good idea <strong>to</strong> take a moment <strong>to</strong> think through <strong>the</strong> development<br />
team’s assumptions.<br />
To understand it more clearly let us take some examples of <strong>the</strong> hidden assumptions<br />
inside <strong>the</strong> software system [3].<br />
1. The team will remain intact for <strong>the</strong> duration of <strong>the</strong> project.<br />
2. Computer systems and data will be available <strong>to</strong> <strong>the</strong> team when needed.<br />
4
3. Development <strong>to</strong>ols and technology infrastructure will be adequate <strong>to</strong> support<br />
<strong>the</strong> project.<br />
4. People outside <strong>the</strong> core team will be available when needed.<br />
5. Outside parties (e.g. vendors, suppliers, business partners, etc.) will deliver as<br />
promised.<br />
6. User s<strong>to</strong>ries have been properly scoped and estimated.<br />
7. Task lists are thorough.<br />
8. The definition-of-done covers <strong>the</strong> needs of every s<strong>to</strong>ry.<br />
9. Any team member will be able <strong>to</strong> select any s<strong>to</strong>ry and complete it.<br />
10. Team members have adequate knowledge and training <strong>to</strong> complete <strong>the</strong> project.<br />
The stated assumptions though obvious can be really risky and dangerous for <strong>the</strong><br />
project. For instance, <strong>the</strong> assumption that <strong>the</strong> team will remain intact for <strong>the</strong> duration<br />
of <strong>the</strong> project. The reason we make that assumption is that <strong>the</strong>y have over <strong>the</strong> period<br />
been intact for most of <strong>the</strong> time. However, any aberration from <strong>the</strong> stated normal<br />
behavior can lead <strong>to</strong> fatal consequences, which can become a risk <strong>to</strong> <strong>the</strong> project. If<br />
some people in team are displaced or leave <strong>the</strong> project, this can lead <strong>to</strong> problems like<br />
resource shortage and re-estimation, which can delay <strong>the</strong> project considerably.<br />
The impact of hidden assumptions can be quite severe in <strong>the</strong> field of testing <strong>to</strong>o. Linda<br />
Hayes analyzes <strong>the</strong> very structure in which most of <strong>the</strong> au<strong>to</strong>mated batch testing<br />
techniques works and how dangerous it can be if <strong>the</strong>re are any hidden assumptions in<br />
<strong>the</strong> process [6] [3]. The way batch testing works is it simply au<strong>to</strong>mates <strong>the</strong> captured<br />
production data and uses it as baseline <strong>to</strong> compare <strong>the</strong> results against it. It may be easy<br />
for describing a lot of functionality in <strong>the</strong> shorthand but unfortunately, it also means<br />
5
that an error introduced in <strong>the</strong> baseline can actually go undetected for a long period<br />
and can cause a lot of damage. This can be a common scenario presuming if <strong>the</strong><br />
system is working in production for a long period <strong>the</strong>n any documentation for <strong>the</strong><br />
system becomes long out of date and it is hard <strong>to</strong> tell if anything is going wrong in <strong>the</strong><br />
system until someone really digs deep in<strong>to</strong> it.<br />
A real time classical example of <strong>the</strong> impact of <strong>the</strong> hidden assumption can be taken<br />
from a firm called Home Side Lending; a New Jersey mortgage broker company<br />
acquired by <strong>the</strong> Australia bank was under pricing mortgages for long period due <strong>to</strong> a<br />
computer error in which <strong>the</strong> wrong interest rate was used [3] [6]. The eventual<br />
outcome was a loss of $4 billion <strong>to</strong> <strong>the</strong> bank and <strong>the</strong> bank almost went bankrupted<br />
because of that. Aside from <strong>the</strong> damage in cost, it is amazing how long <strong>the</strong> error went<br />
undetected. Mortgage pricing is essential <strong>to</strong> Home Side’s core business and alleged <strong>to</strong><br />
be <strong>the</strong>ir special competency. How it happened is a mystery but obviously someone,<br />
somewhere, and at some time decided <strong>the</strong> software was correctly pricing mortgages<br />
when it was not. No one questioned it until <strong>the</strong> Australian banking authority audited<br />
<strong>the</strong> software and found it <strong>to</strong> be working incorrectly for many years.<br />
As more and more sober s<strong>to</strong>ries of impact of hidden assumption keep coming up<br />
<strong>the</strong>re is more than ever need <strong>to</strong> come up with techniques <strong>to</strong> find <strong>the</strong> hidden<br />
assumptions in <strong>the</strong> early phase of <strong>the</strong> project. Assumption management system tries <strong>to</strong><br />
make a shot at that by suggesting a consolidated approach for finding <strong>the</strong> hidden<br />
assumptions inside <strong>the</strong> software requirements. Hidden assumptions uncover fur<strong>the</strong>r<br />
foreseen problems inside <strong>the</strong> project. Once detected <strong>the</strong> discovered assumptions must<br />
be dealt with o<strong>the</strong>rwise <strong>the</strong>y can derail <strong>the</strong> functioning of <strong>the</strong> project.<br />
6
As per many studies, it has been found that no matter what approach we use it is<br />
almost impossible <strong>to</strong> find all <strong>the</strong> hidden assumptions inside <strong>the</strong> software requirement.<br />
To mitigate it some says <strong>the</strong> best thing <strong>to</strong> do is <strong>to</strong> do a proof of concept approach <strong>to</strong><br />
project. While even this does not guarantee all round elimination but it will help ferret<br />
out a sizable fraction.<br />
The repercussions of a system going in<strong>to</strong> production with hidden assumptions can be<br />
immense. They may not be exposed for years but <strong>the</strong> potential is always <strong>the</strong>re. By<br />
definition, we will not be aware of it until <strong>the</strong> problem occurs. The best effective way<br />
is <strong>to</strong> find <strong>the</strong> hidden assumptions during <strong>the</strong> requirements/design phase of <strong>the</strong><br />
software development. At each interaction, understand why and how <strong>the</strong> data will be<br />
used. How <strong>the</strong> data will get from point A <strong>to</strong> Point B. As data moves from tier <strong>to</strong> tier<br />
(database <strong>to</strong> middleware <strong>to</strong> web server <strong>to</strong> presentation) what assumptions are carried<br />
out at each tier<br />
From <strong>the</strong> <strong>Project</strong> Management software side, <strong>the</strong> system is always viewed in through<br />
three different levels. i.e.: Technology, Business and Behavior. Unfortunately,<br />
software assumptions are found in all <strong>the</strong> three areas. In terms of behavioral side, <strong>the</strong><br />
assumptions creep up because all <strong>the</strong> stakeholders think <strong>the</strong>y are all thinking <strong>the</strong> same<br />
thing. They all think <strong>the</strong>y know <strong>the</strong> best and <strong>the</strong>y know <strong>the</strong> cus<strong>to</strong>mer’s intentions well.<br />
Which is not true in most of <strong>the</strong> cases? As per technology <strong>the</strong> reason why our<br />
assumptions are more prevalent in software is lack of engineered “blue print” type<br />
design or details. Poor communications in a communication centric world or if <strong>the</strong><br />
cus<strong>to</strong>mer requirements are intangible, difficult <strong>to</strong> define and verbalize. In addition,<br />
fast-paced business does not allow for design freeze. Some typical assumptions here<br />
7
are technology can solve our key problems, People are interchangeable and its<br />
technology that is important. Also assuming that <strong>the</strong> estimates are accurate enough.<br />
From business point of view some typical assumptions are <strong>the</strong>re is always a funding<br />
available from somewhere, we know what’s/who is driving our project. The ‘paying’<br />
cus<strong>to</strong>mer is happy among o<strong>the</strong>rs. Assumptions affect all aspects of project planning<br />
and are part of progressive elaboration of <strong>the</strong> project.<br />
Many experts of software engineering have tried <strong>to</strong> study this problem and have come<br />
up with many <strong>the</strong>ories, which aim at suggesting <strong>the</strong> negative impact of <strong>the</strong> hidden<br />
assumptions and how critical it is <strong>to</strong> detect <strong>the</strong>m at <strong>the</strong> earliest. Though most of <strong>the</strong><br />
work done in this area aims mainly at highlighting <strong>the</strong> impact of <strong>the</strong> hidden<br />
assumptions inside <strong>the</strong> project but not much research has been done in defining some<br />
definite set of techniques that aim <strong>to</strong> find <strong>the</strong> hidden assumptions inside <strong>the</strong> project .<br />
Andy Steingruebl and Gunnar Peterson for instance take a shot at creating a<br />
methodology for revealing hidden assumptions by coming up with better approach for<br />
discovering and documenting <strong>the</strong>m. They classify <strong>the</strong> hidden assumptions in<strong>to</strong> three<br />
categories of design time, run time and implementation time and come up with<br />
techniques for how <strong>to</strong> apply different techniques for different types of <strong>the</strong> assumptions<br />
and what can be done <strong>to</strong> eliminate <strong>the</strong> same [7]. GA Lewis comes up with<br />
Assumption management software that s<strong>to</strong>res <strong>the</strong> assumptions in a reposi<strong>to</strong>ry and<br />
integrates it with <strong>the</strong> project management and system administration modules <strong>to</strong><br />
reveal <strong>the</strong> hidden assumptions [8].<br />
8
Our approach aims <strong>to</strong> present an approach for finding out hidden assumptions inside<br />
<strong>the</strong> project during <strong>the</strong> early life cycle of <strong>the</strong> project. All <strong>the</strong> technical and business<br />
stakeholders <strong>to</strong> uncover “hidden assumptions” in early phase of <strong>the</strong> project should use<br />
<strong>the</strong> underlying approach / methodology easily. . This will help avoid <strong>the</strong> problems<br />
that are discovered later in <strong>the</strong> development life cycle when <strong>the</strong>y become more<br />
expensive. This new methodology will need <strong>to</strong> provide a vehicle <strong>to</strong> encourage<br />
stakeholders <strong>to</strong> think about and vocalize assumptions, even obvious ones, early in <strong>the</strong><br />
analysis phase of product development.<br />
Close<br />
Execute<br />
Control<br />
Many Possible Assumptions<br />
Figure 1 - Simple Framework for a Single <strong>Project</strong> [5].<br />
Initiate<br />
Plan<br />
9
2.1 Proposed Solution Assumptions<br />
The proposed approach has <strong>the</strong> following underlying assumptions:<br />
1. All <strong>the</strong> stakeholders are involved in <strong>the</strong> requirement ga<strong>the</strong>ring process.<br />
2. All concerned parties have in-depth expertise of domain and <strong>the</strong>ir respective<br />
vertical.<br />
3. Abidance <strong>to</strong> <strong>the</strong> solution especially in <strong>the</strong> early stages of <strong>the</strong> process.<br />
4. Improving <strong>the</strong> quality involves taking action on <strong>the</strong> root causes of <strong>the</strong><br />
problem.<br />
5. There always are hidden assumptions.<br />
10
CHAPTER 3<br />
METHODOLOGY<br />
The project solves <strong>the</strong> problem of <strong>the</strong> hidden assumption with <strong>the</strong> help of three main<br />
techniques i.e. Cause and effect or fishbone technology, risk management technique<br />
and <strong>the</strong> tag detection method. The description of three is as follows:<br />
3.1 Cause and Effect Method<br />
Cause and effect analysis methodology is a method, which was developed by<br />
Japanese professor Kaoru Ishikawa, a pioneer of quality management. The process<br />
includes creating a cause and effect diagram, which is also called as <strong>the</strong> fishbone<br />
diagram. Originally developed as a quality control <strong>to</strong>ol this technique however can be<br />
applied <strong>to</strong> a range of o<strong>the</strong>r areas. As an example, it can be used <strong>to</strong> discover <strong>the</strong> root<br />
cause of <strong>the</strong> problem, uncover bottlenecks in <strong>the</strong> processes and identify where and<br />
why a process is not working properly [9].<br />
Cause and effect analysis provides a structured way <strong>to</strong> think through all possible<br />
causes of a problem. This helps carry out a thorough analysis of a situation and uses<br />
an idea-generating technique <strong>to</strong> identify <strong>the</strong> fac<strong>to</strong>rs within each category that may be<br />
affecting <strong>the</strong> problem / issue and/or effect being studied. For those items identified as<br />
<strong>the</strong> “Most likely causes”, <strong>the</strong> team should be able <strong>to</strong> reach a consensus on listing those<br />
items in priority order with <strong>the</strong> first item being <strong>the</strong> most probable cause.<br />
Application of cause and effect method in <strong>the</strong> detection of <strong>the</strong> hidden assumptions<br />
inside <strong>the</strong> software requirement can be effective. The root cause of assumptions is <strong>the</strong><br />
way in which <strong>the</strong> requirements are drafted. A short and ambiguous statement of<br />
11
software requirement may contain many assumptions, which can be costly especially<br />
in <strong>the</strong> later stages of <strong>the</strong> software development life cycle. Cause and effect helps<br />
decipher those assumptions at a very early stage by revealing all possible risks that<br />
may be involved with that requirement.<br />
To illustrate it let us consider an example of how we will create a fishbone diagram<br />
for a problem-hidden assumption for instance.<br />
Step 1: The Developer starts with <strong>the</strong> effect <strong>to</strong> be investigated (hidden assumption)<br />
and draws a backbone arrow <strong>to</strong> it.<br />
Hidden<br />
Assumptions<br />
Figure 2 - Creating <strong>the</strong> Cause and Effect Diagram<br />
Step 2: We identify all <strong>the</strong> broad areas of inquiry in which <strong>the</strong> cause and effect being<br />
investigated may lie. For hidden assumptions, <strong>the</strong> diagram may <strong>the</strong>n become (see Fig.<br />
2).<br />
Step 3: In this step, we dig down deep in<strong>to</strong> each area of inquiry and see what can<br />
cause that <strong>to</strong> happen. The result will be representation of all fac<strong>to</strong>rs related <strong>to</strong> <strong>the</strong><br />
effect being explored and <strong>the</strong> relationships between <strong>the</strong>m.<br />
12
Faulty functional requirements<br />
Arrogance of experts<br />
Lack of domain competence<br />
Faulty NFRs Trying new Methodology<br />
Time Shortage<br />
13<br />
Lack of knowledge<br />
Ambiguou<br />
s<br />
Requirem<br />
ents<br />
Assumptions<br />
Communication Gap<br />
Figure 3 - Creating <strong>the</strong> Cause and Effect Diagram for Assumptions.<br />
3.2 Risk Management methodology<br />
Risk analysis is often viewed as a black art. Successful risk analysis is however<br />
nothing more than a business level decision support <strong>to</strong>ol. It is a way of ga<strong>the</strong>ring <strong>the</strong><br />
requisite data <strong>to</strong> make a good judgment call based on knowledge about vulnerabilities,<br />
threats, impacts and probability.<br />
Risk management approach helps <strong>to</strong> assess risk, manage cost and control quality of<br />
software and data from vendor; measure effectiveness of people, processes and<br />
supporting frameworks in <strong>the</strong> software supply chain; and helps <strong>to</strong> find and govern <strong>the</strong><br />
risk <strong>to</strong> us, our business and our organization [4].
Now for <strong>the</strong> question how this risk management strategy does helps in finding out <strong>the</strong><br />
hidden assumptions. When we talk about <strong>the</strong> assumptions, finding <strong>the</strong>m alone does<br />
not add value <strong>to</strong> <strong>the</strong> process unless we attach risk <strong>to</strong> <strong>the</strong>m and rank <strong>the</strong>m accordingly.<br />
Risk management framework gives us <strong>the</strong> power <strong>to</strong> do that.<br />
The Risk management framework consists of five fundamental activity stages as<br />
shown in Figure 4 [4].<br />
Figure 4 - The BSI Risk Management Framework [4]<br />
3.2.1. Understand <strong>the</strong> Business Context<br />
Software risk management occurs in a business context. Risks are often unavoidable<br />
and are integral part of <strong>the</strong> software development process. This stage of <strong>the</strong> process<br />
focuses on handling <strong>the</strong> business situation. Commonly, business goals are nei<strong>the</strong>r<br />
obvious nor explicitly stated. In some cases, we may even have difficulty expressing<br />
<strong>the</strong>se goals clearly and consistently. During this stage <strong>the</strong> analyst must extract <strong>the</strong><br />
business goals, priorities and circumstances in order <strong>to</strong> understand what kind of risks<br />
14
<strong>to</strong> care about and which business goals are paramount. Business goals include<br />
increasing revenue, meeting service level agreements. Reducing development costs<br />
and generating high return on investment.<br />
3.2.2 Identify Business and Technical Risks<br />
Business risks are a danger <strong>to</strong> <strong>the</strong> business goals. The identification of such risks<br />
helps <strong>to</strong> clarify and measure <strong>the</strong> impact those will have on <strong>the</strong> business goals.<br />
Business risks may have impacts that include direct financial loss, damage <strong>to</strong> brand or<br />
reputation, violation of cus<strong>to</strong>mer or regula<strong>to</strong>ry constraints, exposure <strong>to</strong> liability and<br />
increase of <strong>the</strong> development costs. The severity of a business risk should be expressed<br />
in terms of financial or project management metrics. These include but are not limited<br />
<strong>to</strong> market share, direct cost, and level of productivity and cost of rework.<br />
Business risk identification helps <strong>to</strong> define and steer use of particular technical<br />
methods for extracting, measuring, and mitigating software risk given various<br />
software artefacts. The identification of business risks provides a necessary<br />
foundation that allows software risk (especially impact) <strong>to</strong> be quantified and described<br />
in business terms. The key <strong>to</strong> making risk management work for business lies in tying<br />
technical risks <strong>to</strong> business context in a meaningful way. The ability <strong>to</strong> identify and<br />
deeply understand risks is thus essential. Uncovering and recognizing technical risks<br />
is a high-expertise undertaking that usually requires years of experience.<br />
Central <strong>to</strong> this stage of <strong>the</strong> Risk Management Framework lays <strong>the</strong> ability <strong>to</strong> discover<br />
and describe technical risks and map <strong>the</strong>m (through business risks) <strong>to</strong> business goals.<br />
A technical risk is a situation that runs counter <strong>to</strong> <strong>the</strong> planned design or<br />
15
implementation of <strong>the</strong> system under consideration. For example, a technical risk may<br />
give rise <strong>to</strong> <strong>the</strong> system behaving in an unexpected way, violating its own design<br />
strictures, or failing <strong>to</strong> perform as required. Technical risks can also be related <strong>to</strong> <strong>the</strong><br />
process of building software. The process an organization follows may offer <strong>to</strong>o many<br />
opportunities for mistakes in design or implementation. Technical risks involve<br />
impacts such as unexpected system crashes, avoidance of controls (audit or<br />
o<strong>the</strong>rwise), unauthorized data modification or disclosure, and needless rework of<br />
artefacts during development.<br />
3.2.3 Syn<strong>the</strong>size and Prioritize <strong>the</strong> Risks<br />
This stage involves syn<strong>the</strong>sizing all <strong>the</strong> risks identified in <strong>the</strong> stage 2 and prioritizing<br />
<strong>the</strong>m as <strong>to</strong> which of <strong>the</strong>m can really affect <strong>the</strong> business goals <strong>the</strong> most. Clearly, <strong>the</strong><br />
prioritization process should take in<strong>to</strong> effect which of <strong>the</strong> goals of firm is <strong>the</strong> most<br />
important ones. According <strong>to</strong> <strong>the</strong> priority, all <strong>the</strong> risks identified should be ranked in<br />
order of <strong>the</strong> most critical <strong>to</strong> <strong>the</strong> least ones.<br />
3.2.4 Define Risk Mitigation Strategy<br />
Stage 3 gives <strong>the</strong> information of all <strong>the</strong> risks that are associated in order of <strong>the</strong>ir<br />
criticality. This stage aims <strong>to</strong> mitigate those risks by clearly defining <strong>the</strong> strategies <strong>to</strong><br />
weep out <strong>the</strong> risks. Typical metrics includes likelihood, risk impact, risk severity and<br />
number of risks emerging and mitigated over <strong>the</strong> period.<br />
16
3.2.5 Execute Process and Validate <strong>the</strong> Results.<br />
Once a plan is set, it is <strong>the</strong> time <strong>to</strong> execute <strong>the</strong>m. This stage does that. Risk mitigation<br />
should be carried out in accordance <strong>to</strong> <strong>the</strong> plan that has been set in <strong>the</strong> earlier stage.<br />
This stage also involves application of those validation techniques previously<br />
identified. The validation stage provides some confidence that risks have been<br />
properly mitigated through artifact improvement and that <strong>the</strong> risk mitigation strategy<br />
is working. Testing can be used <strong>to</strong> demonstrate and measure <strong>the</strong> effectiveness of risk<br />
mitigation activities. The central concern at this stage is <strong>to</strong> validate those software<br />
artifacts and processes no longer bear unacceptable risks. This stage should define and<br />
leave in place a repeatable, measurable, verifiable validation process that can be run<br />
from time <strong>to</strong> time <strong>to</strong> continually verify artifact quality. Typical metrics employed<br />
during this stage include artifact quality metrics as well as levels of risk mitigation<br />
effectiveness.<br />
3.3 Assumption Management by Tag Detection.<br />
It has been found that <strong>the</strong> set of non-functional requirements that contains a certain set<br />
of words or tags are more susceptible <strong>to</strong> have hidden assumptions inside <strong>the</strong>m as<br />
compared <strong>to</strong> <strong>the</strong> ones that do not have <strong>the</strong>m. The tag detection technique aims at<br />
parsing <strong>the</strong> software requirements and aiming <strong>to</strong> find those words or tags inside <strong>the</strong>m.<br />
A quick parse can tell which parts of <strong>the</strong> requirements can be faulty and needs fur<strong>the</strong>r<br />
assessment.<br />
17
Table 1 displays <strong>the</strong> different set of NFRs and <strong>the</strong> commonly used tags attached <strong>to</strong> it.<br />
Table 2 displays <strong>the</strong> keyword and its conjugate both of which can be source of hidden<br />
assumptions.<br />
Table 1 - Representation of <strong>the</strong> Set of NFRs and <strong>the</strong> Words.<br />
Functionality Usability Reliability Efficiency Maintainability Portability<br />
system system system system system installation<br />
external software resource scaling resource system<br />
resource data data software software installed<br />
data allow software<br />
unnecessary<br />
Log software<br />
available configuration gracefully limits Error patch<br />
resources provide behave workload change upgrade<br />
consumers user<br />
application<br />
extended configuration likelihood<br />
application valid failure time procedures mismatches<br />
restarted affecting event application processes between<br />
processing users error tier Data configurations<br />
procedures profile time distribution information patches<br />
Table 2 - Action Words with <strong>the</strong> Conjugate.<br />
Keyword Conjugate<br />
Can Can not<br />
Must Must not<br />
Shall Shall not<br />
Should Should Not<br />
Will Will not<br />
18
CHAPTER 4<br />
PROPOSED SOLUTION<br />
The proposed solution <strong>to</strong> solve <strong>the</strong> problem of hidden assumption makes use of <strong>the</strong><br />
three methodologies discussed in <strong>the</strong> chapter four. How <strong>the</strong>y are combined <strong>to</strong>ge<strong>the</strong>r<br />
and how <strong>the</strong> combination helps in solving <strong>the</strong> hidden assumption problem is<br />
something we will discuss in this chapter. The combined approach takes a shot at<br />
finding <strong>the</strong> hidden assumptions that <strong>to</strong>o at <strong>the</strong> early phases of <strong>the</strong> SDLC [2].<br />
This is how it works. First we apply <strong>the</strong> RMF framework process that we discussed in<br />
chapter 3 and amalgamate <strong>the</strong> 2 o<strong>the</strong>r methodologies in <strong>the</strong> risk identification and<br />
mitigation stage of <strong>the</strong> process [4].<br />
Assuming <strong>the</strong> stakeholders understand <strong>the</strong> Business Context well. The solution<br />
involves 4 steps: -<br />
STAGE 1<br />
Identify <strong>the</strong> Technical / Business risks involved with <strong>the</strong> requirements.<br />
STAGE 2<br />
Prioritize <strong>the</strong> risks involved.<br />
STAGE 3<br />
Define <strong>the</strong> risk mitigation strategy.<br />
STAGE 4<br />
Problem solving and requirement validation.<br />
Figure 5 - Four Stages of Solution.<br />
19
Functionality Usability<br />
system system<br />
external software<br />
resource data<br />
data allow<br />
available configuration<br />
resources provide<br />
consumers user<br />
1. Tag Detection Method 2.Fishbone Diagram<br />
Figure 6 – Solution Diagram: The diagram explains <strong>the</strong> approach <strong>the</strong> system uses for<br />
<strong>the</strong> hidden assumption removal. It is an extension <strong>to</strong> <strong>the</strong> traditional RMF discussed in<br />
chapter four. Here <strong>the</strong> processes of risk identification and risk mitigation are extended<br />
with <strong>the</strong> tag detection and fishbone diagram approach respectively. The tag detection<br />
method helps in revealing more risks inside <strong>the</strong> requirements and <strong>the</strong> fishbone<br />
methodology helps in enhancing <strong>the</strong> mitigation process of <strong>the</strong> requirements [4].<br />
20
In order <strong>to</strong> understand how our approach works let us apply this on real time<br />
requirements and see how this works. The following is <strong>the</strong> example of <strong>the</strong> real time<br />
project used as a test sample <strong>to</strong> be applied <strong>to</strong> our solution.<br />
4.1 Solution Details<br />
To see how our solution works let us consider a sample project and try <strong>to</strong> apply our<br />
solution <strong>to</strong> it.<br />
Sample <strong>Project</strong> Statement:<br />
Our organization relies heavily on <strong>the</strong> support of our community through volunteer<br />
work. We have many volunteers who teach our classes, men<strong>to</strong>r our clients, and assist<br />
with fundraising and events. Our volunteer base is about 300 volunteers, who work<br />
weekly, monthly, or annually. We need a system <strong>to</strong> be able <strong>to</strong> input volunteer’s<br />
contact information/employer information and track hours that volunteers work. The<br />
system should provide a way <strong>to</strong> calendar <strong>the</strong> volunteers in<strong>to</strong> a staff/office calendar<br />
system. Our staff should be able <strong>to</strong> view and make changes <strong>to</strong> a certain extent, but <strong>the</strong><br />
Volunteer Coordina<strong>to</strong>r would have ultimate editing/changing abilities. The system<br />
should allow users <strong>to</strong> export <strong>the</strong> data in<strong>to</strong> an excel file so it can be imputed in<strong>to</strong><br />
ano<strong>the</strong>r database we use for donors.<br />
Sample <strong>Project</strong> Organization Computer Environment:<br />
The organization has a server/shared drive that each staff member can access. The<br />
staff is not all that computer savvy so <strong>the</strong> program/database would have <strong>to</strong> be very<br />
user friendly, at least for those just accessing <strong>the</strong> information.<br />
21
Sample <strong>Project</strong> Aim:<br />
Develop a system <strong>to</strong> manage and track office volunteer information and transactions.<br />
Functional and nonfunctional requirements:<br />
The system should/Shall allow:<br />
1. Ability <strong>to</strong> export data <strong>to</strong> MS Excel.<br />
2. Allocate volunteer interest (volunteer is interested in special events, teaching a<br />
class, childcare, sorting clo<strong>the</strong>s, etc.).<br />
3. Allocate volunteer “area of service” (example: teacher, men<strong>to</strong>r, special events,<br />
childcare certified, etc.)<br />
4. Notify staff of volunteer birthday.<br />
5. Email volunteers a reminder <strong>the</strong>y will be teaching (date and time as imputed in<br />
<strong>the</strong> database).<br />
6. Email volunteers of upcoming volunteer opportunities specified by staff.<br />
7. Interact with a client database (not yet created) so we can assign volunteer<br />
men<strong>to</strong>rs <strong>to</strong> clients).<br />
8. Calculate volunteer hours.<br />
9. Needs <strong>to</strong> run on website for universal access.<br />
10. Can run on any operating system.<br />
11. Software must be reliable and not crash.<br />
Applying Our Approach <strong>to</strong> <strong>the</strong> Sample Problem Described Above:<br />
Applying STAGE 1 of our approach <strong>to</strong> <strong>the</strong> set of requirements<br />
22
To start with, let us analyze <strong>the</strong> requirements and try <strong>to</strong> find out which requirements<br />
can have technical and business risks involved.<br />
Requirement 1: Ability <strong>to</strong> export <strong>the</strong> data in MS excel.<br />
1. Analysis: The requirement is not very clear as it does not point out what all<br />
fields of <strong>the</strong> data are <strong>to</strong> be captured in <strong>the</strong> Excel –Sheet.<br />
2. Tag Found: Looking at table 7 we found that <strong>the</strong> requirement has a tag data<br />
associated with it. Data is a generic word and unless specified very clearly can<br />
lead <strong>to</strong> possible hidden assumption.<br />
3. Risks involved: A major risk involved here could be <strong>the</strong> quantum of data that<br />
goes in<strong>to</strong> <strong>the</strong> excel sheet.<br />
Requirement 2: Notify staff of volunteer birthday.<br />
1. Analysis: The requirement is not very concise, what kind of notification is <strong>to</strong><br />
be send (email, sms, pop up).<br />
2. Tag Found: Looking at table 7 we found that <strong>the</strong> requirement has a tag notify<br />
associated with it. If <strong>the</strong> word ‘notify’ is not used in <strong>the</strong> conjunction with <strong>the</strong><br />
notification type than it can lead <strong>to</strong> hidden assumptions.<br />
3. Risks involved: What If <strong>the</strong> volunteer declines <strong>to</strong> mention his/her birthday. In<br />
addition, different notifications can have different technical and business<br />
repercussions.<br />
23
Requirement 3 : Allocate volunteers on a special date of service.<br />
1. Analysis : The line special date of service needs <strong>to</strong> be more elaborative and<br />
explicit<br />
2. Tag found : None<br />
3. Risks involved: Although no tags found in this requirement but it still may<br />
have a risk associated with it. What if volunteer is not available on that day or<br />
<strong>the</strong> mail server goes down and application is not able <strong>to</strong> notify <strong>the</strong> Volunteer.<br />
Requirement 4: Interact with a client database (not yet created) so we can assign<br />
volunteer men<strong>to</strong>rs <strong>to</strong> clients.<br />
1. Analysis: No clear mention of how <strong>the</strong> volunteers will be assigned <strong>to</strong> <strong>the</strong><br />
clients.<br />
2. Tag Found : None<br />
3. Risk involved: How will we manage <strong>the</strong> volunteer sharing in case multiple<br />
clients require <strong>the</strong> same volunteer.<br />
Applying STAGE 2 of our approach <strong>to</strong> <strong>the</strong> set of risks identified in stage 1<br />
In this stage we prioritize, <strong>the</strong> risks identify in stage 1. Considering <strong>the</strong> business goals<br />
of <strong>the</strong> system, we rank <strong>the</strong>m according <strong>to</strong> <strong>the</strong> most severe ones <strong>to</strong> <strong>the</strong> minor ones.<br />
24
After analyzing <strong>the</strong> business goals, we come up with <strong>the</strong> following list of risks<br />
according <strong>to</strong> priority.<br />
1. Allocation of <strong>the</strong> resources<br />
2. Quantum of data in <strong>the</strong> excel sheets.<br />
3. Notification type <strong>to</strong> <strong>the</strong> volunteers.<br />
4. Mail server down.<br />
Applying STAGE 3 on <strong>the</strong> risk identified<br />
Now after we identify <strong>the</strong> risks involved we go <strong>to</strong> <strong>the</strong> risk mitigation stage of <strong>the</strong><br />
RMF where we try <strong>to</strong> find out <strong>the</strong> mitigation strategies <strong>to</strong> solve <strong>the</strong> risks. Here we<br />
would be applying <strong>the</strong> cause and effect fish bone methodology <strong>to</strong> dig more on what<br />
can cause <strong>the</strong>se risks <strong>to</strong> happen.<br />
Requirement 1: Ability <strong>to</strong> export <strong>the</strong> data in MS Excel.<br />
1. Risk identified: Quantum of data in excels.<br />
2. Cause and Effect analysis :<br />
Poor data normalization in <strong>the</strong> database<br />
User selected all data with no filters<br />
25<br />
Quantum of data in excels.<br />
Redundant data was not taken care.<br />
Figure 7 - Cause and Effect Analysis of <strong>the</strong> Quantum of Data in Excel.
Possible Assumptions: The possible hidden assumptions for <strong>the</strong> risk after applying <strong>the</strong><br />
cause and effect analysis are:<br />
1. While generating <strong>the</strong> report <strong>the</strong> user will use one of <strong>the</strong> filters for <strong>the</strong> report.<br />
2. There will be unique data inserted in <strong>the</strong> database.<br />
3. Database is robust enough <strong>to</strong> handle huge chunks of data.<br />
4. Client has MS office installed on its machine.<br />
The possible effect of <strong>the</strong> above causes can be quite serious.<br />
1. It can lead <strong>to</strong> a buffer overflow error in case <strong>the</strong> number of records is more<br />
than 65,000. This is because <strong>the</strong> Microsoft excel does not support more than<br />
65,000 rows of data.<br />
2. There could be some fields in <strong>the</strong> report that are not supported by <strong>the</strong><br />
Microsoft API; this can lead <strong>to</strong> introduction of corrupt data.<br />
3. The reports will cease <strong>to</strong> work if <strong>the</strong> system does not find <strong>the</strong> Microsoft APIs<br />
on <strong>the</strong> client.<br />
Conclusion: Using our risk mitigation strategy we have successfully revealed that<br />
if not catered properly <strong>the</strong> bulk of data in <strong>the</strong> excel sheet can lead <strong>to</strong> some serious<br />
problems. Similarly, we can apply <strong>the</strong> cause and effect approach <strong>to</strong> o<strong>the</strong>r set of<br />
requirements <strong>to</strong> dig in<strong>to</strong> <strong>the</strong> real causes of <strong>the</strong> risks. Here are <strong>the</strong> cause and effect<br />
analysis for o<strong>the</strong>r requirements.<br />
26
Popup<br />
Email<br />
SMS<br />
Natural Calamity.<br />
Hardware Failure<br />
Power outage.<br />
Notification Type<br />
Mail Server down<br />
27<br />
Resource for required technology not available<br />
Resource is already allocated<br />
Resource Allocation.<br />
Figure 8 - Cause and Effect Analysis of <strong>the</strong> Requirements 2, 3 and 4.
Applying STAGE 4 <strong>to</strong> <strong>the</strong> risk mitigation strategy identified in stage 3<br />
Let us take <strong>the</strong> first requirement and apply stage 4 on that.<br />
We redraft our requirement in<strong>to</strong> set of 4 requirements so that it does not have any<br />
hidden assumptions.<br />
1. The system should have <strong>the</strong> ability <strong>to</strong> export <strong>the</strong> data generated in <strong>the</strong><br />
volunteer Work hours screen in<strong>to</strong> <strong>the</strong> MS excel sheet 2007.<br />
2. If <strong>the</strong> number of records exported is more than 65000 records <strong>the</strong> first 65000<br />
records should be inserted in<strong>to</strong> <strong>the</strong> first sheet of <strong>the</strong> sheet and any o<strong>the</strong>r<br />
records should be put in<strong>to</strong> <strong>the</strong> o<strong>the</strong>r worksheet of <strong>the</strong> excel file.<br />
3. Proper type checking should be done so that <strong>the</strong>re is no data mismatch or<br />
corrupted data in <strong>the</strong> sheet.<br />
4. The client should have MS office 2007 installed on its system.<br />
4.2 Solution Strengths and Benefits<br />
1. Risk analysis is good general-purpose yardstick by which we can judge our<br />
security design’s effectiveness. Because roughly 50% of our problems are <strong>the</strong><br />
result of requirement flaws, we perform our technique at <strong>the</strong> requirement<br />
phase identify hidden assumptions as early possible.<br />
2. By considering <strong>the</strong> resulting ranked risks, business stakeholders can determine<br />
how <strong>to</strong> manage particular risks and what could be <strong>the</strong> most cost effective<br />
controls.<br />
28
3. The major fac<strong>to</strong>r that makes fishbone strategy successful is <strong>the</strong> increased<br />
knowledge of <strong>the</strong> process, helping everyone <strong>to</strong> learn more about <strong>the</strong> fac<strong>to</strong>rs at<br />
work and how <strong>the</strong>y relate <strong>to</strong> each o<strong>the</strong>r. It easily identifies areas for fur<strong>the</strong>r<br />
study where <strong>the</strong>re is lack of sufficient information.<br />
4.3 Solution Constraints<br />
Thus we see through <strong>the</strong> examples that applying <strong>the</strong> 3 methodologies does yield<br />
hidden assumptions which o<strong>the</strong>rwise would have been hidden and could have caused<br />
damage in <strong>the</strong> later stages of <strong>the</strong> SDLC.<br />
However, <strong>the</strong> solution also has some constraints, which may restrict it <strong>to</strong> find all <strong>the</strong><br />
hidden assumptions. Some of <strong>the</strong>m are:<br />
1. The scope of <strong>the</strong> solution is limited <strong>to</strong> <strong>the</strong> three methodologies; Risk<br />
management, Fish bone cause and effect and <strong>the</strong> tag detection methodology<br />
[4] [9].<br />
2. Risk analysis output is difficult <strong>to</strong> apply directly <strong>to</strong> modern software design<br />
structures.<br />
3. Solution does not provide an easy guide of all potential vulnerabilities and<br />
threat <strong>to</strong> consider at a component/environment level. This is why a large<br />
knowledge base and lots of experience is required.<br />
4. The major constraint with <strong>the</strong> fishbone technique is it is inefficiency for<br />
extremely complex problems, where many causes and many problems are<br />
interrelated.<br />
5. Fish bone diagrams does not clarify <strong>the</strong> sequence of <strong>the</strong> causes.<br />
29
CHAPTER 5<br />
TAG DETECTOR <strong>SYSTEM</strong><br />
Tag detec<strong>to</strong>r is a web-based <strong>to</strong>ol made in ASP.net, which helps in detecting <strong>the</strong><br />
hidden assumptions inside <strong>the</strong> non-functional software requirement by using <strong>the</strong> tag<br />
detection approach discussed in Chapter 4. The system scans all <strong>the</strong> requirements line<br />
by line and tries <strong>to</strong> find <strong>the</strong> tags inside <strong>the</strong> requirements, which can cause <strong>the</strong> system<br />
<strong>to</strong> fail. This section talks about <strong>the</strong> requirements of <strong>the</strong> system in detail, its design, its<br />
constraints followed by <strong>the</strong> detailed description of <strong>the</strong> screens and <strong>the</strong> database<br />
structure.<br />
5.1 Tag Detec<strong>to</strong>r Requirements<br />
The Tag Detec<strong>to</strong>r requirements are classified in<strong>to</strong> three parts. User Management<br />
Requirements, Tag Management Requirements and NFR Management Requirements.<br />
This is followed by <strong>the</strong> requirements for <strong>the</strong> main<br />
5.1.1 User Management Requirements<br />
The following are <strong>the</strong> functional requirements of <strong>the</strong> Tag Detec<strong>to</strong>r, which a registered<br />
user for <strong>the</strong> Tag Detec<strong>to</strong>r should be able <strong>to</strong> perform.<br />
1. The system should allow <strong>the</strong> new user <strong>to</strong> register <strong>to</strong> <strong>the</strong> Tag Detec<strong>to</strong>r system in<br />
case he/she has not been registered.<br />
2. The system shall check <strong>the</strong> database for any existing entry in <strong>the</strong> database for<br />
<strong>the</strong> same user.<br />
30
3. The system should notify <strong>the</strong> user if <strong>the</strong> username already exists and should<br />
ask <strong>the</strong>m <strong>to</strong> opt for a different user name.<br />
4. The system should make sure that <strong>the</strong> user enters all <strong>the</strong> required fields while<br />
adding <strong>the</strong> user <strong>to</strong> <strong>the</strong> system.<br />
5. The system should notify <strong>the</strong> user when <strong>the</strong> user is successfully registered in<strong>to</strong><br />
<strong>the</strong> system.<br />
6. The user should be able <strong>to</strong> login in<strong>to</strong> <strong>the</strong> system with <strong>the</strong> registered user name<br />
and password.<br />
7. The system shall provide <strong>the</strong> forget password functionality <strong>to</strong> <strong>the</strong> user in case<br />
<strong>the</strong> user forgets <strong>the</strong> password.<br />
8. The system shall email <strong>the</strong> user <strong>the</strong> password on <strong>the</strong> basis of <strong>the</strong> username<br />
entered.<br />
9. The system shall provide <strong>the</strong> user <strong>the</strong> change password functionality <strong>to</strong> change<br />
<strong>the</strong> password whenever <strong>the</strong>y want.<br />
10. The system should have <strong>the</strong> User Management screen for <strong>the</strong> admin users<br />
where <strong>the</strong>y can view all <strong>the</strong> usernames and <strong>the</strong>ir email ids for system<br />
maintenance purpose.<br />
11. The system shall allow <strong>the</strong> admin user <strong>to</strong> add, edit or delete <strong>the</strong> user from <strong>the</strong><br />
Tag Detec<strong>to</strong>r System.<br />
31
5.1.2 Tag Management Requirements<br />
The following are <strong>the</strong> functional requirements for <strong>the</strong> Tag Management module for<br />
<strong>the</strong> Tag Detec<strong>to</strong>r <strong>to</strong>ol.<br />
1. The system shall allow <strong>the</strong> user <strong>to</strong> add more tags in<strong>to</strong> <strong>the</strong> database based on<br />
<strong>the</strong> non-functional requirement parameter selected.<br />
2. The system shall check if <strong>the</strong> tag already exists in <strong>the</strong> database.<br />
3. The system should notify <strong>the</strong> user in case <strong>the</strong> tag already exists in <strong>the</strong><br />
database.<br />
4. The system shall allow <strong>the</strong> user <strong>to</strong> edit <strong>the</strong> existing tags in <strong>the</strong> database.<br />
5. The system shall allow <strong>the</strong> user <strong>to</strong> delete <strong>the</strong> tags from <strong>the</strong> database.<br />
5.1.3 NFR Management Requirements<br />
The following are <strong>the</strong> functional requirements for <strong>the</strong> NFR Management module for<br />
<strong>the</strong> Tag Detec<strong>to</strong>r <strong>to</strong>ol.<br />
1. The system shall allow <strong>the</strong> user <strong>to</strong> add more NFR in<strong>to</strong> <strong>the</strong> database.<br />
2. The system should notify <strong>the</strong> user in case <strong>the</strong> NFR already exists in <strong>the</strong><br />
database.<br />
3. The system shall allow <strong>the</strong> user <strong>to</strong> edit <strong>the</strong> existing NFR in <strong>the</strong> database.<br />
4. The system shall allow <strong>the</strong> user <strong>to</strong> delete <strong>the</strong> NFR from <strong>the</strong> database.<br />
5.1.4 Assumption Management Requirements<br />
1. The system shall allow <strong>the</strong> user <strong>to</strong> upload <strong>the</strong> requirements using <strong>the</strong> upload<br />
document functionality.<br />
32
2. The system shall display <strong>the</strong> requirements uploaded in <strong>the</strong> screen in <strong>the</strong><br />
following format :<br />
1. Req ID.<br />
2. Requirement.<br />
3. The system shall perform <strong>the</strong> tag detection for one requirement per time.<br />
4. The system shall allow <strong>the</strong> user <strong>to</strong> clear <strong>the</strong> requirements.<br />
5. The system shall provide <strong>the</strong> dropdown for all <strong>the</strong> NFR in <strong>the</strong> system.<br />
6. The system shall scan all <strong>the</strong> lines of <strong>the</strong> requirements and search for <strong>the</strong> tag<br />
based on <strong>the</strong> NFR criterion selected in <strong>the</strong> dropdown.<br />
7. The system shall summarize <strong>the</strong> findings on <strong>the</strong> screen in <strong>the</strong> following<br />
format:<br />
1. Req ID.<br />
2. Requirement.<br />
3. Faulty Word.<br />
4. NFR Type.<br />
5.1.5 Tag Detec<strong>to</strong>r Assumptions<br />
1. The requirements for <strong>the</strong> analysis should be in <strong>the</strong> .xls template format.<br />
2. Client has MS office installed on its system.<br />
5.1.6 O<strong>the</strong>r Information<br />
Tag detec<strong>to</strong>r is built in ASP.net 4.0 with SQL Server 2008 as <strong>the</strong> database. The<br />
system uses Telerik ASP.net AJAX suite for displaying <strong>the</strong> information in <strong>the</strong> grid<br />
and is compatible in all <strong>the</strong> browsers.<br />
33
5.2 Use Cases<br />
5.2.1 User Management Use Case<br />
Figure below shows <strong>the</strong> use case for <strong>the</strong> User Management module. There are 2 main<br />
ac<strong>to</strong>rs in <strong>the</strong> User management module i.e. Tag Detec<strong>to</strong>r user and Admin. The Admin<br />
user has <strong>the</strong> access <strong>to</strong> all <strong>the</strong> users and can add/edit/delete any user from <strong>the</strong> system.<br />
Individual Tag Detec<strong>to</strong>r user can register itself, login and can use <strong>the</strong> modules like<br />
forget password and change password.<br />
Figure 9 - Use Case Diagram for <strong>the</strong> User Management Module<br />
34
5.2.2 Tag Management Use Case<br />
The use case diagram for <strong>the</strong> Tag Management module consists of one ac<strong>to</strong>r and three<br />
components. Ac<strong>to</strong>r comprises of <strong>the</strong> Tag Detec<strong>to</strong>r user and it has <strong>the</strong> ability <strong>to</strong> add a<br />
tag <strong>to</strong> <strong>the</strong> system, edit <strong>the</strong> existing tag in <strong>the</strong> system and delete <strong>the</strong> tag from <strong>the</strong><br />
system.<br />
Preconditions<br />
The following pre-conditions must be true <strong>to</strong> initiate this Use Case.<br />
1. User has logged in<strong>to</strong> <strong>the</strong> System.<br />
Figure 10 - Use Case Diagram for <strong>the</strong> Tag Management Module<br />
35
5.2.3 NFR Management Use Case.<br />
The use case diagram for NFR Management module consists of one ac<strong>to</strong>r and three<br />
components. Ac<strong>to</strong>r comprises of <strong>the</strong> NFR Management user and it has <strong>the</strong> ability <strong>to</strong><br />
add, edit and delete <strong>the</strong> NFRs inside <strong>the</strong> system.<br />
Preconditions<br />
The following pre-conditions must be true <strong>to</strong> initiate this Use Case.<br />
1. User has logged in<strong>to</strong> <strong>the</strong> System.<br />
Figure 11 - Use Case Diagram for <strong>the</strong> NFR Management Module<br />
36
5.3 Data Flow Diagram<br />
Figure 12 displays <strong>the</strong> data flow diagram between <strong>the</strong> different components of <strong>the</strong> Tag<br />
Detec<strong>to</strong>r system and its attributes.<br />
ID<br />
Users<br />
Name<br />
NFR<br />
NfrDescription<br />
eMail<br />
Password<br />
NFR Type<br />
Description<br />
Req Mapping<br />
nfrTypeID<br />
NfrWord<br />
Desc<br />
Figure 12 - Data Flow Diagram for <strong>the</strong> Tag Detec<strong>to</strong>r.<br />
RiskID<br />
37
5.4 Database Structure<br />
The Database is composed of three main tables namely NFRDescription table, Users<br />
table and Reqmapping table. NFRDescription is <strong>the</strong> lookup table that consists of <strong>the</strong><br />
record of all <strong>the</strong> NFRs that is being used in <strong>the</strong> mapping. The Requirement mapping<br />
table consists of <strong>the</strong> mapping of all <strong>the</strong> NFR types and <strong>the</strong> words associated with it.<br />
Users table consists of <strong>the</strong> record of <strong>the</strong> users in <strong>the</strong> system along with <strong>the</strong>ir email IDs<br />
and password.<br />
Figure 13 - Database Structure for Tag Detec<strong>to</strong>r.<br />
38
5.5 Architecture of <strong>the</strong> Tag Detec<strong>to</strong>r.<br />
The Tag Detec<strong>to</strong>r systems architecture consists of two basic layer, <strong>the</strong> web pages and<br />
<strong>the</strong> user controls composes <strong>the</strong> Presentation layer , <strong>the</strong> code behind page forms <strong>the</strong><br />
business logic layer which consists of all <strong>the</strong> logic which in turn interacts with <strong>the</strong><br />
SQL server database. ADO.net is used for <strong>the</strong> communication between <strong>the</strong> web pages<br />
and <strong>the</strong> database.<br />
Presentation Layer<br />
ASP.net Webpages, User Controls and Telerik Grids.<br />
Business Logic Layer<br />
ASP.net Code behind<br />
SQL Server<br />
Figure 14 - Architecture of Tag Detec<strong>to</strong>r.<br />
39
5.6 Tag Detec<strong>to</strong>r Screen<br />
5.6.1 User Management Screens<br />
1. Register User Screen.<br />
The Add user screen allows <strong>the</strong> user <strong>to</strong> register in<strong>to</strong> <strong>the</strong> Tag Detec<strong>to</strong>r system.<br />
The go back but<strong>to</strong>n takes <strong>the</strong> user back <strong>to</strong> <strong>the</strong> login page.<br />
2. Forget Password Screen.<br />
Figure 15 - Register User Screen.<br />
The Forget Password screen allows <strong>the</strong> user <strong>to</strong> retrieve <strong>the</strong> lost password<br />
based on <strong>the</strong> correct username entered. The password is send <strong>to</strong> <strong>the</strong> user in <strong>the</strong><br />
email entered during <strong>the</strong> registration.<br />
Figure 16 - Forget Password Screen.<br />
40
3. Change Password Screen.<br />
The change password screen allows <strong>the</strong> user <strong>to</strong> change his/her password. The<br />
system prompts <strong>the</strong> user <strong>to</strong> re-enter <strong>the</strong> old password twice and notifies <strong>the</strong><br />
user in case <strong>the</strong> old password is incorrect.<br />
4. Login Screen<br />
Figure 17 - Change Password Screen.<br />
The login screen allows <strong>the</strong> user <strong>to</strong> log in <strong>to</strong> <strong>the</strong> system if <strong>the</strong> credentials<br />
entered are correct.<br />
Figure 18 - Login Screen.<br />
41
5. User Management Screen<br />
The user management screen is used by <strong>the</strong> admin for adding, editing and<br />
deleting any user from <strong>the</strong> Tag Detec<strong>to</strong>r system. (This is additional <strong>to</strong> <strong>the</strong><br />
register user discussed in 1)<br />
Figure 19 - User Management Screen.<br />
Figure 20 - Edit user Screen.<br />
42
5.6.2 Tag Management Screen<br />
1. Tag Management Grid (View)<br />
The Tag Management Screen has all <strong>the</strong> tags displayed on <strong>the</strong> screen along<br />
with <strong>the</strong> NFR type. We can view <strong>the</strong> different tags for <strong>the</strong> different NFR type<br />
by selecting <strong>the</strong> different NFR type from <strong>the</strong> dropdown.<br />
2. Tag Management Grid (Add View)<br />
Figure 21 - Tag Management Screen.<br />
On clicking <strong>the</strong> add Tag link in <strong>the</strong> grid <strong>the</strong> system opens <strong>the</strong> add view and<br />
allows <strong>the</strong> user <strong>to</strong> add <strong>the</strong> new Tag.<br />
43
3. Tag Management Grid (Edit View)<br />
Figure 22 - Add Tag Screen.<br />
On clicking <strong>the</strong> edit tag but<strong>to</strong>n from <strong>the</strong> grid, <strong>the</strong> grid opens in <strong>the</strong> edit mode.<br />
On clicking <strong>the</strong> update tag but<strong>to</strong>n <strong>the</strong> tag description in <strong>the</strong> database is<br />
updated. Cancel but<strong>to</strong>n cancels <strong>the</strong> operation and takes user back <strong>to</strong> <strong>the</strong> view<br />
grid mode. (See figure below).<br />
Figure 23 - Edit Tag Screen.<br />
44
4. Tag Management Grid (Delete)<br />
On clicking <strong>the</strong> red delete icon in <strong>the</strong> tag management grid, <strong>the</strong> system<br />
prompts <strong>the</strong> user with <strong>the</strong> message that “Are you sure you want <strong>to</strong> delete this<br />
tag”.<br />
5.6.3 NFR Management Screen<br />
1. NFR Management Grid (View)<br />
Figure 24 - Delete Tag Screen.<br />
The NFR Management Screen has all <strong>the</strong> NFR displayed on <strong>the</strong> screen along<br />
with <strong>the</strong> NFR type ID.<br />
45
2. NFR Management Grid (Add View)<br />
Figure 25 - NFR Management Screen.<br />
On clicking <strong>the</strong> add NFR link in <strong>the</strong> grid <strong>the</strong> system prompts <strong>the</strong> add view and<br />
allows <strong>the</strong> user <strong>to</strong> add <strong>the</strong> new NFR. On clicking Add NFR, <strong>the</strong> new NFR is<br />
added in<strong>to</strong> <strong>the</strong> database.<br />
Figure 26 - Add NFR Screen.<br />
46
3. NFR Management Grid (Edit View)<br />
On clicking <strong>the</strong> edit tag but<strong>to</strong>n from <strong>the</strong> grid, <strong>the</strong> grid opens in <strong>the</strong> edit mode.<br />
On clicking <strong>the</strong> update tag but<strong>to</strong>n <strong>the</strong> NFR description in <strong>the</strong> database is<br />
updated. Cancel but<strong>to</strong>n cancels <strong>the</strong> operation and takes user back <strong>to</strong> <strong>the</strong> view<br />
grid mode. The system notifies <strong>the</strong> user that <strong>the</strong> NFR has been updated<br />
successfully.<br />
4. NFR Management Grid (Delete)<br />
Figure 27 - Edit NFR Screen.<br />
On clicking <strong>the</strong> red delete icon in <strong>the</strong> tag management grid, <strong>the</strong> system<br />
prompts <strong>the</strong> user with <strong>the</strong> message that “Are you sure you want <strong>to</strong> delete this<br />
tag”. On affirmation, <strong>the</strong> system deletes <strong>the</strong> tag from <strong>the</strong> database and cancels<br />
it o<strong>the</strong>rwise (See figure below).<br />
47
5.6.4 Assumption Management Screen.<br />
Figure 28 - Delete NFR Screen.<br />
When no requirement is selected by <strong>the</strong> user than <strong>the</strong> system displays a<br />
“No Requirement “found message. This screen is also displayed when <strong>the</strong><br />
requirements are cleared by clicking <strong>the</strong> clear requirement but<strong>to</strong>n.<br />
Figure 29 - No Requirement Uploaded Screen.<br />
48
When <strong>the</strong> user selects <strong>the</strong> requirement and clicks <strong>the</strong> upload requirement but<strong>to</strong>n.<br />
The requirements are displayed in <strong>the</strong> grid with <strong>the</strong> Req ID and Requirement<br />
description columns respectively.<br />
Figure 30 - Requirement Uploaded Screen.<br />
When user selects <strong>the</strong> NFR type from <strong>the</strong> NFR type dropdown. After selecting<br />
and uploading <strong>the</strong> requirements when <strong>the</strong> user selects <strong>the</strong> NFR type from <strong>the</strong><br />
dropdown than <strong>the</strong> user scans <strong>the</strong> requirement word by word and tries <strong>to</strong> find a<br />
match for <strong>the</strong> tag in <strong>the</strong> requirement for <strong>the</strong> NFR type selected in <strong>the</strong><br />
dropdown. At any point of time, <strong>the</strong> user believes that <strong>the</strong> tag for that NFR<br />
49
type needs <strong>to</strong> be updated / added or deleted <strong>the</strong>n he can go <strong>to</strong> <strong>the</strong> NFR<br />
management module and can do <strong>the</strong> same.<br />
5.7 Tag Detec<strong>to</strong>r Strengths and Weaknesses<br />
Strength<br />
Figure 31 - Assumption Management Screen.<br />
1. Tag Detec<strong>to</strong>r system provides an intuitive way of risk and assumption<br />
detection inside <strong>the</strong> requirements.<br />
2. With configurable tag functionality, we can add / edit or delete any number of<br />
tags inside <strong>the</strong> requirements.<br />
3. By detecting <strong>the</strong> Tags at very early stages of <strong>the</strong> requirement we prevent <strong>the</strong><br />
project from risks which o<strong>the</strong>rwise could have been detected at very later<br />
stages of <strong>the</strong> project.<br />
50
Weaknesses<br />
1. The system uses <strong>the</strong> tags, which are s<strong>to</strong>red and maintained based on <strong>the</strong> NFR<br />
type, <strong>the</strong>re is no intuitive way <strong>to</strong> apply this approach on <strong>the</strong> functional<br />
requirements.<br />
2. The tag detection if not followed by risk mitigation and risk validation can still<br />
lead <strong>to</strong> assumptions inside <strong>the</strong> requirements.<br />
51
6.1 Conclusion<br />
CHAPTER 6<br />
CONCLUSION<br />
This project solution provides all <strong>to</strong>ge<strong>the</strong>r a new way of detecting <strong>the</strong> hidden<br />
assumptions inside <strong>the</strong> software requirements by applying <strong>the</strong> fishbone methodology<br />
and tag detection approach <strong>to</strong> <strong>the</strong> Risk Management Framework. If applied properly<br />
<strong>the</strong> solution can be a great <strong>to</strong>ol <strong>to</strong> detect some of <strong>the</strong> hidden assumptions inside <strong>the</strong><br />
requirements. The approach is complemented by <strong>the</strong> Tag Detec<strong>to</strong>r software, which<br />
helps in detecting <strong>the</strong> faulty words inside <strong>the</strong> requirements with ease.<br />
6.2 Future Work<br />
There can be a lot of work that can be done fur<strong>the</strong>r on this <strong>to</strong>pic. Elaborative analysis of <strong>the</strong><br />
impact of tag detection on finding <strong>the</strong> assumptions in <strong>the</strong> requirements, a software <strong>to</strong>ol<br />
implementing <strong>the</strong> suggested new model for <strong>the</strong> risk management system, Analysis of <strong>the</strong><br />
impact of <strong>the</strong> new framework on <strong>the</strong> software failures are some of <strong>the</strong> areas where we can do<br />
fur<strong>the</strong>r research. A lot of future work can also been done on <strong>the</strong> Tag detec<strong>to</strong>r <strong>to</strong>ol ,<br />
associating risks , integrating <strong>the</strong> whole RMF and reporting are some of <strong>the</strong> areas where <strong>the</strong><br />
application can be fur<strong>the</strong>r extended.<br />
52
APPENDIX A<br />
CODE SNIPPET: <strong>ASSUMPTION</strong><strong>MANAGEMENT</strong>.ASPX<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
53
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
54
APPENDIX B<br />
CODE SNIPPET: <strong>ASSUMPTION</strong><strong>MANAGEMENT</strong>.CS<br />
using System;<br />
using System.Collections.Generic;<br />
using System.Linq;<br />
using System.Web;<br />
using System.Web.UI;<br />
using System.Web.UI.WebControls;<br />
using System.Data.OleDb;<br />
using System.Data;<br />
using System.Configuration;<br />
using System.Reflection;<br />
using Excel = Microsoft.Office.Interop.Excel;<br />
using System.Data.SqlClient;<br />
using Telerik.Web.UI;<br />
using System.IO;<br />
public partial class Webpages_AssumptionManagement : System.Web.UI.Page<br />
{<br />
public class myTags<br />
{<br />
public string RequirementID { get; set; }<br />
public string Requirement { get; set; }<br />
public string FaultyWord { get; set; }<br />
public string nfrType { get; set; }<br />
}<br />
public bool isRequirements { get; set; }<br />
protected void Page_Load(object sender, EventArgs e)<br />
{<br />
if (!Page.IsPostBack)<br />
{<br />
populateNFRTypes();<br />
}<br />
}<br />
protected void GridDataSource(object source, GridNeedDataSourceEventArgs e)<br />
{<br />
PopulateRequirements();<br />
}<br />
private void populateNFRTypes()<br />
{<br />
SqlConnection conn = new SqlConnection(@"Data Source=AYUSH-PC\SQLEXPRESS;Initial<br />
Catalog=AssumptionManagement;Integrated Security=True");<br />
SqlDataAdapter da = new SqlDataAdapter();<br />
SqlCommand cmd = conn.CreateCommand();<br />
cmd.CommandText = "Select nfrtypeID,nfrtypedescription from nfrDescription";<br />
da.SelectCommand = cmd;<br />
DataSet ds = new DataSet();<br />
conn.Open();<br />
da.Fill(ds);<br />
conn.Close();<br />
cboNFRTypes.Items.Clear();<br />
cboNFRTypes.DataTextField = "nfrTypeDescription";<br />
cboNFRTypes.DataValueField = "nfrTypeID";<br />
cboNFRTypes.DataSource = ds.Tables[0];<br />
cboNFRTypes.DataBind();<br />
cboNFRTypes.Items.Insert(0, new RadComboBoxItem("- Select NFR Type -", string.Empty));<br />
55
}<br />
private void PopulateRequirements()<br />
{<br />
lblmessage.Text = "";<br />
var file = Direc<strong>to</strong>ry.GetFiles(Server.MapPath("~/Requirements"))<br />
.FirstOrDefault();<br />
if(file == null)<br />
{<br />
isRequirements = false;<br />
lblmessage.Text = "No Requirements found.Please upload it <strong>to</strong> continue.";<br />
}<br />
else<br />
{<br />
isRequirements = true;<br />
gridRequirements.DataSource = GetRequirements();//DataSource <strong>to</strong> GrigView(Id:gvOne)<br />
}<br />
}<br />
private DataTable GetRequirements()<br />
{<br />
var file = Direc<strong>to</strong>ry.GetFiles(Server.MapPath("~/Requirements"))<br />
.FirstOrDefault();<br />
Excel.Application appExl;<br />
Excel.Workbook workbook;<br />
Excel.Worksheet NwSheet;<br />
Excel.Range ShtRange;<br />
appExl = new Excel.ApplicationClass();<br />
workbook = appExl.Workbooks.Open(file, Missing.Value, Missing.Value, Missing.Value, Missing.Value, Missing.Value,<br />
Missing.Value, Missing.Value, Missing.Value, Missing.Value, Missing.Value, Missing.Value, Missing.Value, Missing.Value,<br />
Missing.Value);<br />
NwSheet = (Excel.Worksheet)workbook.Sheets.get_Item(1);<br />
int Cnum = 0;<br />
int Rnum = 0;<br />
ShtRange = NwSheet.UsedRange; //gives <strong>the</strong> used cells in sheet<br />
//Reading Excel file.<br />
//Creating datatable <strong>to</strong> read <strong>the</strong> containt of <strong>the</strong> Sheet in File.<br />
DataTable dt = new DataTable();<br />
dt.Columns.Add("ID");<br />
dt.Columns.Add("Requirement");<br />
for (Rnum = 1; Rnum
\<br />
protected void cmdUpload_Click(object sender, EventArgs e)<br />
{<br />
var fileExists = Direc<strong>to</strong>ry.GetFiles(Server.MapPath("~/Requirements"))<br />
.FirstOrDefault();<br />
RadUpload RadUpload1 = uploadRequirement;<br />
UploadedFile file = RadUpload1.UploadedFiles[0];<br />
if (fileExists == null)<br />
{<br />
string targetFolder = Server.MapPath(RadUpload1.TargetFolder);<br />
string targetFileName = System.IO.Path.Combine(targetFolder,<br />
file.GetNameWithoutExtension() + file.GetExtension());<br />
file.SaveAs(targetFileName);<br />
}<br />
else<br />
{<br />
System.IO.Direc<strong>to</strong>ryInfo downloadedMessageInfo = new Direc<strong>to</strong>ryInfo(Server.MapPath("~/Requirements"))<br />
foreach (FileInfo files in downloadedMessageInfo.GetFiles())<br />
{<br />
files.Delete();<br />
}<br />
string targetFolder = Server.MapPath(RadUpload1.TargetFolder);<br />
string targetFileName = System.IO.Path.Combine(targetFolder,<br />
file.GetNameWithoutExtension() + file.GetExtension());<br />
file.SaveAs(targetFileName);<br />
gridRequirements.Rebind();<br />
}<br />
}<br />
private void findTagsForHiddenAssumptions(DataTable dtRequirements)<br />
{<br />
if (cboNFRTypes.SelectedItem.Value != string.Empty)<br />
{<br />
gridRequirements.DataSource = null;<br />
int nfrTypeID = int.Parse(cboNFRTypes.SelectedItem.Value.ToString());<br />
AssumptionPanel.Visible = true;<br />
string connectionString = @"Data Source=AYUSH-PC\SQLEXPRESS;Initial<br />
Catalog=AssumptionManagement;Integrated Security=True";<br />
string sql = "SELECT * FROM ReqMapping where nfrtypeid = " + nfrTypeID;<br />
DataTable myTable = new DataTable();<br />
List TagsFound = new List();<br />
List newList = new List();<br />
List tagList = new List();<br />
using (SqlConnection myConnection = new SqlConnection(connectionString))<br />
{<br />
using (SqlCommand myCommand = new SqlCommand(sql, myConnection))<br />
{<br />
myConnection.Open();<br />
using (SqlDataReader myReader = myCommand.ExecuteReader())<br />
{<br />
}<br />
}<br />
}<br />
myTable.Load(myReader);<br />
myConnection.Close();<br />
for (int j = 0; j < dtRequirements.Rows.Count; j++)<br />
{<br />
string[] str = dtRequirements.Rows[j][1].ToString().Split(' ');<br />
for (int i = 0; i < str.Length; i++)<br />
57
{<br />
for (int k = 0; k < myTable.Rows.Count; k++)<br />
{<br />
if (str[i].Contains(myTable.Rows[k][1].ToString()))<br />
{<br />
TagsFound.Add("ReqID " + (j + 1) + "," + dtRequirements.Rows[j][1] + ",Faulty Words : " +<br />
myTable.Rows[k][1].ToString());<br />
}<br />
}<br />
}<br />
}<br />
int counter = 1;<br />
foreach (string s in TagsFound)<br />
{<br />
if (!newList.Contains(s))<br />
{<br />
newList.Add(s);<br />
}<br />
counter++;<br />
}<br />
string[] strFetchAssumption = null;<br />
for (int i = 0; i < newList.Count; i++)<br />
{<br />
strFetchAssumption = newList[i].Split(',');<br />
tagList.Add(new myTags { RequirementID = strFetchAssumption[0], Requirement = strFetchAssumption[1],<br />
FaultyWord = strFetchAssumption[2], nfrType = cboNFRTypes.SelectedItem.Text.ToString() });<br />
}<br />
}<br />
}<br />
AssumptionPanel.Visible = true;<br />
GridAssumptions.DataSource = tagList;<br />
protected void cmdClear_Click(object sender, EventArgs e)<br />
{<br />
try<br />
{<br />
System.IO.Direc<strong>to</strong>ryInfo downloadedMessageInfo = new Direc<strong>to</strong>ryInfo(Server.MapPath("~/Requirements"));<br />
foreach (FileInfo file in downloadedMessageInfo.GetFiles())<br />
{<br />
file.Delete();<br />
}<br />
58
}<br />
RadAjaxManager1.Alert("Requirements cleared Successfully");<br />
gridRequirements.Rebind();<br />
GridAssumptions.Rebind();<br />
}<br />
catch<br />
{<br />
RadAjaxManager1.Alert("Error Removing <strong>the</strong> Requirements");<br />
}<br />
}<br />
protected void GridAssumptionDataSource(object source, GridNeedDataSourceEventArgs e)<br />
{<br />
var file = Direc<strong>to</strong>ry.GetFiles(Server.MapPath("~/Requirements"))<br />
.FirstOrDefault();<br />
if (file != null)<br />
{ findTagsForHiddenAssumptions(GetRequirements()); }<br />
}<br />
protected void IndexChanged(object o, RadComboBoxSelectedIndexChangedEventArgs e)<br />
{<br />
var file = Direc<strong>to</strong>ry.GetFiles(Server.MapPath("~/Requirements"))<br />
.FirstOrDefault();<br />
}<br />
if (file != null)<br />
{ GridAssumptions.Rebind(); }<br />
else<br />
{ RadAjaxManager1.Alert("No requirements found .. !!!"); }<br />
59
Login Screen<br />
APPENDIX C<br />
USER GUIDE<br />
1. First page of <strong>the</strong> application is login page. Enter correct username and password <strong>to</strong><br />
proceed.<br />
2. For new users, click on <strong>the</strong> “Register” link on login page, enter <strong>the</strong><br />
3. Information required and click on submit but<strong>to</strong>n. After creating a new username,<br />
user can log in<strong>to</strong> <strong>the</strong> system using new username and password.<br />
4. In case of user forgetting <strong>the</strong> password, <strong>the</strong> user can go <strong>to</strong> <strong>the</strong> forget password link<br />
and can enter its user name and click send password. The password would be send<br />
<strong>to</strong> <strong>the</strong> user <strong>to</strong> <strong>the</strong> email address entered at <strong>the</strong> time of registering.<br />
5. In case, <strong>the</strong> user wants <strong>to</strong> change <strong>the</strong> password than <strong>the</strong> user can go <strong>to</strong> <strong>the</strong> change<br />
password link and do <strong>the</strong> same.<br />
Management Screen<br />
1. At any point in time if <strong>the</strong> user feels that any Tag or NFR needs <strong>to</strong> be added /<br />
updated or deleted than we can always go <strong>to</strong> <strong>the</strong> Tag Management or NFR<br />
management screens and do <strong>the</strong> same.<br />
Assumption Management<br />
1. After logging in <strong>the</strong> user sees, <strong>the</strong> assumption management page opened up .To<br />
start searching for tags first upload <strong>the</strong> requirement document that needs <strong>to</strong> be<br />
analyzed and click <strong>the</strong> upload requirement but<strong>to</strong>n.<br />
60
1. Please make sure <strong>the</strong> requirements are in <strong>the</strong> excel sheet in <strong>the</strong> desired<br />
template form.<br />
2. After uploading <strong>the</strong> requirement, <strong>the</strong> requirement should show up in <strong>the</strong><br />
screen in <strong>the</strong> grid beneath <strong>the</strong> Requirements heading.<br />
3. Select <strong>the</strong> NFR type from <strong>the</strong> dropdown for <strong>the</strong> type of NFR for which <strong>the</strong><br />
requirement needs <strong>to</strong> be analyzed.<br />
4. The assumption screen shows up below <strong>the</strong> dropdown in <strong>the</strong> grid with <strong>the</strong><br />
requirement, faulty word and type shown in <strong>the</strong> grid.<br />
61
REFERENCES<br />
[1]. Requirements Engineering for Time-To-Market <strong>Project</strong>s. McPhee, Alta.<br />
Eberlein.<br />
http://ieeexplore.ieee.org/xpl/articleDetails.jsp;jsessionid=hkzxQq0ZSpnhJkmvgRplT<br />
m5PL226n8SKM51CGvlxcMT5vNTPqMDn!1271855879?arnumber=999818&conte<br />
ntType=Conference+Publications<br />
[2]. Requirements Engineering for Product Development. IBM Corporation.<br />
ftp://ftp.software.ibm.com/software/plm/solutions/Requirements_Engineering.p df<br />
[3]. Hidden Assumptions Inside Requirements. MICRA, Inc. 1998.<br />
[4]. Risk Management Framework. Gary.E. McGraw.<br />
https://buildsecurityin.us-cert.gov/bsi/articles/best-practices/risk/250-BSI.html<br />
[5]. Assumption Management. Robert C.Seacord<br />
http://www.sei.cmu.edu/library/abstracts/news-at-sei/cotsspot1q03.cfm<br />
[6]. Hidden Assumptions: What You Do not Know Can Hurt You. Linda Hayes.<br />
http://www.stickyminds.com/sitewide.asp?ObjectId=11067<br />
[7]. Software Assumptions Lead <strong>to</strong> Preventable Errors. Andy Stengruebl.<br />
http://www.<strong>the</strong>securitypractice.com/<strong>the</strong>_security_practice/papers/84-87.pdf<br />
62
[8]. Assumptions Management in Software Development. G.A.Lewis<br />
http://www.dtic.mil/cgi-bin/GetTRDoc?AD=ADA443152<br />
[9]. Cause and Effect Analysis. Mid Tools Corporation.<br />
http://www.mind<strong>to</strong>ols.com/pages/article/newTMC_03.htm<br />
63