DOCSLIB.ORG

A Multiple Viewed Approach to Software Requirements

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
A Multiple Viewed Approach to Software Requirements A Multiple Viewed Approach To Software Requirements A Dissertation Presented to the Faculty of the School of Engineering and Applied Science (Unofficial copy) University of Virginia In Partial Fulfillment of the Requirements for the Degree Doctor of Philosophy ( Computer Science ) by Harry S. Delugach May 1991 ABSTRACT A problem in current requirements development techniques is that the viewpoints (including implicit pre-existing assumptions) of multiple participants must be satisfied by the resulting requirements. Choosing a single language for all participants requires the additional burden of learning the new language and being prepared to overlook some requirements for which the language was not intended. This dissertation proposes a framework and methodology whereby multiple requirements specifications can be produced in several languages of the participants’ own choosing, then translated into a meta-language (that is, a language capable of capturing features of several different requirements languages) in order to analyze their common features. The meta-language of conceptual graphs is used to capture requirements expressed in various conventional requirements development notations. Once translated into conceptual graphs, the set of requirements is analyzed in order to find the most likely counterpart concepts between the partcipants’ requirements specifications. These counterparts represent the overlap between views and form the basis for joining the multiple graphs into one requirements graph. Ambiguous counterparts (i.e., concepts that cannot be distinguished from other concepts) are also identified, guiding the requirements analyst in asking participants further questions about the assumptions that underlie the concepts. i A Multiple-Viewed Approach To Software Requirements Harry S. Delugach Department of Computer Science Computer Science Building Rm 109 University of Alabama in Huntsville Huntsville, AL 35899 U. S. A. Telephone: (205) 895-6614 Electronic mail: [email protected] Table of Contents Table of Contents .................................................................................................i List of Figures.................................................................................................... iv Abbreviations and Symbols ................................................................................... v 1. Introduction....................................................................................................... 1 1.1. Problems With Software Requirements........................................................... 1 1.2. Context of Work......................................................................................... 2 1.3. Multiple Views........................................................................................... 3 1.4. Improving Requirements Development ........................................................... 4 1.5. Outline Of Dissertation................................................................................ 5 2. Views In Software Requirements Development........................................................ 6 2.1. Views in Requirements................................................................................ 6 2.1.1. Purpose Of Using Views.................................................................... 7 2.1.2. Basics Of A View............................................................................. 7 2.1.3. A Participant’s View ......................................................................... 9 2.2. Example Requirements and Assumptions .......................................................12 2.3. Support For A Single View..........................................................................14 2.4. Multiple Viewed Requirements ....................................................................15 2.4.1. Interaction Between Views................................................................15 2.4.2. Support For Multiple Viewed Requirements .........................................16 2.5. The Multiple Viewed Approach....................................................................18 2.6. Summary .................................................................................................18 3. Analyzing Multiple-Viewed Requirements.............................................................20 3.1. Role Of the Requirements Analyst ................................................................21 3.2. Analyzing Overlap Between Views...............................................................23 3.2.1. Identifying Overlap Between Views ....................................................25 3.2.2. Kinds Of Associations ......................................................................26 3.2.3. Association Graph Technique.............................................................28 3.3. General Issues For Multiple Views................................................................35 3.4. Summary .................................................................................................37 4. A Framework and Methodology For Multiple-Viewed Analysis .................................38 4.1. Conceptual Graphs: An Analyst’s Meta-Language ...........................................38 4.2. Definition Of A View.................................................................................40 4.2.1. Domains ........................................................................................40 4.2.2. Requirements Specification ...............................................................42 4.2.3. Requirements Specification Graph ......................................................42 ii 4.2.4. Translation Scheme..........................................................................42 4.2.5. Assumption Graphs..........................................................................43 4.2.6. View .............................................................................................43 4.3. Analyst’s Framework .................................................................................44 4.3.1. Analyst’s Canon..............................................................................44 4.3.2. Analyst’s Requirements Specification Graph.........................................44 4.4. Analysis of Multiple Viewed Requirements ....................................................44 4.4.1. Describing Overlap ..........................................................................45 4.4.2. Analyzing Overlap...........................................................................47 4.5. A Methodology For Multiple Viewed Requirements.........................................49 4.5.1. Methodology Steps ..........................................................................50 4.5.2. Products of Analysis.........................................................................56 4.5.3. Analyst’s View................................................................................56 4.6. General Features Of Approach .....................................................................57 4.7. Summary .................................................................................................58 5. Translating Requirements Into Conceptual Graphs...................................................59 5.1. Entity-Relationship Diagrams ......................................................................60 5.1.1. Example Entity-Relationship Diagram.................................................60 5.1.2. Discussion......................................................................................61 5.2. Data Flow Diagrams...................................................................................61 5.2.1. Example Data Flow Diagram .............................................................62 5.2.2. Discussion......................................................................................63 5.3. State Transition Diagrams ...........................................................................63 5.3.1. Example State Transition Diagram......................................................63 5.3.2. Discussion......................................................................................64 5.4. Requirements Networks (SREM)..................................................................65 5.4.1. Example Requirements Network.........................................................65 5.4.2. Discussion......................................................................................66 5.5. Summary .................................................................................................67 6. A Multiple Viewed Analysis Example...................................................................68 6.1. Analysis: First Association ..........................................................................69 6.2. Analysis: Second Association.......................................................................71 6.3. Analysis: Third Association.........................................................................75 6.4. Results of Analysis ....................................................................................77 6.5. Summary .................................................................................................78 7. Validating Multiple Viewed Analysis....................................................................79 7.1. Overlap Characteristics...............................................................................80 7.2.
Load more

