DOCSLIB.ORG

Non-Functional Requirements Software Architecture Design David

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Non-Functional Requirements Software Architecture Design David Non-Functional Requirements as drivers of Software Architecture Design David Ameller Thesis supervised by Dr. Xavier Franch A thesis submitted in partial fulfillment of the requirements for the degree of Doctor of Philosophy in Computing Departament de Llenguatges i Sistemes Informàtics Universitat Politècnica de Catalunya Abstract In the last decades, software engineering has become an important area of research. As researchers, we try to identify a problem, a need, or a hole in some research topic, once identified we make an effort to produce new tech- niques, methods, and tools that hopefully will help to improve the detected issue. In the present thesis the identified issue was the need of supporting non-functional requirements in the software architecture design where these requirements are the drivers of the architectural decision-making. This thesis started with the idea that a relatively new software engi- neering discipline, model-driven development, was a good place to propose a solution for the detected issue. We envisioned how non-functional re- quirements can be integrated in model-driven development and how this integration will impact in the architectural design activities. When we started to produce our techniques, methods, and tools for model-driven development we found out that there was a bigger hole in the web of knowledge than what we had initially foreseen. Much of the evidence of how non-functional requirements affect the software architecture design is hidden. This situation caused a turn in this thesis: we needed to understand architects, how they think and how they make the architectural decisions, what is the role of non-functional requirements in the architectural decision- making process, and to what extent are the non-functional requirements important in this process. All these questions needed an answer, an answer that only architects could provide. In consequence we opted to drove several empirical studies to answer these questions. I ABSTRACT In parallel, we started to work in a way of representing this knowledge, an ontology for software architecture that integrates non-functional require- ments. Using this ontology as basis, we designed a method to assist archi- tects in the architectural decision-making process and a tool that acted as a proof of concept of both, the ontology and the method. In summary, this thesis explores how non-functional requirements are currently integrated in the software architecture design practices, and pro- poses ways to improve this integration and facilitate the work of architects by providing means to assist them in the architectural decision-making pro- cess. II Co-authorship statement Most of the contents in this thesis are based on published papers authored by the candidate, and in some cases co-authored with other authors. The contents of the papers included in this thesis may have been adapted, reorga- nized, and extended with respect to the published version. The contribution for each chapter is described, including specifically who contributed to the work and the nature and extent of his/her contribution. All thesis chapters Dr. Xavier Franch, as supervisor, has contributed to the research described in this thesis. Xavier’s has been active and involved in the research being conducted, discussing, and writing each paper. His guidance and supervision has been fundamental for the selection of conference and journal targets for publications and the improvement of English writing skills. Chapter 3 This chapter is based in [24], which was co-authored with Dr. Jordi Cabot, associate professor at the École des Mines de Nantes and the leader of the AtlanMod team. Jordi participated in the discussions of this research giving his opinion, in particular his expertise in Model-Driven Development was of great value for this research. He also helped in the writing of the paper. III CO-AUTHORSHIP STATEMENT Chapter 5 This chapter is composed by three empirical studies. While the first one was performed with Dr. Xavier Franch alone, the other two were in collabora- tion with other researchers. The second empirical study is based in [11, 12], which was co-authored with Dr. Claudia Ayala, researcher at the Universi- tat Politècnica de Catalunya and Dr. Jordi Cabot, previously introduced. Claudia was the expert in driving empirical studies, and proposed the pro- tocol to follow, she also participated in the execution of the study and in the writing of the papers. Jordi participated in most of the discussions of this research and helped in the writing of the papers. The third empirical study is based in [25], which was co-authored with Dr. Matthias Galster, re- searcher at the University of Canterbury, and Dr. Paris Avgeriou, researcher at the University of Groningen and leader of the SEARCH group. Matthias produced the first version of the research protocol and helped in the writing of the paper. Paris participated in most of the discussions of this research giving his opinion, in particular his expertise in software architecture was of great value for this research. He also helped in the writing of the paper. Chapter 7 The Section 7.3 of this chapter is based in the papers [14, 15], which were co-authored with Oriol Collell. Oriol was the main developer of the Ar- chiTech tool, and he also helped in the preparation of the tool demo and the promotional video. IV Acknowledgments This research project would not have been possible without the support of many people. The author wishes to express his gratitude to his supervi- sor, who was abundantly helpful and provided extremely useful assistance, support, and guidance. Special thanks also to all his research group members and university colleagues; for their invaluable assistance. Not forgetting his best friends who always have been there. The author wishes to express an special gratitude to his mother and father, and to his relatives; for their support during his studies. The following is the list of people, in alphabetical order, that helped in one way or another to the completion of this thesis. Antonio Vallecillo David Ruiz Oriol Collell Antonio Villegas Frank Buschmann Oscar Cabrera Borja Balle Hugo H. Pibernat Oscar Hernan Carles Farré Jaelson Castro Oscar Pastor Carlos Ameller Jordi Cabot Paris Avgeriou Charlie Ameller Jordi Marco Paul Grünbacher Claudia P. Ayala Judith Mitchell Raul Marina Cristina Gómez Lidia López Rebeca Dalmau Cristina Palomares Marc Oriol Silverio Martínez David Aguilera Matthias Galster Vicente Pelechano David Cerdan Nadia Ameller Xavier Franch V ACKNOWLEDGMENTS VI Contents Abstract I Co-authorship Statement III Acknowledgments V Contents VII List of Tables XI List of Figures XIII 1 Introduction 1 1.1 Context and terminology . .1 1.1.1 Requirements Engineering . .1 1.1.2 Software Architecture . .4 1.1.3 Model-Driven Development . .5 1.2 Research questions . .7 1.3 Methodological approach . .9 1.4 Research contributions . 11 1.4.1 Integration of NFRs into MDD . 11 1.4.2 Empirical research in software architecture . 12 1.4.3 Architectural knowledge . 13 VII CONTENTS 1.4.4 Other publications . 14 1.4.5 Statistics of the published works . 16 1.5 Structure of the dissertation . 17 I NFRs in Model-Driven Development 19 2 State of the art 21 2.1 Modeling languages supporting NFRs in MDD . 22 2.1.1 Extending modeling languages to represent NFRs . 22 2.1.2 MDD with support for RE modeling languages . 23 2.1.3 Analysis . 25 2.2 Processes that support NFRs in MDD . 25 2.2.1 NFR-driven transformations . 26 2.2.2 NFRs as validating mechanism . 26 2.2.3 Analysis . 28 3 Introducing NFRs in MDD 29 3.1 State of the practice . 29 3.1.1 NFRs supported with manual adaptation . 30 3.1.2 NFRs supported with new transformations . 31 3.1.3 How are NFRs supported in MDD practice? . 32 3.2 Motivation . 34 3.3 Introducing NFRs in MDD . 37 3.3.1 NFR-aware MDD: NFRs in the PIM . 38 3.3.2 NFR-aware MDD: NFRs for decision-making . 42 3.3.3 Comparison . 44 3.4 Discussion . 47 3.5 Conclusions . 50 II NFRs in Software Architecture 53 4 State of the art 55 4.1 Empirical studies on NFRs . 56 4.1.1 Analysis . 58 4.2 Empirical studies on software architecture . 58 VIII CONTENTS 4.2.1 Analysis . 60 5 State of the practice 61 5.1 First empirical study . 62 5.1.1 Design . 62 5.1.2 Results . 66 5.1.3 Discussion . 70 5.2 Second empirical study . 73 5.2.1 Design . 73 5.2.2 Results . 80 5.2.3 Discussion . 97 5.3 Third empirical study . 98 5.3.1 Design . 99 5.3.2 Results . 103 5.3.3 Discussion . 113 5.4 Conclusions . 115 III Arteon, Quark, and ArchiTech 119 6 State of the art 121 6.1 Architectural Knowledge ontologies . 122 6.1.1 Analysis . 125 6.2 Software architectural design methods . 126 6.2.1 Analysis . 130 6.3 Architectural Knowledge tools . 130 6.3.1 Analysis . 131 7 Architectural knowledge 133 7.1 Arteon: Architectural and Technological Ontology . 135 7.1.1 Design . 136 7.1.2 Structural elements module (SE-module) . 139 7.1.3 Reasoning module (R-module) . 143 7.1.4 Discussion . 146 7.2 Quark: Quality in Architectural Knowledge . 147 7.2.1 The Quark method . 148 7.2.2 Example . 152 IX CONTENTS 7.2.3 Discussion . 154 7.3 ArchiTech . 156 7.3.1 ArchiTech-CRUD . 156 7.3.2 ArchiTech-DM . 158 7.3.3 Design . 159 7.4 Conclusions . 165 Conclusions and future work 167 Conclusions . 167 Future work . 169 Appendix A First empirical study 171 Appendix B Second empirical study 191 Appendix C Third empirical study 197 List of Abbreviations 215 Bibliography 217 Index 243 X List of Tables 1.1 Research questions of this thesis .
Load more

