Design and Development of a Traceability Framework for Small Software Development Teams – a Message-Oriented Approach

Total Page:16

File Type:pdf, Size:1020Kb

Design and Development of a Traceability Framework for Small Software Development Teams – a Message-Oriented Approach Die approbierte Originalversion dieser Diplom-/Masterarbeit ist an der Hauptbibliothek der Technischen Universität Wien aufgestellt (http://www.ub.tuwien.ac.at). The approved original version of this diploma or master thesis is available at the main library of the Vienna University of Technology (http://www.ub.tuwien.ac.at/englweb/). Design and Development of a Traceability Framework for Small Software Development Teams – A Message-Oriented Approach DIPLOMARBEIT zur Erlangung des akademischen Grades Diplom-Ingenieur im Rahmen des Studiums Informatik eingereicht von Martin Schwarzbauer Matrikelnummer 9725707 an der Fakultät für Informatik der Technischen Universität Wien Betreuung: Betreuer/Betreuerin: Ao.Univ.Prof. Dipl.-Ing. Dr.techn. Thomas Grechenig Wien, 4.11.2008 _______________________ ______________________ (Unterschrift Verfasser/in) (Unterschrift Betreuer/in) Technische Universität Wien A-1040 Wien Karlsplatz 13 Tel. +43/(0)1/58801-0 http://www.tuwien.ac.at Design and Development of a Traceability Framework for Small Software Development Teams – A Message-Oriented Approach DIPLOMARBEIT zur Erlangung des akademischen Grades Diplom-Ingenieur im Rahmen des Studiums Informatik eingereicht von Martin Schwarzbauer 9725707 ausgeführt am Institut für Rechnergestützte Automation Forschungsgruppe Industrial Software der Fakultät für Informatik der Technischen Universität Wien Betreuung: Betreuer: Univ.-Prof. Dipl.-Ing. Dr. techn. Thomas Grechenig Mitwirkung: Mario Bernhart Eidesstattliche Erklärung Ich erkläre an Eides statt, dass ich die vorliegende Arbeit selbständig und ohne fremde Hilfe verfasst, andere als die angegebenen Quellen nicht benützt und die den benutzten Quellen wörtlich oder inhaltlich entnommenen Stellen als solche kenntlich gemacht habe. Wien, am 4.11.2008 ---------------------------------------------- Martin Schwarzbauer Danksagung Ich möchte Professor Grechenig danken, vor allem dafür dass er mich in der Anfangsphase meiner Diplomarbeit ermutigt hat, an meiner Idee einer Traceability-Lösung für kleine Softwareentwicklungsteams zu arbeiten, sie zu detaillieren und zu erweitern. Mein Dank gilt auch Mario Bernhart, der mir in den entscheidenden Phasen geholfen hat, meine Anstrengungen auf ein erreichbares Ziel zu konzentrieren und mich dadurch davor bewahrt hat, mich mit mehr Problemen zu beschäftigen, als ich im Rahmen meiner Arbeit lösen hätte können. Ich bin Brigitte Brem sehr dankbar für Ihre Anmerkungen und Anleitung während der abschließenden Arbeiten an dieser Diplomarbeit, ohne die ich nicht imstande gewesen wäre, den letzten Einreichtermin für meinen Studienzweig zu halten. Meiner Lebensgefährtin Yvonne danke ich für ihren Hinweis, dass es allein meine eigene Schuld war, dass mein Abschluss aufgrund des Termindrucks fraglich war, und vor allem dafür, dass sie mich mich trotz dieser Tatsache in Liebe unterstützt hat. Zum Abschluss möchte ich auch meinen Eltern danken, die mir immer ein Rückhalt waren und mich auch dann unterstützt haben, als meine Studienfortschritte aufgrund mangelnder Konsequenz und Anstrengung meinerseits seltener wurden. Acknowledgements I want to thank professor Grechenig, especially for encouraging me in the inception phase of the thesis to work on, detail and expand my idea of a traceability solution for small development teams. My thanks also go to Mario Bernhart, who helped me focus my efforts on an achievable goal at the decisive stages of my thesis and thus preserved me from trying to solve more problems than I could have handled in this thesis. I am very grateful to Brigitte Brem for her feedback and guidance during the finalisation of my thesis, without which I would not have been able to hand in my work in time for the last chance to graduate in my branch of study. To my significant other Yvonne, I owe thanks for kindly pointing out to me that getting into a situation where my graduation was in peril was entirely my own fault, and even more gratitude for showing unwavering love and support in spite of that fact. Finally, I want to thank my parents, who have always backed me up and strongly supported me throughout my entire studies, even when there were few results due to little effort on my part. Kurzfassung In der Softwareentwicklung werden Verfolgbarkeit des Informationsflusses und Nachvollziehbarkeit von Entscheidungen (Traceability) oft eher als bürokratisches Hemmnis denn als Möglichkeit zur Effizienzsteigerung gesehen. Dadurch sind gerade kleinere Softwareentwicklungsteams kaum motiviert, die genannten Konzepte anzunehmen und einzuführen. Diese Arbeit hat das Ziel, eine akzeptable Lösung für das Verknüpfen von Projektzwischenergebnissen (Artefakten) zu präsentieren – eine Methode, um Applikationen in der Softwareentwicklung zu integrieren – um es auch kleinen Softwareentwicklungsprojekten zu ermöglichen, Traceability mit einem vertretbaren Aufwand zu erreichen und daraus Vorteile zu ziehen. Das Hauptproblem ist die Tatsache, dass verschiedenste Applikationen zur Unterstützung der Softwareentwicklung im Einsatz sind, sodass ein gemeinsamer Kommunikationsstandard etabliert werden muss, um den Informationsaustausch zwischen beliebigen Zusammenstellungen dieser Applikationen zu ermöglichen. Der hier präsentierte Vorschlag ist ein XML-basiertes Nachrichtenformat: Nachrichten mit Informationen zur Identifikation von Artefakten sowie Nachrichten, die Beziehungen zwischen jeweils zwei Artefakten definieren. Der Einsatz von Nachrichten anstelle von Schnittstellen erlaubt eine lose Kopplung der Applikationen, sodass diese integriert werden können, ohne die applikationsinternen Konzepte anzutasten. Dadurch werden schnelle Resultate erzielt, etwa durch Erweiterung einer Anwendung, die somit Nachrichten an eine zweite Anwendung verschickt, die diese verarbeitet und optisch für Benutzer aufbereitet. Dadurch ist der erste Schritt Richtung Traceability umgesetzt, unter verhältnismäßig geringem Aufwand. Die Verwendung von XML als Basis ermöglicht das automatische Validieren von Nachrichten sowie das Erweitern um zusätzliche Informationen, um eine engere Zusammenarbeit zwischen einzelnen Applikationen zu ermöglichen. Als Machbarkeitsstudie wurden zwei Applikationsprototypen entwickelt – eine für Anforderungsmanagement und eine für Testverwaltung – und diese so erweitert, dass sie durch das präsentierte Nachrichtenformat kommunizieren. Das System zeigt, dass damit Verknüpfungen über Anwendungsgrenzen hinweg erstellt werden können und dass dadurch ein Mehrwert gegeben ist. Aufgrund der ausgetauschten Informationen könnten zum Beispiel Berichte über Testabdeckung oder Testergebnisse zu einzelnen Anforderungen erstellt werden. Keywords: Verfolgbarkeit, Softwareentwicklung, Tool-Integration, XML-Nachrichten, dezentrale Verknüpfungen Abstract Traceability in software development is often seen as bureaucratic burden rather than an opportunity for efficiency improvements. Consequently, small development teams are hardly motivated to embrace the concept and make information flow and decision making in their projects traceable. This thesis aims to present a viable solution for linking intermediate products (artefacts) of the project – a method of integrating tools used in the development process – so that small development teams can reap the benefits of traceability with a reasonable amount of effort. The primary issue is the fact that there are various tools available and in use – a common standard of communication is needed to enable information exchange between any pair or set of tools. The proposal of this thesis an XML-based message format – messages containing information to identify artefacts, and messages defining relationships between pairs of artefacts. Using messages instead of interfaces allows for looser coupling, enabling integration of a tool without adapting its underlying concepts. It is therefore possible to achieve quick results by extending one tool to send messages about its artefacts, and another tool to process these messages and offer its users the information obtained from them – the first step towards traceability. Using XML as base format allows easy message validation against an XML schema and also offers extensibility to incorporate additional information for tighter tool integration where this is desired. As proof of concept, two standalone tool prototypes have been developed and then extended to communicate via the suggested message format: a requirements management and a test tracking tool. The set-up shows that traceability links can be established across tool borders and that this provides benefits to the users. With the shared information, for example reports on test coverage or test results of specific requirements are possible. Keywords: traceability, software engineering, tool integration, XML messages, decentralized links Table of Contents 1 Introduction...............................................................................................................1 2 The Traceability Concept............................................................................................3 2.1 History and Development.....................................................................................4 2.1.1 Origins.........................................................................................................4 2.1.2 Tracing to Design, Code and Test Artefacts....................................................5 2.1.3 Tracing Sources of Specifications...................................................................6 2.1.4 Process Traceability......................................................................................6
Recommended publications
  • Seilevel's Evaluations of Requirements Management Tools
    Seilevel Whitepaper Seilevel’s Evaluations of Requirements Management Tools: Summaries and Scores Joy Beatty Vice President of Research and Development Remo Ferrari, Ph.D. Lead Requirements Tool Researcher Balaji Vijayan Product Manager Savitri Godugula Requirements Tool Researcher www.seilevel.com Executive Summary Seilevel’s requirements management tools research indicates that there is significant improvement over the last few years in the available tools on the market. In an effort to help the Business Analyst and Product Management community, this paper presents the results of Seilevel’s full evaluation of the top 17 tools selected from the initial evaluation, including each tool’s strengths and limitations. The research approach and results are structured in a way to help make other organizations’ tool evaluations easier. This paper also includes a short introduction to the final trial phase, Phase 3, where tools will be used on actual Seilevel projects. A note about rankings: All 17 of the tools evaluated are worthy solutions depending on your organization’s needs, and we strongly encourage you to evaluate all of them using your own priorities. Seilevel’s ranking is not meant to be an endorsement of any tool in preference to another, but rather reflects Seilevel’s proposed priorities for tools criteria. Introduction to Seilevel’s Requirements Tools Evaluations More organizations are adopting requirements tools as they Evaluation Scoring look for support in managing requirements information, in Each tool was evaluated and scored against the full set of traceability to ensure scope is controlled, and in modeling to features, using the following scale: visually represent requirements.
    [Show full text]
  • Tools for Requirements Management in GSD: a Survey Muhammad Mukhtar, Zishan Hussain Chuhan, Zulfiqar Ahmad
    International Journal of Scientific & Engineering Research, Volume 6, Issue 4, April-2015 1935 ISSN 2229-5518 Tools for Requirements Management in GSD: A Survey Muhammad Mukhtar, Zishan Hussain Chuhan, Zulfiqar Ahmad Abstract--- The software requirement specification (SRS) is a volatile document. Even well documented SRS evolves and grows throughout Software Development Life Cycle. Requirements management plays an important role to manage evolution and growth in SRS. Managing requirements in manual ways becomes very difficult especially in global software development due to some additional factors (time zone difference, cultural issues, geographical boundaries, etc.). To overcome this difficulty software industry moves to automate the requirements management. In this research activity, our focus is to survey about tools to automate the requirements management in global software development (GSD). We consider existing tools in this survey those are not developed for GSD and evaluate them on defined parameters in the context of GSD. In short our goal is to validate the existing tools for GSD. Index Terms - Requirements Management, SRS, Tools, Automation, GSD, Integration, Access Control —————————— —————————— 1 Introduction develop many tools These tools proved to be very Requirements management (RM) is a helpful to keep specifications consistent, up-to-date, discipline, in which change and versions of ensure requirements traceability and accessible [3, requirement is controlled, update plan according to 9]. In fact, the existing tools (DOORS, Analyst Pro, the current requirements, managing traceability of PACE, etc) were not developed for global software requirements (impact analysis), and status of the development. Existing requirements management requirements is tracked [1]. SRS is a volatile and tools require a high degree of knowledge to dynamic document because requirements are understand and use it [5].
    [Show full text]
  • Applying Requirements Management with Use Cases
    AAppppllyyiinngg RReeqquuiirreemmeennttss MMaannaaggeemmeenntt wwiitthh UUssee CCaasseess Roger Oberg, Leslee Probasco, and Maria Ericsson ©Copyright 2000 by Rational Software Corporation. All Rights Reserved. Technical Paper TP505 (Version 1.4) Rational Software White Paper Table of Contents Software and System Development in the Age of Process ....................................................................................................1 Why Manage Requirements?..................................................................................................................................................1 What is a Requirement? ..........................................................................................................................................................2 What is Requirements Management? ....................................................................................................................................2 The Problems of Requirements Management........................................................................................................................2 Requirements Management Skills ..........................................................................................................................................3 Key Skill 1: Analyze the Problem..........................................................................................................................................4 Key Skill 2: Understand Stakeholder Needs ..........................................................................................................................4
    [Show full text]
  • REQUIREMENTS ENGINEERING MANAGEMENT FINDINGS REPORT May 2009 6
    DOT/FAA/AR-08/34 Requirements Engineering Air Traffic Organization NextGen & Operations Planning Management Findings Report Office of Research and Technology Development Washington, DC 20591 May 2009 Final Report This document is available to the U.S. public through the National Technical Information Service (NTIS), Springfield, Virginia 22161. U.S. Department of Transportation Federal Aviation Administration NOTICE This document is disseminated under the sponsorship of the U.S. Department of Transportation in the interest of information exchange. The United States Government assumes no liability for the contents or use thereof. The United States Government does not endorse products or manufacturers. Trade or manufacturer's names appear herein solely because they are considered essential to the objective of this report. This document does not constitute FAA certification policy. Consult your local FAA aircraft certification office as to its use. This report is available at the Federal Aviation Administration William J. Hughes Technical Center’s Full-Text Technical Reports page: actlibrary.tc.faa.gov in Adobe Acrobat portable document format (PDF). Technical Report Documentation Page 1. Report No. 2. Government Accession No. 3. Recipient's Catalog No. DOT/FAA/AR-08/34 4. Title and Subtitle 5. Report Date REQUIREMENTS ENGINEERING MANAGEMENT FINDINGS REPORT May 2009 6. Performing Organization Code 7. Author(s) 8. Performing Organization Report No. David L. Lempia and Steven P. Miller 9. Performing Organization Name and Address 10. Work Unit No. (TRAIS) Rockwell Collins, Inc. 400 Collins Road NE 11. Contract or Grant No. Cedar Rapids, IA 52498 DTFACT-05-C-00004 12. Sponsoring Agency Name and Address 13.
    [Show full text]
  • CSCI 4200 Fall 2015.Pages
    CSCI 4200: Software Engineering I (WI) Fall 2015 Instructor Dr. Mark Hills Tuesday, Thursday: 9:30am - 10:45am, Bate 1018 (Section 1) Class Meeting 12:30pm - 1:45pm, Austin 307 (Section 2) Office Science & Technology Building, Room C-110 Tuesday and Thursday: 2:00pm – 4:30pm (except for second Thursday of the month, Office hours then it is Wednesday from 1:00pm - 3:30pm); every weekday by appointment. Phone 252-328-9692 [email protected] (responses within 24 hours during the week, possibly longer on Email weekends, over holidays, or during breaks) Course web page Blackboard: https://blackboard.ecu.edu Required textbooks Software Engineering (10th Edition), by Ian Sommerville, Addison Wesley, 2015, ISBN-10: 0-13-394303-8 Prerequisites CSCI major, completion of CSCI 3200 or CSCI 3310 Course Description and Learning Objectives This course provides practical and theoretical knowledge in relation to software development using software engineering principles. Students will learn the processes, methodologies and tools regarding the complete life cycle of software development so that they are able to begin using state-of-the art software development techniques that will aid the success of their software development projects. Students are required to complete a team project and other assignments during one semester. This is an approved Writing Intensive (WI) course. Upon completion of this course each student will be able to: • Understand the nature, objectives, and methods of software engineering practice • Evaluate and chose process models for
    [Show full text]
  • Requirements Engineering Requirements Management
    Requirements Engineering Chapter 5 Requirements Management Learning Objective ...to describe the process of managing the evolution and change of a system’s requirements. Learning about the user (customers) needs and helping them to better understand and clarify the real and important facets of the endeavor. Some of the issues and aspects that are covered her include: Stable versus volatile requirements, requirements identification and storage, change management and last (but not least) traceability. Frederick T Sheldon Assistant Professor of Computer Science University of Colorado at Colorado Springs CS 531 Software Requirements Analysis and Specification Chapter 5 From Requirements Engineering Processes and Techniques by G. Kotonya and I. Sommerville 1998 Slide 1 Requirements management ⊗ The process of managing change to the requirements for a system ⊗ The principal concerns of requirements management are: • Managing changes to agreed requirements • Managing the relationships between requirements • Managing the dependencies between the requirements document and other documents produced in the systems engineering process ⊗ Requirements cannot be managed effectively without requirements traceability. • A requirement is traceable if you can discover who suggested the requirement, why the requirement exists, what requirements are related to it and how that requirement relates to other information such as systems designs, implementations and user documentation. CS 531 Software Requirements Analysis and Specification Chapter 5 From Requirements
    [Show full text]
  • Applyingrequirements Management with Use Cases
    R Applying Requirements Management with Use Cases Roger Oberg Technical Paper TP505 Leslee Probasco Maria Ericsson Roger Oberg is Vice President and General Manager for Rational Software's requirements management products and on the Board of Directors of two start-up software companies. He has 16 years of high technology marketing and engineering management experience in office automation systems, software development tools, and telecommunications, and a B.A. in Economics from the University of Michigan. Leslee Probasco is the Product Manager for Rational University's requirements management professional education courses. She is a trainer and consultant with experience teaching requirements management, project management, TQM, CMM and ISO 9000. Leslee has twenty years of software management and development experience in the areas of military and aerospace systems, telecommunications, oil and gas, and electrical engineering. Leslee has a M.S. in computer science from the University of Denver and a B.S. in Management Science and Operations Research from Colorado State University. Maria Ericsson is Senior Technical Consultant for Rational Software, located in McLean, Virginia. Maria is part of the team developing the Rational Unified Process, and the co-author of the textbook The Object Advantage: Business Process Engineering with Object Technology. Maria has a M.S. in Engineering Physics from the Royal Institute of Technology in Stockholm, Sweden Applying Requirements Management with Use Cases by Roger Oberg, Leslee Probasco and Maria Ericsson ©Copyright 1998 by Rational Software Corporation. All Rights Reserved. If you are new to or somewhat familiar with requirements management and are interested in requirements process improvement, this paper offers a framework with which to develop your own approach.
    [Show full text]
  • Requirements Management Plan ENT.0018
    Department of Health Care Services CA-MMIS Requirements Management Plan ENT.0018 October 31, 2013 Version 2.0 Table of Contents Preface ..................................................................................... v Revision History ............................................................................................. v Executive Summary .......................................................................................ix 1. Introduction ........................................................................ 1 1.1 Scope ............................................................................................... 5 1.2 Objectives ......................................................................................... 8 2. Process .............................................................................. 9 2.1 Approach .......................................................................................... 9 2.2 Inputs.............................................................................................. 10 2.3 Requirements Development ........................................................... 11 2.3.1 Preparation (1st-Pass Requirements Refinement) ...................... 12 2.3.2 Pre-Validation (2nd-Pass Requirements Refinement)................. 15 2.3.3 Validation (Including SR Workgroup Validation, BP and EVSA Workshops) ................................................................................ 18 2.4 Requirements Management ............................................................ 21 2.4.1
    [Show full text]
  • A CMMI-Compliant Requirements Management and Development Process
    Vanessa Sofia Simões de Ataíde Ramos Licenciada em Engenharia Informática A CMMI-compliant Requirements Management and Development Process Dissertação para obtenção do Grau de Mestre em Engenharia Informática Orientador: Ana Moreira, Professora Associada, FCT/UNL Júri: Presidente: Prof. Doutor Rodrigo Seromenho Miragaia Rodrigues Arguente: Prof. Doutor João Carlos Pascoal de Faria Vogal: Prof. Doutor Ana Maria Dinis Moreira Setembro, 2014 A CMMI-compliant Requirements Management and Development Process Copyright © Vanessa Sofia Simões de Ataíde Ramos, Faculdade de Ciências e Tecnologia, Universidade Nova de Lisboa A Faculdade de Ciências e Tecnologia e a Universidade Nova de Lisboa têm o direito, perpétuo e sem limites geográficos, de arquivar e publicar esta dissertação através de exemplares impressos reproduzidos em papel ou de forma digital, ou por qualquer outro meio conhecido ou que venha a ser inventado, e de a divulgar através de repositórios científicos e de admitir a sua cópia e distribuição com objectivos educacionais ou de investigação, não comerciais, desde que seja dado crédito ao autor e editor. ii iii Acknowledgments Throughout this dissertation I was fortunate enough to have the precious contribution of many people and entities. To them, I would like to show my appreciation with a few words of recognized gratitude. Foremost, I must express my deep gratitude to my supervisors, Ana Maria Moreira and Rui Nunes Gonçalves, for the outstanding guidance and continuous support during this dissertation research and writing. Without them it would, literally, not be possible. I cannot begin to thank my supervisor Ana Moreira, for presenting me with the opportunity to work directly in industry and on one of my favorite topics of software engineering.
    [Show full text]
  • Requirements Management
    02_0321383001_ch01.qxd 11/14/07 8:06 AM Page 3 C HAPTER 1 Requirements Management This chapter starts by defining the concepts of requirements and stakeholders. Then we describe what types of requirements can exist in a project. The relationships between these requirements are presented in the form of a pyramid. The concept of traceability is introduced (which require- ment is derived from which). Characteristics of a good requirement are presented. Examples of problematic requirements are given, together with some guidelines on how to fix them. General steps in requirements management (RM) during the project lifecycle are shown. The main steps navigate through the requirements pyramid from top to bottom. 1.1 Definition of a Requirement and a Stakeholder A requirement is defined as “a condition or capability to which a system must conform.” It can be any of the following: • A capability needed by a customer or user to solve a problem or achieve an objective • A capability that must be met or possessed by a system to satisfy a contract, standard, specification, regulation, or other formally imposed document • A restriction imposed by a stakeholder Let’s define a concept of a stakeholder because this word occurs many times in this book. Usually the stakeholder is defined as someone who is affected by the system that is being devel- oped. The two main types of stakeholders are users and customers. Users are people who will be using the system. Customers are the people who request the system and are responsible for approving it. Usually customers pay for the development of the system.
    [Show full text]
  • Impact of Requirements Volatility on Software Architecture: How Do Software Teams Keep up with Ever-Changing Requirements?
    SPE CIAL IS SUE PA PER Impact OF REQUIREMENTS VOLATILITY ON SOFTWARE architecture: How DO SOFTWARE TEAMS KEEP UP WITH EVer-changing requirements? Sandun DasanaYAKE | Sanja AarAMAA | Jouni Markkula | Markku OivO M3S, Faculty OF Information TECHNOLOGY AND Electrical Engineering, UnivERSITY OF AbstrACT Oulu, Finland. Requirements VOLATILITY IS A MAJOR ISSUE IN SOFTWARE DEVelopment, CAUSING Correspondence PROBLEMS SUCH AS HIGHER DEFECT DENSITY, PROJECT DELAYS AND COST OVerruns. Soft- Sandun DasanaYAKe, M3S, Faculty OF WARE ARCHITECTURE THAT GUIDES THE OVERALL VISION OF SOFTWARE product, IS ONE Information TECHNOLOGY AND Electrical Engineering, UnivERSITY OF Oulu, Finland. OF THE AREAS THAT IS GREATLY AFFECTED BY REQUIREMENTS VOLATILITY. Since CRITICAL Email: sandun.dasanaYAKe@oulu.fi ARCHITECTURE DECISIONS ARE MADE BASED ON THE REQUIREMENTS AT hand, CHANGES FUNDING INFORMATION IN REQUIREMENTS CAN RESULT SIGNIfiCANT CHANGES IN architecture. With THE WIDE ITEA2 AND TEKES - The Finnish FUNDING ADOPTION OF AGILE SOFTWARE DEVelopment, SOFTWARE ARCHITECTURES ARE DESIGNED Agency FOR Innovation, VIA THE MERgE PROJECT TO ACCOMMODATE POSSIBLE FUTURE changes. HoweVER, THE CHANGES HAS TO BE CAREFULLY MANAGED AS UNNECESSARY AND EXCESSIVE CHANGES CAN BRING NEGATIVE consequences. An EXPLORATORY CASE STUDY WAS CONDUCTED TO STUDY THE IMPACT OF REQUIREMENTS VOLATILITY ON SOFTWARE architecture. Fifteen semi-structured, THEMATIC INTERVIEWS WERE CONDUCTED IN A European SOFTWARE COMPANY. The RESEARCH REVEALED POOR communication, INFORMATION distortion, AND Exter- NAL DEPENDENCIES AS THE MAIN FACTORS THAT CAUSE REQUIREMENT VOLATILITY AND INADEQUATE ARCHITECTURE documentation, INABILITY TO TRACE DESIGN Rationale, AND INCREASED COMPLEXITY AS THE MAIN IMPLICATIONS OF REQUIREMENTS VOLATILITY ON SOFTWARE architecture. Insights FROM SOFTWARE teams’ AWARENESS OF THE REQUIREMENT VOLATILITY, FACTORS CONTRIBUTE TO it, AND POSSIBLE WAYS TO MITIGATE ITS IMPLICATIONS WILL BE UTILIZED TO IMPROVE THE MANAGEMENT OF REQUIREMENT VOLATILITY DURING SOFTWARE ARCHITECTING process.
    [Show full text]
  • Evaluation of the Software Requirement Tools
    International Journal of Engineering Research & Technology (IJERT) ISSN: 2278-0181 Vol. 3 Issue 3, March - 2014 Evaluation of the Software Requirement Tools Yogita Sharma Associate Prof. Aman Kumar Sharma Research Scholar Department of Computer Science Department of Computer Science Himachal Pradesh University Himachal Pradesh University Shimla, India Shimla, India Abstract— The foundation of the entire software development requirements and keeps project plans current with the life cycle is laid on the requirement. After receiving a request for requirements. developing a new software project, understanding the requirements and documenting them properly is the first thing that RE can face many problems. Some of the reasons can be is done. If the requirements are managed properly then the right insufficient user involvement which can delay completion of solution can be delivered on time and within budget. Because of project. The situation is made worse if modifications to the the limitations of the document based approach used earlier, requirements are made frequently. Developer’s time is wasted automated tools are being used. Today, there are so many software when he has to fill in the gaps because of the ambiguous and requirements tools available that can be used to speed up the insufficiently detailed requirements. process of documenting requirements, communicating them and managing changes to them. This paper aims to provide an So, to enable effective management of an integrated RE evaluation of five such software requirements tools. The process, automated tool support is essential. Different evaluation is based on the theoretical analysis and various features software requirements tools provide the capabilities for provided by them.
    [Show full text]