Recommended publications
  • Rugby - a Process Model for Continuous Software Engineering
    INSTITUT FUR¨ INFORMATIK DER TECHNISCHEN UNIVERSITAT¨ MUNCHEN¨ Forschungs- und Lehreinheit I Angewandte Softwaretechnik Rugby - A Process Model for Continuous Software Engineering Stephan Tobias Krusche Vollstandiger¨ Abdruck der von der Fakultat¨ fur¨ Informatik der Technischen Universitat¨ Munchen¨ zur Erlangung des akademischen Grades eines Doktors der Naturwissenschaften (Dr. rer. nat.) genehmigten Dissertation. Vorsitzender: Univ.-Prof. Dr. Helmut Seidl Prufer¨ der Dissertation: 1. Univ.-Prof. Bernd Brugge,¨ Ph.D. 2. Prof. Dr. Jurgen¨ Borstler,¨ Blekinge Institute of Technology, Karlskrona, Schweden Die Dissertation wurde am 28.01.2016 bei der Technischen Universitat¨ Munchen¨ eingereicht und durch die Fakultat¨ fur¨ Informatik am 29.02.2016 angenommen. Abstract Software is developed in increasingly dynamic environments. Organizations need the capability to deal with uncertainty and to react to unexpected changes in require- ments and technologies. Agile methods already improve the flexibility towards changes and with the emergence of continuous delivery, regular feedback loops have become possible. The abilities to maintain high code quality through reviews, to regularly re- lease software, and to collect and prioritize user feedback, are necessary for con- tinuous software engineering. However, there exists no uniform process model that handles the increasing number of reviews, releases and feedback reports. In this dissertation, we describe Rugby, a process model for continuous software en- gineering that is based on a meta model, which treats development activities as parallel workflows and which allows tailoring, customization and extension. Rugby includes a change model and treats changes as events that activate workflows. It integrates re- view management, release management, and feedback management as workflows. As a consequence, Rugby handles the increasing number of reviews, releases and feedback and at the same time decreases their size and effort.
    [Show full text]
  • Writing and Reviewing Use-Case Descriptions
    Bittner/Spence_06.fm Page 145 Tuesday, July 30, 2002 12:04 PM PART II WRITING AND REVIEWING USE-CASE DESCRIPTIONS Part I, Getting Started with Use-Case Modeling, introduced the basic con- cepts of use-case modeling, including defining the basic concepts and understanding how to use these concepts to define the vision, find actors and use cases, and to define the basic concepts the system will use. If we go no further, we have an overview of what the system will do, an under- standing of the stakeholders of the system, and an understanding of the ways the system provides value to those stakeholders. What we do not have, if we stop at this point, is an understanding of exactly what the system does. In short, we lack the details needed to actually develop and test the system. Some people, having only come this far, wonder what use-case model- ing is all about and question its value. If one only comes this far with use- case modeling, we are forced to agree; the real value of use-case modeling comes from the descriptions of the interactions of the actors and the system, and from the descriptions of what the system does in response to the actions of the actors. Surprisingly, and disappointingly, many teams stop after developing little more than simple outlines for their use cases and consider themselves done. These same teams encounter problems because their use cases are vague and lack detail, so they blame the use-case approach for having let them down. The failing in these cases is not with the approach, but with its application.
    [Show full text]
  • Metamodeling Variability to Enable Requirements Reuse
    Metamodeling Variability to Enable Requirements Reuse Begoña Moros 1, Cristina Vicente-Chicote 2, Ambrosio Toval 1 1Departamento de Informática y Sistemas Universidad de Murcia, 30100 Espinardo (Murcia), Spain {bmoros, atoval}@um.es 2 Departamento de Tecnologías de la Información y las Comunicaciones Universidad Politécnica de Cartagena, 30202 Cartagena (Murcia), Spain [email protected] Abstract. Model-Driven Software Development (MDSD) is recognized as a very promising approach to deal with software complexity. The Requirements Engineering community should be aware and take part of the Model-Driven revolution, enabling and promoting the integration of requirements into the MDSD life-cycle. As a first step to reach that goal, this paper proposes REMM, a Requirements Engineering MetaModel, which provides variability modeling mechanisms to enable requirements reuse. In addition, this paper also presents the REMM-Studio graphical requirements modeling tool, aimed at easing the definition of complex requirements models. This tool enables the specification of (1) catalogs of reusable requirements models (modeling for reuse facet of the tool), and (2) specific product requirements by reusing previously defined requirements models (modeling by reuse facet of the tool). Keywords: Model-Driven Software Development (MDSD), Requirements Engineering (RE), Requirements MetaModel (REMM), Requirements Reuse, Requirements Variability. 1 Introduction Model-Driven Software Development (MDSD) aims at raising the level of abstraction at which software is conceived, implemented, and evolved, in order to help managing the inherent complexity of modern software-based systems. As recently stated in a Forrester Research Inc. study “model-driven development will play a key role in the future of software development; it is a promising technique for helping application development managers address growing business complexity and demand ” [1].
    [Show full text]
  • Practical Agile Requirements Engineering Presented to the 13Th Annual Systems Engineering Conference 10/25/2010 – 10/28/2010 Hyatt Regency Mission Bay, San Diego, CA
    Defense, Space & Security Lean-Agile Software Practical Agile Requirements Engineering Presented to the 13th Annual Systems Engineering Conference 10/25/2010 – 10/28/2010 Hyatt Regency Mission Bay, San Diego, CA Presented by: Dick Carlson ([email protected]) Philip Matuzic ([email protected]) BOEING is a trademark of Boeing Management Company. Copyright © 2009 Boeing. All rights reserved. 1 Agenda Boeing Defense, Space & Security| Lean-Agile Software . Introduction . Classic Requirements engineering challenges . How Agile techniques address these challenges . Overview / background of Agile software practices . History and evolution of Agile software Requirements Engineering . Work products and work flow of Agile Requirements Engineering . Integration of Agile software Requirements Engineering in teams using Scrum . Current status of the work and next steps Copyright © 2010 Boeing. All rights reserved. 2 Introduction Boeing Defense, Space & Security| Lean-Agile Software . A large, software-centric program applied Agile techniques to requirements definition using the Scrum approach . This presentation shows how systems engineering effectively applies Agile practices to software requirements definition and management . An experience model created from the program illustrates how failures on a large software program evolved into significant process improvements by applying specific Agile practices and principles to practical requirements engineering Copyright © 2010 Boeing. All rights reserved. 3 Requirements Reality Boeing Defense, Space & Security| Lean-Agile Software “The hardest single part of building a software system is deciding precisely what to build. No other part of the conceptual work is as difficult as establishing the detailed technical requirements, including all the interfaces to people, machines, and other software systems. No other part of the work so cripples the resulting system if done wrong.
    [Show full text]
  • The Legacy of Victor R. Basili
    University of Tennessee, Knoxville TRACE: Tennessee Research and Creative Exchange About Harlan D. Mills Science Alliance 2005 Foundations of Empirical Software Engineering: The Legacy of Victor R. Basili Barry Boehm Hans Dieter Rombach Marvin V. Zelkowitz Follow this and additional works at: https://trace.tennessee.edu/utk_harlanabout Part of the Physical Sciences and Mathematics Commons Recommended Citation Boehm, Barry; Rombach, Hans Dieter; and Zelkowitz, Marvin V., "Foundations of Empirical Software Engineering: The Legacy of Victor R. Basili" (2005). About Harlan D. Mills. https://trace.tennessee.edu/utk_harlanabout/3 This Book is brought to you for free and open access by the Science Alliance at TRACE: Tennessee Research and Creative Exchange. It has been accepted for inclusion in About Harlan D. Mills by an authorized administrator of TRACE: Tennessee Research and Creative Exchange. For more information, please contact [email protected]. University of Tennessee, Knoxville Trace: Tennessee Research and Creative Exchange The Harlan D. Mills Collection Science Alliance 1-1-2005 Foundations of Empirical Software Engineering: The Legacy of Victor R.Basili Barry Boehm Hans Dieter Rombach Marvin V. Zelkowitz Recommended Citation Boehm, Barry; Rombach, Hans Dieter; and Zelkowitz, Marvin V., "Foundations of Empirical Software Engineering: The Legacy of Victor R.Basili" (2005). The Harlan D. Mills Collection. http://trace.tennessee.edu/utk_harlan/36 This Book is brought to you for free and open access by the Science Alliance at Trace: Tennessee Research and Creative Exchange. It has been accepted for inclusion in The Harlan D. Mills Collection by an authorized administrator of Trace: Tennessee Research and Creative Exchange. For more information, please contact [email protected].
    [Show full text]
  • Modeling System Requirements Using Use Cases and Petri Nets
    ICSEA 2016 : The Eleventh International Conference on Software Engineering Advances Modeling System Requirements Using Use Cases and Petri Nets Radek Koˇc´ıand Vladim´ır Janouˇsek Brno University of Technology, Faculty of Information Technology, IT4Innovations Centre of Excellence Czech Republic email: {koci,janousek}@fit.vutbr.cz Abstract—The fundamental problem associated with software executable form, which can then be tested and debugged. All development is a correct identification, specification and sub- changes that result from validation process are hard to transfer sequent implementation of the system requirements. To specify back into the models. It is a problem because the models requirement, designers often create use case diagrams from become useless over the development time. Unified Modeling Language (UML). These models are then developed by further UML models. To validate requirements, Similar work based on ideas of model-driven develop- its executable form has to be obtained or the prototype has to be ment deals with gaps between different development stages developed. It can conclude in wrong requirement implementations and focuses on the usage of conceptual models during the and incorrect validation process. The approach presented in this simulation model development process—these techniques are work focuses on formal requirement modeling combining the called model continuity [8]. While it works with simulation classic models for requirements specification (use case diagrams) models during design stages, the approach proposed in this with models having a formal basis (Petri Nets). Created models can be used in all development stages including requirements paper focuses on live models that can be used in the deployed specification, verification, and implementation.
    [Show full text]
  • Identify and Manage the Software Requirements Volatility Proposed Framework and Casestudy
    (IJACSA) International Journal of Advanced Computer Science and Applications, Vol. 7, No. 5, 2016 Identify and Manage the Software Requirements Volatility Proposed Framework and CaseStudy Khloud Abd Elwahab Mahmoud Abd EL Latif Sherif Kholeif MSc student /Information system Associate Professor of information Assistant Professor of information Department system department system Faculty of computers and Faculty of computers and Faculty of computers and information, Helwan University line information, Helwan University information, Helwan University 3: Cairo, Egypt Cairo, Egypt Cairo, Egypt Abstract—Management of software requirements volatility a framework focus on how to manage requirements volatility through development of life cycle is a very important stage. It during the software development life cycle and to limit the helps the team to control significant impact all over the project implications thereof. The remainder paper is structured as (cost, time and effort), and also it keeps the project on track, to follows: Section 2 presents the motivation to search for the finally satisfy the user which is the main success criteria for the requirements volatility topic. Section 3 explains the software project. requirements volatility definition, factors, causes, and the In this research paper, we have analysed the root causes of measures, and finally explains the impact of that on software requirements volatility through a proposed framework development process. Section 4 contains proposed framework presenting the requirements volatility causes and how to manage and presents a case study in explanation of the benefits of this requirements volatility during the software development life framework. Section 5 concludes our results and provides some cycle. Our proposed framework identifies requirement error types, open research directions causes of requirements volatility and how to manage these II.
    [Show full text]
  • Software Development a Practical Approach!
    Software Development A Practical Approach! Hans-Petter Halvorsen https://www.halvorsen.blog https://halvorsen.blog Software Development A Practical Approach! Hans-Petter Halvorsen Software Development A Practical Approach! Hans-Petter Halvorsen Copyright © 2020 ISBN: 978-82-691106-0-9 Publisher Identifier: 978-82-691106 https://halvorsen.blog ii Preface The main goal with this document: • To give you an overview of what software engineering is • To take you beyond programming to engineering software What is Software Development? It is a complex process to develop modern and professional software today. This document tries to give a brief overview of Software Development. This document tries to focus on a practical approach regarding Software Development. So why do we need System Engineering? Here are some key factors: • Understand Customer Requirements o What does the customer needs (because they may not know it!) o Transform Customer requirements into working software • Planning o How do we reach our goals? o Will we finish within deadline? o Resources o What can go wrong? • Implementation o What kind of platforms and architecture should be used? o Split your work into manageable pieces iii • Quality and Performance o Make sure the software fulfills the customers’ needs We will learn how to build good (i.e. high quality) software, which includes: • Requirements Specification • Technical Design • Good User Experience (UX) • Improved Code Quality and Implementation • Testing • System Documentation • User Documentation • etc. You will find additional resources on this web page: http://www.halvorsen.blog/documents/programming/software_engineering/ iv Information about the author: Hans-Petter Halvorsen The author currently works at the University of South-Eastern Norway.
    [Show full text]
  • The Role of Empirical Study in Software Engineering
    The Role of Empirical Study in Software Engineering Victor R. Basili Professor, University of Maryland and Director, Fraunhofer Center - Maryland © 2004 Experimental Software Engineering Group, University of Maryland Outline • Empirical Studies – Motivation – Specific Methods – Example: SEL • Applications – CeBASE – NASA High Dependability Computing Project – The Future Combat Systems Project – DoE High Productivity Computing System 2 Motivation for Empirical Software Engineering Understanding a discipline involves building models, e.g., application domain, problem solving processes And checking our understanding is correct, e.g., testing our models, experimenting in the real world Analyzing the results involves learning, the encapsulation of knowledge and the ability to change or refine our models over time The understanding of a discipline evolves over time This is the empirical paradigm that has been used in many fields, e.g., physics, medicine, manufacturing Like other disciplines, software engineering requires an empirical paradigm 3 Motivation for Empirical Software Engineering Empirical software engineering requires the scientific use of quantitative and qualitative data to understand and improve the software product, software development process and software management It requires real world laboratories Research needs laboratories to observe & manipulate the variables - they only exist where developers build software systems Development needs to understand how to build systems better - research can provide models to help Research
    [Show full text]
  • Design Thinking: Challenges for Software Requirements Elicitation
    information Article Design Thinking: Challenges for Software Requirements Elicitation Hugo Ferreira Martins 1, Antônio Carvalho de Oliveira Junior 2, Edna Dias Canedo 1,* , Ricardo Ajax Dias Kosloski 2, Roberto Ávila Paldês 1 and Edgard Costa Oliveira 3 1 Department of Computer Science, University of Brasília (UnB), P.O. Box 4466, Brasília–DF, CEP 70910-900, Brazil; [email protected] (H.F.M.); [email protected] (R.Á.P.); 2 Faculty UnB Gama, University of Brasília (UnB), P.O. Box 4466, Brasília–DF, CEP 70910-900, Brazil; [email protected] (A.C.d.O.J.); [email protected] (R.A.D.K.) 3 Department of Production Engineering, University of Brasília (UnB), P.O. Box 4466, Brasília–DF, CEP 70910-900, Brazil; [email protected] * Correspondence: [email protected]; Tel.: +55-61-98114-0478 Received: 21 October 2019; Accepted: 30 October 2019; Published: 28 November 2019 Abstract: Agile methods fit well for software development teams in the requirements elicitation activities. It has brought challenges to organizations in adopting the existing traditional methods, as well as new ones. Design Thinking has been used as a requirements elicitation technique and immersion in the process areas, which brings the client closer to the software project team and enables the creation of better projects. With the use of data triangulation, this paper brings a literature review that collected the challenges in software requirements elicitation in agile methodologies and the use of Design Thinking. The result gave way to a case study in a Brazilian public organization project, via user workshop questionnaire with 20 items, applied during the study, in order to identify the practice of Design Thinking in this context.
    [Show full text]
  • Utilizing GQM+Strategies for Business Value Analysis
    Utilizing GQM+Strategies for Business Value Analysis An Approach for Evaluating Business Goals Vladimir Mandic´ Victor Basili Lasse Harjumaa Department of Information Fraunhofer Center for Department of Information Processing Science, Experimental Software Processing Science, University of Oulu Engineering - Maryland University of Oulu Finland USA Finland [email protected].fi [email protected] lasse.harjumaa@oulu.fi Markku Oivo Jouni Markkula Department of Information Department of Information Processing Science, Processing Science, University of Oulu University of Oulu Finland Finland markku.oivo@oulu.fi jouni.markkula@oulu.fi ABSTRACT to define it. The general understanding is that business value is Business value analysis (BVA) quantifies the factors that provide a concept which extends the traditional bookkeeping-like defini- value and cost to an organization. It aims at capturing value, con- tion of the value by including different aspects of the business as trolling risks, and capitalizing on opportunities. GQM+Strategies well. Those different aspects of business (e.g., employees, part- is an approach designed to aid in the definition and alignment of ner networks, ability to adopt new processes rapidly, etc.) form an business goals, strategies, and an integrated measurement program endless list that is under continuous amendment. A rich financial at all levels in the organization. In this paper we describe how apparatus for evaluating business investments (e.g., return on in- to perform business value analysis (BVA) using the GQM+Strate- vestment (ROI), net present value (NPV), portfolio management, gies approach. The integration of these two approaches provides a etc.) is powerless if we are not able to define inputs (components coupling of cost-benefit and risk analysis (value goals) with oper- of the business value).
    [Show full text]
  • Victor Basili Adam Trendowicz Martin Kowalczyk Jens Heidrich Carolyn
    The Fraunhofer IESE Series on Software and Systems Engineering Victor Basili Adam Trendowicz Martin Kowalczyk Jens Heidrich Carolyn Seaman Jürgen Münch Dieter Rombach Aligning Organizations Through Measurement The GQM+Strategies Approach The Fraunhofer IESE Series on Software and Systems Engineering Series Editor Dieter Rombach Peter Liggesmeyer Editorial Board W. Rance Cleaveland II Reinhold E. Achatz Helmut Krcmar For further volumes: http://www.springer.com/series/8755 ThiS is a FM Blank Page Victor Basili • Adam Trendowicz • Martin Kowalczyk • Jens Heidrich • Carolyn Seaman • Ju¨rgen Mu¨nch • Dieter Rombach Aligning Organizations Through Measurement The GQM+Strategies Approach Victor Basili Adam Trendowicz Department of Computer Science Jens Heidrich University of Maryland Dieter Rombach College Park Fraunhofer Institute for Experimental Maryland Software Engineering USA Kaiserslautern Germany Martin Kowalczyk Carolyn Seaman Department of Information Systems Department of Information Systems Technical University of Darmstadt University of Maryland Baltimore County Darmstadt Baltimore Germany USA Ju¨rgen Mu¨nch Department of Computer Science University of Helsinki Helsinki Finland ISSN 2193-8199 ISSN 2193-8202 (electronic) ISBN 978-3-319-05046-1 ISBN 978-3-319-05047-8 (eBook) DOI 10.1007/978-3-319-05047-8 Springer Cham Heidelberg New York Dordrecht London Library of Congress Control Number: 2014936596 # Springer International Publishing Switzerland 2014 This work is subject to copyright. All rights are reserved by the Publisher, whether the whole or part of the material is concerned, specifically the rights of translation, reprinting, reuse of illustrations, recitation, broadcasting, reproduction on microfilms or in any other physical way, and transmission or information storage and retrieval, electronic adaptation, computer software, or by similar or dissimilar methodology now known or hereafter developed.
    [Show full text]