Recommended publications
  • A System Model for Managing Requirement Traceability Matrices Via Statistical Artifact Change Analysis Benjamin J
    A System Model for Managing Requirement Traceability Matrices via Statistical Artifact Change Analysis Benjamin J. Deaver and LiGuo Huang, Southern Methodist University, Dallas Introduction and Motivation Requirement Traceability Matrix – Gantt Open Source Software Project The Value of the Requirements Traceability Matrix The system Requirement Traceability Matrix (RTM) is primarily used for ensuring Our initial dataset for evaluation is taken from the Gantt Open Source PROCEDURE Kannenberg et al identify the underlying necessity of the Requirements Traceability Matrix and the underlying effect on that all requirements are fulfilled by the system artifact deliverables and the Software Project (http://www.ganttproject.biz). The initial trace data 1. Identify the taxonomy of change for a given domain (Systems Engineering, project management, process visibility, verification and validation, as well as project maintainability. Over time, the management of change to deliverables with respect to impact on other systems. In has been provided to us by Dr. Alexander Egyed at the Institute for SoS Engineering, Software Engineering). the systems engineering and system of systems (SoS) engineering landscapes, the Systems Engineering and Automation at Johannes Kepler University. Requirements Traceability Matrix provides significant insight in to the internal workings of the relationships between RTM is a tool that is useful at time of creation, but requires constant maintenance in Additional traces of requirements to code for subsequent Gantt versions 2. Identify and classify changes between static versions of the product. requirements and deliverable artifacts. a frequently changing landscape to maintain the original level of validity. The are being created using similar methods to the original collections 3. Generate Requirements Trace Matrixes for each static version of the product dynamic nature of systems and SoS engineering landscapes requires that a RTM be performed by Dr.
    [Show full text]
  • A Reference Architecture for Web Servers
    A Reference Architecture for Web Servers Ahmed E. Hassan and Richard C. Holt Software Architecture Group (SWAG) Dept. of Computer Science University of Waterloo Waterloo, Ontario N2L 3G1 CANADA +1 (519) 888-4567 x 4671 {aeehassa, holt}@plg.uwaterloo.ca ABSTRACT document increases with the size and the complexity of the software system. Recently, a number of tools have A reference software architecture for a domain defines been developed to decrease this cost by helping to ex- the fundamental components of the domain and the tract the architecture of a software system [7, 16, 20, relations between them. Research has shown the bene- 21]. Using these tools, reverse engineering researchers fits of having a reference architecture for product de- have developed semi-automated processes to extract the velopment, software reuse, and maintenance. Many product’s architecture from available artifacts such as mature domains, such as compilers and operating sys- the product's source code and any available documenta- tems, have well-known reference architectures. tion. In this paper, we present a process to derive a reference The reference architecture [4] for a domain is an archi- architecture for a domain. We used this process to de- tecture template for all the software systems in the do- rive a reference architecture for web servers, which is a main. It defines the fundamental components of the relatively new domain. The paper presents the map- domain and the relations between these components. ping of this reference architecture to the architectures of The architecture for a particular product is an instance three open source web servers: Apache (80KLOC), of the reference architecture.
    [Show full text]
  • Server: Apache
    Modern Trends in Network Fingerprinting SecTor [11.21.07] Jay Graver Ryan Poppa // Fingerprinting Topics Why, What, Who & How? Tools in action Why Tools Break Tools EOL New Approaches New Tool // Why Fingerprint? WhiteHat needs accurate identification of hosts in a PenTest report BlackHat reconnaissance SysAdmins track down and identify new services or hosts when they appear on their network // What is a Fingerprint? Looking at something common … 192.168.2.187:8004 192.168.2.187 [152] 48 54 54 50 2f 31 2e 31 20 32 30 30 20 4f 4b 0d HTTP/1.1 200 OK. 0a 43 6f 6e 6e 65 63 74 69 6f 6e 3a 20 63 6c 6f .Connection: clo 73 65 0d 0a 41 6c 6c 6f 77 3a 20 4f 50 54 49 4f se..Allow: OPTIO 4e 53 2c 20 47 45 54 2c 20 48 45 41 44 2c 20 50 NS, GET, HEAD, P 4f 53 54 0d 0a 43 6f 6e 74 65 6e 74 2d 4c 65 6e OST..Content‐Len 67 74 68 3a 20 30 0d 0a 44 61 74 65 3a 20 46 72 gth: 0..Date: Fr 69 2c 20 30 32 20 4e 6f 76 20 32 30 30 37 20 32 i, 02 Nov 2007 2 32 3a 32 35 3a 31 38 20 47 4d 54 0d 0a 53 65 72 2:25:18 GMT..Ser 76 65 72 3a 20 6c 69 67 68 74 74 70 64 2f 31 2e ver: lighttpd/1. 34 2e 31 35 0d 0a 0d 0a 4.15...
    [Show full text]
  • Requirements Traceability Practices Guide
    CDC UNIFIED PROCESS PRACTICE GUIDE REQUIREMENTS TRACEABILITY Document Purpose The purpose of this document is to provide guidance on the project management practice of Requirements Traceability and to describe the practice overview, requirements, best practices, activities, and key terms related to these requirements. In addition, templates relevant to this practice are provided at the end of this guide. Practice Overview Requirements traceability is an activity that is one part of an overarching requirements management practice and extends from requirements definition through to implementation. Requirements tracing is used to ensure that each step of the product’s development process is correct, conforms to the needs of prior and next steps, and conforms to the defined requirements. Requirements tracing is a technique that helps to ensure that the project delivers what stakeholders expect. If applied correctly requirements tracing is a practice that can greatly increase the quality and reliability of a project’s final product while minimizing costly rework resulting from requirements errors. Requirements tracing defines the ability to describe and follow the life of a requirement, in both a forward and backward direction, ideally through each step of the entire product’s life cycle. This is done by documenting and tracking traceability relationships between requirements. A traceability relationship is a dependency relationship between project and/or product elements. Similar to the way a dynamic project schedule may react to a change in one task, a change to a requirement element may also have a rippling effect on other elements. A well documented traceability relationship clearly defines requirement dependencies and allows for analysis of how changes in requirements affect other requirements and the project as a whole.
    [Show full text]
  • Next Generation Web Scanning Presentation
    Next generation web scanning New Zealand: A case study First presented at KIWICON III 2009 By Andrew Horton aka urbanadventurer NZ Web Recon Goal: To scan all of New Zealand's web-space to see what's there. Requirements: – Targets – Scanning – Analysis Sounds easy, right? urbanadventurer (Andrew Horton) www.morningstarsecurity.com Targets urbanadventurer (Andrew Horton) www.morningstarsecurity.com Targets What does 'NZ web-space' mean? It could mean: •Geographically within NZ regardless of the TLD •The .nz TLD hosted anywhere •All of the above For this scan it means, IPs geographically within NZ urbanadventurer (Andrew Horton) www.morningstarsecurity.com Finding Targets We need creative methods to find targets urbanadventurer (Andrew Horton) www.morningstarsecurity.com DNS Zone Transfer urbanadventurer (Andrew Horton) www.morningstarsecurity.com Find IP addresses on IRC and by resolving lots of NZ websites 58.*.*.* 60.*.*.* 65.*.*.* 91.*.*.* 110.*.*.* 111.*.*.* 113.*.*.* 114.*.*.* 115.*.*.* 116.*.*.* 117.*.*.* 118.*.*.* 119.*.*.* 120.*.*.* 121.*.*.* 122.*.*.* 123.*.*.* 124.*.*.* 125.*.*.* 130.*.*.* 131.*.*.* 132.*.*.* 138.*.*.* 139.*.*.* 143.*.*.* 144.*.*.* 146.*.*.* 150.*.*.* 153.*.*.* 156.*.*.* 161.*.*.* 162.*.*.* 163.*.*.* 165.*.*.* 166.*.*.* 167.*.*.* 192.*.*.* 198.*.*.* 202.*.*.* 203.*.*.* 210.*.*.* 218.*.*.* 219.*.*.* 222.*.*.* 729,580,500 IPs. More than we want to try. urbanadventurer (Andrew Horton) www.morningstarsecurity.com IP address blocks in the IANA IPv4 Address Space Registry Prefix Designation Date Whois Status [1] -----
    [Show full text]
  • Non-Functional Requirements
    ® IBM Software Group Non-Functional Requirements Peter Eeles [email protected] IBM Software Group | Rational software Agenda Definitions Types of requirement Classifying requirements Capturing NFRs Summary IBM Software Group | Rational software Definitions Functional Requirement Functional requirements describe the behaviors (functions or services) of the system that support user goals, tasks or activities. [Malan] Non-Functional Requirement Non-functional requirements include constraints and qualities. [Malan] [System] qualities are properties or characteristics of the system that its stakeholders care about and hence will affect their degree of satisfaction with the system. [Malan] A constraint is a restriction on the degree of freedom we have in providing a solution. [Leffingwell] [Leffingwell] Managing Software Requirements – a Unified Approach, Dean Leffingwell and Don Widrig. [Malan] Defining Non-Functional Requirements, Ruth Malan and Dana Bredemeyer. IBM Software Group | Rational software Agenda Definitions Types of requirement Classifying requirements Capturing NFRs Summary IBM Software Group | Rational software Types of Requirement Use Cases Defines the behavior of the system from an external perspective System-Wide Requirements Legal and regulatory requirements, application standards, qualities that the system exhibits (such as usability, reliability, scalability, performance), operating system and environment requirements, compatibility requirements, and other design and implementation constraints Change
    [Show full text]
  • Learning Management System Technologies and Software Solutions for Online Teaching: Tools and Applications
    Learning Management System Technologies and Software Solutions for Online Teaching: Tools and Applications Yefim Kats Ellis University, USA & Rivier College, USA InformatIon scIence reference Hershey • New York Director of Editorial Content: Kristin Klinger Director of Book Publications: Julia Mosemann Acquisitions Editor: Lindsay Johnston Development Editor: Elizabeth Ardner Typesetter: Gregory Snader Production Editor: Jamie Snavely Cover Design: Lisa Tosheff Printed at: Yurchak Printing Inc. Published in the United States of America by Information Science Reference (an imprint of IGI Global) 701 E. Chocolate Avenue Hershey PA 17033 Tel: 717-533-8845 Fax: 717-533-8661 E-mail: [email protected] Web site: http://www.igi-global.com/reference Copyright © 2010 by IGI Global. All rights reserved. No part of this publication may be reproduced, stored or distributed in any form or by any means, electronic or mechanical, including photocopying, without written permission from the publisher. Product or company names used in this set are for identification purposes only. Inclusion of the names of the products or companies does not indicate a claim of ownership by IGI Global of the trademark or registered trademark. Library of Congress Cataloging-in-Publication Data Learning management system technologies and software solutions for online teaching : tools and applications / Yefim Kats, editor. p. cm. Includes bibliographical references and index. Summary: "This book gives a general coverage of learning management systems followed by a comparative analysis of the particular LMS products, review of technologies supporting different aspect of educational process, and, the best practices and methodologies for LMS-supported course delivery"--Provided by publisher. ISBN 978-1-61520-853-1 (hardcover) -- ISBN 978-1-61520-854-8 (ebook) 1.
    [Show full text]
  • Comparison of Web Server Software from Wikipedia, the Free Encyclopedia
    Create account Log in Article Talk Read Edit ViewM ohrisetory Search Comparison of web server software From Wikipedia, the free encyclopedia Main page This article is a comparison of web server software. Contents Featured content Contents [hide] Current events 1 Overview Random article 2 Features Donate to Wikipedia 3 Operating system support Wikimedia Shop 4 See also Interaction 5 References Help 6 External links About Wikipedia Community portal Recent changes Overview [edit] Contact page Tools Server Developed by Software license Last stable version Latest release date What links here AOLserver NaviSoft Mozilla 4.5.2 2012-09-19 Related changes Apache HTTP Server Apache Software Foundation Apache 2.4.10 2014-07-21 Upload file Special pages Apache Tomcat Apache Software Foundation Apache 7.0.53 2014-03-30 Permanent link Boa Paul Phillips GPL 0.94.13 2002-07-30 Page information Caudium The Caudium Group GPL 1.4.18 2012-02-24 Wikidata item Cite this page Cherokee HTTP Server Álvaro López Ortega GPL 1.2.103 2013-04-21 Hiawatha HTTP Server Hugo Leisink GPLv2 9.6 2014-06-01 Print/export Create a book HFS Rejetto GPL 2.2f 2009-02-17 Download as PDF IBM HTTP Server IBM Non-free proprietary 8.5.5 2013-06-14 Printable version Internet Information Services Microsoft Non-free proprietary 8.5 2013-09-09 Languages Jetty Eclipse Foundation Apache 9.1.4 2014-04-01 Čeština Jexus Bing Liu Non-free proprietary 5.5.2 2014-04-27 Galego Nederlands lighttpd Jan Kneschke (Incremental) BSD variant 1.4.35 2014-03-12 Português LiteSpeed Web Server LiteSpeed Technologies Non-free proprietary 4.2.3 2013-05-22 Русский Mongoose Cesanta Software GPLv2 / commercial 5.5 2014-10-28 中文 Edit links Monkey HTTP Server Monkey Software LGPLv2 1.5.1 2014-06-10 NaviServer Various Mozilla 1.1 4.99.6 2014-06-29 NCSA HTTPd Robert McCool Non-free proprietary 1.5.2a 1996 Nginx NGINX, Inc.
    [Show full text]
  • Requirements Traceability Matrix Template
    Connecticut Department of Social Services Enterprise Program Management Office Requirements Traceability Matrix Purpose of the Requirements Traceability Matrix The Requirements Traceability Matrix (RTM) is a document that links requirements throughout the validation process. The purpose of the Requirements Traceability Matrix is to ensure that all requirements defined for a system are tested in the test protocols. The traceability matrix is a tool both for the validation team to ensure that requirements are not lost during the validation project and for auditors to review the validation documentation. Information to Include The requirements traceability matrix is usually developed in concurrence with the initial list of requirements (either the User Requirements Specification or Functional Requirements Specification). As the Design Specifications and Test Protocols are developed, the traceability matrix is updated to include the updated documents. Ideally, requirements should be traced to the specific test step in the testing protocol in which they are tested. How the RTM is used A requirements traceability matrix is used to check if the current project requirements are being met or to help in the creation of a request for proposal, software requirements specification, various deliverable documents, and project plan tasks. Change Impact Analysis – if a requirement is changing, trace links inform about related and dependent artifacts. These artifacts can easily be verified and if required, be adjusted. The probability to overlook related artifacts is reduced. Coverage Analysis – Traceability ensures that no requirements are overlooked. Especially when certifying safety-critical products it is necessary to demonstrate that all requirements are realized. Project Status Analysis – Tracking of the project status is possible: analyzing the traceability data allows the project manager to see the completion status of the requirements.
    [Show full text]
  • Requirements Engineering and Agile Methodology
    Requirements – Architecture - Agility R. Kuehl/J. Scott Hawker p. 1 R I T Software Engineering Requirements Engineering and Agile Processes (You may be thinking) Requirements engineering model as presented is not very agile Writing a SRS, etc. sounds like a classic heavy weight process It is! But, two points to consider as good software engineers: 1. Fit the software methodology and process to the problem 2. Agile processes do equivalent requirement engineering activities – still need requirements validated by stakeholders for success R. Kuehl/J. Scott Hawker p. 2 R I T Software Engineering Requirements and Agile Traditional approach – the requirements document Agile argument against tradition Communication gaps between authors and readers Change cycle is too long Challenging to capture the complete problem and system context Brain’s capacity to retain information Agile answer: Continuous collaboration with stakeholders . Workshops, conversation Stories (index cards) record conversations Are they the requirements? R. Kuehl/J. Scott Hawker p. 3 R I T Software Engineering Requirements Engineering in Agile Processes Where is the Knowledge? Requirements Eng. Agile Methodology 1. Elicitation 1. Stories 2. Iteration design, 2. Analysis customer collaboration 3. Specification 3. Stories, code, acceptance tests, unit 4. Validation tests 5. Management 4. Customer collaboration, acceptance tests 5. Planning cycle, frequent iterations R. Kuehl/J. Scott Hawker p. 4 R I T Software Engineering A Picture Worth a 1000 Words Requirements Waterfall Incremental Evolutionary “Classic” or agile style Design Always maps Construction (coding & testing) Deployment The Requirements Engineering Model The General Software Engineering Framework R. Kuehl/J. Scott Hawker p. 5 R I T Software Engineering R.
    [Show full text]
  • What Is a Requirement?
    What is a requirement? • May range from – a high-level abstract statement of a service or – a statement of a system constraint to a Software Requirements detailed mathematical functional specification • Requirements may be used for – a bid for a contract Descriptions and specifications • must be open to interpretation of a system – the basis for the contract itself • must be defined in detail • Both the above statements may be called requirements Example Example …… 4.A.5 The database shall support the generation and control of configuration objects; that is, objects which are themselves groupings of other objects in the database. The configuration control facilities shall allow access to the objects in a version group by the use of an incomplete name. …… 1 Types of requirements User requirements readers • Written for customers • Client managers – User requirements • Statements in natural language plus diagrams of the • System end-users services the system provides and its operational constraints. • Client engineers • Written as a contract between client and • Contractor managers contractor – System requirements • System architects • A structured document setting out detailed descriptions of the system services. • Written for developers – Software specification • A detailed software description which can serve as a basis for a design or implementation. System requirements readers Software specification readers • System end-users • Client engineers (maybe) • Client engineers • System architects • System architects • Software developers • Software developers 2 Functional requirements • Statements of services the system should provide, how the system We will come back to user should react to particular inputs and system requirements and how the system should behave in particular situations. Examples of functional Functional requirements requirements • Describe functionality or system services 1.
    [Show full text]
  • A Tutorial for Requirements Analysis
    Project Scope Management Prof. Dr. Daning Hu Department of Informatics University of Zurich Some of the contents are adapted from “System Analysis and Design” by Dennis, Wixom, &Tegarden. Course Review: What do Project Managers Manage? The Triple Constraint of Project Management •Scope &Quality •Time •Cost 2 Course Review: Project Objectives Scope & Quality (fitness for purpose) Budget (to complete it within the budget) Time (to complete it within the given time) It is clear that these objectives are not in harmony! 3 3 Course Review: Requirements Analysis and System Specification Why is it one of first activities in (software) project life cycle? Need to understand what customer wants first! Goal is to understand the customer’s problem. Though customer may not fully understand it! Requirements analysis says: “Make a list of the guidelines we will use to know when the job is done and the customer is satisfied.” Also called requirements gathering or requirements engineering System specification says: “Here’s a description of what the program/system will do (not how) to satisfy the requirements.” Distinguish requirements gathering & system analysis? A top-level exploration into the problem and discovery of whether it can be done and how long it will take. 4 Learning Objectives: Project Scope Management Explain what scope management is and the related processes Discuss methods for collecting and documenting requirements Explain the scope definition process and describe the contents of a Project Scope Statement Discuss the process of constructing a Work Breakdown Structure (WBS) using various approaches Explain the importance of scope verification and control and how to avoid scope problems 5 What is Project Scope Management? Scope refers to all the work involved in creating the products of the project and the processes used to create them.
    [Show full text]