DOCSLIB.ORG

How to Write Requirements

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
How to Write Requirements Telelogic Lifecycle Solutions Get it Right the First Time Telelogic Get it Right the First Time: Writing Better Requirements Part Number: MN-DOR-ED-GTR80-05-01 L License Agreement No part of this publication may be reproduced, transmitted, stored in a retrieval system, nor translated into any human or computer language, in any form or by any means, electronic, mechanical, magnetic, optical, chemical, manual or otherwise, without the prior written permission of the copyright owner, Telelogic AB. Copyright infringement is a serious matter under the United States and foreign Copyright Laws. Telelogic AB reserves the right to revise this publication and to make changes from time to time without obligation to notify authorized users of such changes. Consult Telelogic AB to determine whether any such changes have been made. The terms and conditions governing the licensing of Telelogic software consist solely of those set forth in the written contracts between Telelogic AB and its customers. Restricted Rights Legend/Notice Use, duplication or disclosure by the government is subject to the Restricted Rights restrictions as set forth in subparagraph (c)(1)(ii) of the Rights in Technical Data and Computer Software clause at DFARS 252.227-7013 or FAR 52.227-14, Alternate III, subparagraph (g)(3)(i), each clause of current date. Trademarks Telelogic®, Telelogic DOORS®, Telelogic Tau®, Telelogic DocExpress®, Telelogic Rhapsody®, Telelogic Statemate®, Telelogic ActiveCM®, and Telelogic System Architect® are registered trademarks of Telelogic. Telelogic DOORS®/Analyst™, Telelogic DOORS® XT™, Telelogic DOORS®/Net™, Telelogic Tau®/Architect™, Telelogic Tau®/Developer™, Telelogic Tau®/DoDAF™, Telelogic Tester™, Telelogic SDL Suite™, Telelogic TTCN Suite™, Telelogic Synergy™, Telelogic Change™, Telelogic Dashboard™, Telelogic Focal Point™, Telelogic Logiscope™, Telelogic System Architect®/XT™, Telelogic System Architect®/ERP™, Telelogic System Architect®/Simulator II™, Telelogic System Architect®/Compare™, and Telelogic System Architect®/Publisher™ are trademarks of Telelogic. Adobe, the Adobe logo, Acrobat, the Acrobat logo, FrameMaker, and PostScript are trademarks of Adobe Systems Incorporated or its subsidiaries and may be registered in certain jurisdictions. HP and HP-UX are registered trademarks of Hewlett-Packard Corporation. AIX and INFORMIX are registered trademarks of IBM in the United States. Microsoft, Windows, Windows 2003, Windows XP, Windows Vista and/or other Microsoft products referenced herein are either trademarks or registered trademarks of Microsoft Corporation. Macrovision and FLEXnet are registered trademarks or trademarks of Macrovision Corporation. Netscape and Netscape Enterprise Server are registered trademarks of Netscape Communications Corporation in the United States and other countries. Sun, Sun Microsystems, Solaris, and Java are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States and other countries. Pentium is a trademark of Intel Corporation. All other product or company names mentioned herein may be trademarks or registered trademarks of their respective owners. Notice The information in this document is subject to change without notice. Telelogic makes no warranty of any kind with regard to this material, including, but not limited to, the implied warranties of merchantability and fitness for a particular purpose. Telelogic AB shall not be liable for errors contained herein nor for incidental or consequential damages in connection with the furnishing, performance or use of this material. Copyright © 1993 - 2007 Telelogic AB All rights reserved Table of Contents Chapter 1: About this Manual 1 Chapter 1: How to write better requirements 1 Overview . 1 Guidelines to keep in mind . 1 Remember what requirements are for. 2 Requirements are a human issue . 3 Chapter 2: Definition and structure of a requirement 5 A requirement shall be a complete sentence. 5 Shall, will, and must . 5 Anatomy of a good requirement . 6 Chapter 3: Criteria for a good requirement 7 For each requirement ask the question: . 7 Check the requirements as a set . 7 Guidelines for writing good requirements . 8 Chapter 4: Writing user and system requirements 9 Writing the user requirements . 9 What is a user? . 9 System requirements . 9 Writing system requirements . 10 Making requirements testable . 11 Chapter 5: Sources of user requirements 13 Interview users . 13 Working in the environment . 13 Study analogous or existing systems . 14 Examine suggestions and problem reports. 15 Get It Right The First Time: Writing Better Requirements iii Requirements from the help desk and support teams. 15 Improvements made by users. 15 Unintended uses . 15 Workshops. 16 Prototypes . 17 Chapter 6: Organizing requirements 19 You need structure as well as text . 19 Organizing requirements in practice . 20 Defining the scope . 20 Agree on exactly what to include. 20 Identify priorities . 21 Work out what can be afforded. 21 Putting the requirements in the right place . 21 Chapter 7: Requirementsó Aids for Analysis 23 Status information is essential . 23 Analysis made simple . 23 Chapter 8: Reviews 25 The review process . 25 The review meeting. 26 Capturing the suggestions. 26 Make the necessary changes . 27 Golden rules for reviewing: . 27 Chapter 9: Traceability 29 The complexity of large systems . 29 Chapter 10: Controlling change 31 Forces of change . 31 Tracking change . 31 Allow for feedback . 31 iv Get It Right The First Time: Writing Better Requirements Requirements effort throughout the lifecycle. 32 Other helpful hints on managing change . 32 Chapter A: Appendix: Writing pitfalls to avoid 33 Avoid ambiguity . 33 Don't make multiple requirements . 33 Never build in let-out or escape clauses . 34 Don't ramble . ..
Load more

Recommended publications
  • INCOSE: the FAR Approach “Functional Analysis/Allocation and Requirements Flowdown Using Use Case Realizations”
    in Proceedings of the 16th Intern. Symposium of the International Council on Systems Engineering (INCOSE'06), Orlando, FL, USA, Jul 2006. The FAR Approach – Functional Analysis/Allocation and Requirements Flowdown Using Use Case Realizations Magnus Eriksson1,2, Kjell Borg1, Jürgen Börstler2 1BAE Systems Hägglunds AB 2Umeå University SE-891 82 Örnsköldsvik SE-901 87 Umeå Sweden Sweden {magnus.eriksson, kjell.borg}@baesystems.se {magnuse, jubo}@cs.umu.se Copyright © 2006 by Magnus Eriksson, Kjell Borg and Jürgen Börstler. Published and used by INCOSE with permission. Abstract. This paper describes a use case driven approach for functional analysis/allocation and requirements flowdown. The approach utilizes use cases and use case realizations for functional architecture modeling, which in turn form the basis for design synthesis and requirements flowdown. We refer to this approach as the FAR (Functional Architecture by use case Realizations) approach. The FAR approach is currently applied in several large-scale defense projects within BAE Systems Hägglunds AB and the experience so far is quite positive. The approach is illustrated throughout the paper using the well known Automatic Teller Machine (ATM) example. INTRODUCTION Organizations developing software intensive defense systems, for example vehicles, are today faced with a number of challenges. These challenges are related to the characteristics of both the market place and the system domain. • Systems are growing ever more complex, consisting of tightly integrated mechanical, electrical/electronic and software components. • Systems have very long life spans, typically 30 years or longer. • Due to reduced acquisition budgets, these systems are often developed in relatively short series; ranging from only a few to several hundred units.
    [Show full text]
  • PML, an Object Oriented Process Modelling Language
    PML, an Object Oriented Process Modeling Language Prof. Dr.-Ing. Reiner Anderl 1, and Dipl.-Ing. Jochen Raßler 2 1 Prof. Dr.-Ing. Reiner Anderl, Germany, [email protected] 2 Dipl.-Ing. Jochen Raßler, Germany, [email protected] Abstract: Processes are very important for the success within many business fields. They define the proper application of methods, technologies, tools and company structures in order to reach business goals. Important processes to be defined are manufacturing processes or product development processes for example to guarantee the company’s success. Over the last decades many process modeling languages have been developed to cover the needs of process modeling. Those modeling languages have several limitations, mainly they are still procedural and didn’t follow the paradigm change to object oriented modeling and thus often lead to process models, which are difficult to maintain. In previous papers we have introduced PML, Process Modeling Language, and shown it’s usage in process modeling. PML is derived from UML and hence fully object oriented and uses modern modeling techniques. It is based on process class diagrams that describe methods and resources for process modeling. In this paper the modeling language is described in more detail and new language elements will be introduced to develop the language to a generic usable process modeling language. Keywords: process modeling language, PML, UML 1. Introduction As the tendency of enterprises to collaborate growths steadily, industry faces new challenges managing business processes, product development processes, manufacturing processes and much more. Furthermore, discipline spanning product development processes are increasing, e.
    [Show full text]
  • The Roots of Software Engineering*
    THE ROOTS OF SOFTWARE ENGINEERING* Michael S. Mahoney Princeton University (CWI Quarterly 3,4(1990), 325-334) At the International Conference on the History of Computing held in Los Alamos in 1976, R.W. Hamming placed his proposed agenda in the title of his paper: "We Would Know What They Thought When They Did It."1 He pleaded for a history of computing that pursued the contextual development of ideas, rather than merely listing names, dates, and places of "firsts". Moreover, he exhorted historians to go beyond the documents to "informed speculation" about the results of undocumented practice. What people actually did and what they thought they were doing may well not be accurately reflected in what they wrote and what they said they were thinking. His own experience had taught him that. Historians of science recognize in Hamming's point what they learned from Thomas Kuhn's Structure of Scientific Revolutions some time ago, namely that the practice of science and the literature of science do not necessarily coincide. Paradigms (or, if you prefer with Kuhn, disciplinary matrices) direct not so much what scientists say as what they do. Hence, to determine the paradigms of past science historians must watch scientists at work practicing their science. We have to reconstruct what they thought from the evidence of what they did, and that work of reconstruction in the history of science has often involved a certain amount of speculation informed by historians' own experience of science. That is all the more the case in the history of technology, where up to the present century the inventor and engineer have \*-as Derek Price once put it\*- "thought with their fingertips", leaving the record of their thinking in the artefacts they have designed rather than in texts they have written.
    [Show full text]
  • A Comparative Analysis of Structured and Object-Oriented Programming Methods
    JASEM ISSN 1119-8362 Full-text Available Online at J. Appl. Sci. Environ. Manage. December, 2008 All rights reserved www.bioline.org.br/ja Vol. 12(4) 41 - 46 A Comparative Analysis of Structured and Object-Oriented Programming Methods ASAGBA, PRINCE OGHENEKARO; OGHENEOVO, EDWARD E. CPN, MNCS. Department of Computer Science, University of Port Harcourt, Port Harcourt, Nigeria. [email protected], [email protected]. 08056023566 ABSTRACT: The concepts of structured and object-oriented programming methods are not relatively new but these approaches are still very much useful and relevant in today’s programming paradigm. In this paper, we distinguish the features of structured programs from that of object oriented programs. Structured programming is a method of organizing and coding programs that can provide easy understanding and modification, whereas object- oriented programming (OOP) consists of a set of objects, which can vary dynamically, and which can execute by acting and reacting to each other, in much the same way that a real-world process proceeds (the interaction of real- world objects). An object-oriented approach makes programs more intuitive to design, faster to develop, more amenable to modifications, and easier to understand. With the traditional, procedural-oriented/structured programming, a program describes a series of steps to be performed (an algorithm). In the object-oriented view of programming, instead of programs consisting of sets of data loosely coupled to many different procedures, object- oriented programs
    [Show full text]
  • Leveraging Software Development Approaches in Systems Engineering
    Raytheon Leveraging Software Development Approaches in Systems Engineering Rick Steiner Engineering Fellow Raytheon Integrated Defense Systems [email protected] 6 May 2004 Naval Postgraduate School SI4000 Project Seminar Copyright © 2003 Raytheon Company UNPUBLISHED WORK ALL RIGHTS RESERVED 1 We’re going to talk about: Raytheon • Why Software Tools exist, why Systems Engineers should care • Software vs. SE as a discipline – key differences • The importance of requirements – Different requirement/system development approaches – Pros & cons of each, and how they relate to software approaches • How Use Cases relate to Requirements – Hints on how to manage use case development • How Object Oriented Design relates to Functional Analysis – or not! • What graphical languages can help (UML, SysML) • The promise of Model Driven Architecture (MDA) Copyright © 2003 Raytheon Company UNPUBLISHED WORK ALL RIGHTS RESERVED 2 Software Development Crisis Raytheon • In the 1980’s, software development underwent a crisis: – Software was RAPIDLY proliferating – Software was becoming very complex • Software on top of Software (OS, Application) • Software talking to Software (interfaces) – Software development delays were holding up system delivery – Software was becoming very expensive to develop and maintain – Software development effort was becoming very hard to estimate – Software reliability was becoming problematic – Existing techniques were proving inadequate to manage the problem • Reasons: – Economics • Processing hardware (silicon) got cheap –
    [Show full text]
  • Extending and Evaluating the Model-Based Product Definition
    NIST GCR 18-015 Extending and Evaluating the Model-based Product Definition Nathan W. Hartman Jesse Zahner Purdue University This publication is available free of charge from: https://doi.org/10.6028/NIST.GCR.18-015 NIST GCR 18-015 Extending and Evaluating the Model-based Product Definition Prepared for Thomas D. Hedberg, Jr. Allison Barnard Feeney U.S. Department of Commerce Engineering Laboratory National Institute of Standards and Technology Gaithersburg, MD 20899-8260 By Nathan W. Hartman Jesse Zahner PLM Center of Excellence Purdue University This publication is available free of charge from: https://doi.org/10.6028/NIST.GCR.18-015 December 2017 U.S. Department of Commerce Wilbur L. Ross, Jr., Secretary National Institute of Standards and Technology Walter Copan, NIST Director and Undersecretary of Commerce for Standards and Technology Disclaimer Any opinions, findings, conclusions, or recommendations expressed in this publication do not necessarily reflect the views of the National Institute of Standards and Technology (NIST). Additionally, neither NIST nor any of its employees make any warranty, expressed or implied, nor assume any legal liability or responsibility for the accuracy, completeness, or usefulness of any information, product, or process included in this publication. The report was prepared under cooperative agreement 70NANB15H311 between the National Institute of Standards and Technology and Purdue University. The statements and conclusions contained in this report are those of the authors and do not imply recommendations or endorsements by the National Institute of Standards and Technology. Certain commercial systems are identified in this report. Such identification does not imply recommendation or endorsement by the National Institute of Standards and Technology.
    [Show full text]
  • Chapter 1: Introduction
    Just Enough Structured Analysis Chapter 1: Introduction “The beginnings and endings of all human undertakings are untidy, the building of a house, the writing of a novel, the demolition of a bridge, and, eminently, the finish of a voyage.” — John Galsworthy Over the River, 1933 www.yourdon.com ©2006 Ed Yourdon - rev. 051406 In this chapter, you will learn: 1. Why systems analysis is interesting; 2. Why systems analysis is more difficult than programming; and 3. Why it is important to be familiar with systems analysis. Chances are that you groaned when you first picked up this book, seeing how heavy and thick it was. The prospect of reading such a long, technical book is enough to make anyone gloomy; fortunately, just as long journeys take place one day at a time, and ultimately one step at a time, so long books get read one chapter at a time, and ultimately one sentence at a time. 1.1 Why is systems analysis interesting? Long books are often dull; fortunately, the subject matter of this book — systems analysis — is interesting. In fact, systems analysis is more interesting than anything I know, with the possible exception of sex and some rare vintages of Australian wine. Without a doubt, it is more interesting than computer programming (not that programming is dull) because it involves studying the interactions of people, and disparate groups of people, and computers and organizations. As Tom DeMarco said in his delightful book, Structured Analysis and Systems Specification (DeMarco, 1978), [systems] analysis is frustrating, full of complex interpersonal relationships, indefinite, and difficult.
    [Show full text]
  • Formalized Structured Analysis Specifications David L
    Iowa State University Capstones, Theses and Retrospective Theses and Dissertations Dissertations 1991 Formalized structured analysis specifications David L. Coleman Iowa State University Follow this and additional works at: https://lib.dr.iastate.edu/rtd Part of the Computer Sciences Commons, and the Mathematics Commons Recommended Citation Coleman, David L., "Formalized structured analysis specifications " (1991). Retrospective Theses and Dissertations. 9634. https://lib.dr.iastate.edu/rtd/9634 This Dissertation is brought to you for free and open access by the Iowa State University Capstones, Theses and Dissertations at Iowa State University Digital Repository. It has been accepted for inclusion in Retrospective Theses and Dissertations by an authorized administrator of Iowa State University Digital Repository. For more information, please contact [email protected]. INFORMATION TO USERS This manuscript has been reproduced from the microfihn master. UMI fUms the text directly &om the original or copy submitted. Thus, some thesis and dissertation copies are in typewriter face, while others may be from any type of computer printer. The quality of this reproduction is dependent upon the quality of the copy submitted. Broken or indistinct print, colored or poor quality illustrations and photographs, print bleedthrough, substandard margins, and improper alignment can adversely afifect reproduction. In the unlikely event that the author did not send UMI a complete manuscript and there are missing pages, these will be noted. Also, if unauthorized copyright material had to be removed, a note will indicate the deletion. Oversize materials (e.g., maps, drawings, charts) are reproduced by sectioning the original, beginning at the upper left-hand corner and continuing from left to right in equal sections with small overlaps.
    [Show full text]
  • & Evocean Bridging the Enterprise Architecture to IT Architecture
    & Evocean Bridging the Enterprise Architecture to IT Architecture Gap Presented by Jog Raj 31st January 2008 © Telelogic AB Agenda • Introductions • The Business Challenge • What is Enterprise Architecture • Bridging the Business and IT gap • Service Orientated Architectures • Role of Tools in Architecture • Demonstration • Questions & Answers • Summary © Telelogic AB Telelogic At A Glance • Founded 1983 • HQ Malmö, Sweden • US HQ Irvine, California • Public Company Listed in 1999 • Development Sites USA, Sweden, UK, India © Telelogic AB Global Presence Over 40 offices around the world As of September 2004 © Telelogic AB Bridging the Enterprise Architecture to IT Architecture Gap © Telelogic AB Current Business Challenges • Hypercompetitive Market – Innovation – Ability to implement ideas • Mergers and Acquisitions • Governance and Compliance • Reduce Cost – Operational costs – IT Asset Management • Reuse of assets • Application Integration Costs • Risk Reduction and Mitigation © Telelogic AB A Growing Divide? Business Challenges and Opportunities Business Process Adaptability The Internet 1990s 2000s © Telelogic AB What is Enterprise Architecture? • A description of business and IT domains: – Mission, Strategy, Landscape, Organization, People, Locations – Processes, Technology, Information, Data, Applications • A description of the relationships between them • A set of graphical and textual models and artefacts that can be communicated in a common manner • An Enterprise Architecture supports an operating business in achieving its goals
    [Show full text]
  • Course Name : Structured and Object Oriented Analysis and Design
    GUJARAT TECHNOLOGICAL UNIVERSITY MASTER OF COMPUTER APPLICATIONS (MCA) Semester: III Subject: Structured & Object Oriented Analysis and Design Methodology (SOOADM) Subject Code: 630001 (W.E.F June 2012) Learning Objectives : System Analysis and Design is a practical field that relies on a core set of concepts and principles. The objective of this course is to teach the students tried-and-tested techniques widely embraced by experienced analysts plus new and emerging tools and techniques that recent graduates are expected to apply on the job. The course is meant to give balanced exposure to both traditional and object oriented approaches to system analysis & design. Prerequisites : Fundamentals of Structured Programming and Fundamentals of Object Oriented Programming Contents : 1. System Analysis Fundamentals [4 hrs.] Types of Systems, Role of the System Analyst, Systems Development Life Cycle, CASE Tools, Interviewing, Joint Application Development, Using Questionnaires 2. Analysis Modeling [10 hrs.] Data Flow Approach, Developing Data Flow Diagrams, Logical and Physical Data Flow Diagrams, Data Dictionary, Creating Data Dictionary, Using Data Dictionary, Process Specifications, Structured English, Decision Tables, Decision Trees 3. System Design [10 hrs.] Designing Effective Output, Output Design Objectives, Designing a Web Site, Form Design, Web Forms Design, Human-Computer Interaction, Types of Interfaces, Dialog Design, Designing Queries, Effective Coding, Effective Data Capture, Input Validation 4. Object Modeling Concepts [10 hrs.] Introduction, Modeling as a design technique, Class Modeling-Object and Classes, Association, Generalization, aggregation, Abstract class, Multiple inheritance, Metadata, Reification, Constraints, Derived data, Packages, State Modeling- State, Transitions and Conditions, State Diagrams, Nested state diagrams , Nested States, Signal Generalization, Concurrency 5. Basic Structural Modeling [4 hrs.] Classes, Relationships, Common Mechanisms, Diagrams, Class Diagrams 6.
    [Show full text]
  • Chap 1. Introduction to Software Architecture
    Chap 1. Introduction to Software Architecture 1. Introduction 2. IEEE Recommended Practice for Architecture Modeling 3. Architecture Description Language: the UML 4. The Rational Unified Process (RUP) 1 1. Introduction Preamble “Conventional wisdom has been to use terms like ‘software architecture’, ‘software architectural design’, or ‘coarse-grained design’ for the high-level structural subdivision of a system, and ‘design’ or ‘detailed design’ for more detailed planning… we denote the whole activity of constructing a software system as ‘software design’ and the resulting artifacts as ‘software architecture’.” “Many developers nowadays prefer the term ‘software architecture’ to ‘software design’ for denoting all the artifacts that result from design activities.” “In doing so, they want to express the fact that they do not just decompose the functionality of a system into a set of cooperating components, but rather that they construct a software architecture… They no longer agree that high-level design decisions can be made independently of lower-level decisions.” From “Pattern-Oriented Software Architecture, A System of Patterns” By F. Buschmann, R. Meunier, H. Rohnert, P. Sommerlad, M. Stal 2 Software Architecture as a Design Plan Software architecture provides a design plan, a blueprint of a system, an abstraction to help manage the complexity of a system, and also a communication medium between stakeholders. Critical factor for a product’s success: good software architecture that is understood by the stakeholders and by the developers. Structural plan that describes the elements of the system, how they fit together, and how they work together to fulfill the system’s requirements. •Used to negotiate system requirements, and to set expectations with customers, marketing and management personnel.
    [Show full text]
  • DCSA Information Model 3.0
    DCSA Information Model 3.0 December 2020 Table of contents Version history __________________________________________________ 8 1 Introduction __________________________________________________ 9 1.1 Preface ______________________________________________________ 9 1.2 Purpose ______________________________________________________ 9 1.3 Overview _____________________________________________________ 10 1.4 Conformance __________________________________________________ 10 1.5 Supporting publications ___________________________________________ 10 2 DCSA Information Model 3.0 ________________________________________ 13 2.1 Introduction ___________________________________________________ 13 2.2 Selected data modelling terms defined _________________________________ 14 2.3 The DCSA Information Model data types and formats ________________________ 15 2.3.1 Attribute naming conventions ____________________________________ 16 3 Logical Data Model ____________________________________________ 18 4 Logical Data Model usage ________________________________________ 20 4.1 Track and trace (T&T) ____________________________________________ 20 4.2 Operational vessel schedules (OVS) ___________________________________ 21 4.3 eDocumentation _______________________________________________ 23 5 Subject areas in the Logical Data Model _______________________________ 25 5.1 Shipment ____________________________________________________ 26 5.1.1 Shipment reference data _______________________________________ 31 5.2 Transport Document _____________________________________________
    [Show full text]