IEEE Guide For Developing System Requirements Specifications - IEEE

To view this page ensure that Adobe Flash Player version 9.0.124 or greater is installed.

Please login or register to make a comment!

The Institute of Electrical and Electronics Engineers, Inc. 345 East 47th Street, New York, NY 10017-2394, USA Copyright © 1998 by the Institute of Electrical and Electronics Engineers, Inc. All rights reserved.

Published 22 December 1998. Printed in the United States of America. Print: ISBN 0-7381-0337-3 SH94659 PDF: ISBN 0-7381-1515-0 SS94659 No part of this publication may be reproduced in any form, in an electronic retrieval system or otherwise, without the prior written permission of the publisher.

IEEE Std 1233, 1998 Edition (Includes IEEE Std 1233-1996 and IEEE Std 1233a-1998) IEEE Guide for Developing System Requirements Speci*cations Sponsor Software Engineering Standards Committee of the IEEE Computer Society IEEE Std 1233-1996 Approved 17 April 1996 IEEE Std 1233a-1998 Approved 8 December 1998 by the IEEE-SA Standards Board Abstract: Guidance for the development of the set of requirements, System Requirements Speci- fication (SyRS), that will satisfy an expressed need is provided. Developing an SyRS includes the identification, organization, presentation, and modification of the requirements. Also addressed are the conditions for incorporating operational concepts, design constraints, and design configuration requirements into the specification.

This guide also covers the necessary characteristics and qual- ities of individual requirements and the set of all requirements. Keywords: requirement, SyRS, system, ... more. less.

system requirements speci;cation IEEE Standards documents are developed within the IEEE Societies and the Standards Coordinat- ing Committees of the IEEE Standards Association (IEEE-SA) Standards Board. Members of the committees serve voluntarily and without compensation. They are not necessarily members of the Institute. The standards developed within IEEE represent a consensus of the broad expertise on the subject within the Institute as well as those activities outside of IEEE that have expressed an inter- est in participating in the development of the standard. Use of an IEEE Standard is wholly voluntary. The existence of an IEEE Standard does not imply that there are no other ways to produce, test, measure, purchase, market, or provide other goods and services related to the scope of the IEEE Standard. Furthermore, the viewpoint expressed at the time a standard is approved and issued is subject to change brought about through developments in the state of the art and comments received from users of the standard. Every IEEE Standard is sub- jected to review at least every Lve years for revision or reafLrmation. When a document is more than Lve years old and has not been reafLrmed, it is reasonable to conclude that its contents, although still of some value, do not wholly reMect the present state of the art. Users are cautioned to check to determine that they have the latest edition of any IEEE Standard. Comments for revision of IEEE Standards are welcome from any interested party, regardless of membership afLliation with IEEE. Suggestions for changes in documents should be in the form of a proposed change of text, together with appropriate supporting comments. Interpretations: Occasionally questions may arise regarding the meaning of portions of standards as they relate to speciLc applications. When the need for interpretations is brought to the attention of IEEE, the Institute will initiate action to prepare appropriate responses. Since IEEE Standards rep- resent a consensus of all concerned interests, it is important to ensure that any interpretation has also received the concurrence of a balance of interests. For this reason, IEEE and the members of its societies and Standards Coordinating Committees are not able to provide an instant response to interpretation requests except in those cases where the matter has previously received formal consideration. Comments on standards and requests for interpretations should be addressed to: Secretary, IEEE-SA Standards Board 445 Hoes Lane P.O. Box 1331 Piscataway, NJ 08855-1331 USA Authorization to photocopy portions of any individual standard for internal or personal use is granted by the Institute of Electrical and Electronics Engineers, Inc., provided that the appropriate fee is paid to Copyright Clearance Center. To arrange for payment of licensing fee, please contact Copyright Clearance Center, Customer Service, 222 Rosewood Drive, Danvers, MA 01923 USA; (978) 750-8400. Permission to photocopy portions of any individual standard for educational class- room use can also be obtained through the Copyright Clearance Center. Note: Attention is called to the possibility that implementation of this standard may require use of subject matter covered by patent rights. By publication of this standard, no position is taken with respect to the existence or validity of any patent rights in connection therewith. The IEEE shall not be responsible for identifying patents for which a license may be required by an IEEE standard or for conducting inquiries into the legal validity or scope of those patents that are brought to its attention. Copyright © 1998 IEEE. All rights reserved. iii Introduction (This introduction is not a part of IEEE Std 1233, 1998 Edition, IEEE Guide for Developing System Requirements Spec- iLcations.) The purpose of this guide is to provide guidance for capturing system requirements. This guide serves the analyst by providing a clear deLnition for identifying well-formed requirements and ways of organizing them. This guide should be used to help the analyst capture requirements at the beginning of the system require- ments phase. It should be used to clarify what constitutes a good requirement and provide an understanding of where to look to identify different requirement sources. The readers of this guide are referred to Annex C for guidelines for using this guide to meet the requirements of IEEE/EIA 12207.1-1997, IEEE/EIA Guide for Information Technology 4Software life cycle processes 4 Life cycle data. Participants IEEE Std 1233-1996 was prepared by a working group chartered by the Software Engineering Committee of the IEEE Computer Society. At the time it was approved, the working group consisted of the following members: Louis E. Miller, Chair William N. Sabor, Secretary Other contributors included The following persons balloted IEEE Std 1233-1996: Bakul Banerjee David Byrch Kim A. Cady Larry Diehr Charles A. Droz Larry C. Forrest P. Michael Guba James R. Hughes Joe Iaquinto Marybeth A. Jupina Thomas M. Kurihara Richard C. Lee Jim Longbucco Donald F. Parsons Eric Peterson John Sheckler Jess Thompson Eva D. Williams Geoff Cozens Paul Davis Kristin Dittmann Christof Ebert Don McCash Virginia Nuckolls Anne O 9Neill H. Ronald Berlack Mark Bilger William J. Boll Fletcher Buckley Edward R. Byrne François Coallier Christopher Cooke Geoff Cozens Alan M. Davis Robert E. Dwyer Sherman Eagles Leo G. Egan Caroline L. Evans Richard L. Evans John W. Fendrich Peter Fillery Larry Forrest Eugene P. Friedman Eitan Froumine Yair Gershkovitch Adel N. Ghannam Julio Gonzalez-Sanz Patrick J. GrifLn David A. Gustavson John Harauz Derek J. Hatley William HeMey Umesh P. Hiriyannaiah Jody Howard Eiichi Kaneko Jerry Kickenson Janet Kintner Thomas M. Kurihara Renee Lamb John B. Lane Boniface Lau J. Dennis Lawrence Ben Livson Harold Mains Roger Martin James W. McClean Sue McGrath Louis E. Miller Dennis E. Nickle Indradeb P. Pal Joseph A. Palermo Stephen R. Schach Norman Schneidewind Wolf A. Schnoege Gregory D. Schumacher Carl S. Seddio David M. Siefert Richard S. Sky Alfred R. Sorkowitz iv Copyright © 1998 IEEE. All rights reserved. IEEE Std 1233a-1998 was prepared by the Life Cycle Data Harmonization Working Group of the Software Engineering Standards Committee of the IEEE Computer Society. At the time it was approved, the working group consisted of the following members: Leonard L. Tripp, Chair The following persons balloted IEEE Std 1233a-1998: Robert N. Sulgrove Tanehiro Tatsuta Richard H. Thayer George D. Tice Leonard L. Tripp Tom Vaiskunas Thomas E. Vollman Ronald L. Wade Dolores Wallace William M. Walsh Paul R. Work Janusz Zalewski Edward Byrne Paul R. Croll Perry DeWeese Robin Fralick Marilyn Ginsberg-Finner John Harauz Mark Henley Dennis Lawrence David Maibor Ray Milovanovic James Moore Timothy Niesen Dennis Rilling Terry Rout Richard Schmidt Norman F. Schneidewind David Schultz Basil Sherlund Peter Voldner Ronald Wade Syed Ali Robert E. Barry Leo Beltracchi H. Ronald Berlack Richard E. Biehl Michael A. Blackledge Sandro Bologna Kathleen L. Briggs M. Scott Buck Michael Caldwell James E. Cardow Enrico A. Carrara Antonio M. Cicu Theo Clarke Sylvain Clermont Rosemary Coleman Virgil Lee Cooper W. W. Geoff Cozens Paul R. Croll Gregory T. Daich Geoffrey Darnton Taz Daughtrey Bostjan K. Derganc Perry R. DeWeese Evelyn S. Dow Carl Einar Dragstedt Sherman Eagles Christof Ebert Leo Egan Richard E. Fairley John W. Fendrich Jay Forster Kirby Fortenberry Eva Freund Barry L. Garner Marilyn Ginsberg-Finner John Garth Glynn Julio Gonzalez-Sanz L. M. Gunther David A. Gustafson Jon D. Hagar John Harauz Herbert Hecht William HeMey Mark Heinrich Debra Herrmann John W. Horch Jerry Huller Peter L. Hung George Jackelen Frank V. Jorgensen Vladan V. Jovanovic William S. Junk George X. Kambic Ron S. Kenett Judith S. Kerner Robert J. Kierzyk Thomas M. Kurihara John B. Lane J. Dennis Lawrence Randal Leavitt Fang Ching Lim John Lord Stan Magee Harold Mains Robert A. Martin Tomoo Matsubara Patrick D. McCray Bret Michael Alan Miller James W. Moore Pavol Navrat Alex Polack Peter T. Poon Lawrence S. Przybylski Kenneth R. Ptack Annette D. Reilly Dennis Rilling Helmut Sandmayr Stephen R. Schach Norman Schneidewind David J. Schultz Lisa A. Selmon Robert W. Shillato David M. Siefert Carl A. Singer Richard S. Sky Alfred R. Sorkowitz Donald W. Sova Luca Spotorno Julia Stesney Fred J. Strauss Toru Takeshita Richard H. Thayer Booker Thomas Patricia Trellue Leonard L. Tripp Theodore J. Urbanowicz Glenn D. Venables Udo Voges David D. Walden Dolores Wallace William M. Walsh John W. Walz Scott A. Whitmire P. A. Wolfgang Paul R. Work Natalie C. Yopconka Janusz Zalewski Geraldine Zimmerman Peter F. Zoll Copyright © 1998 IEEE. All rights reserved. v When the IEEE-SA Standards Board approved IEEE Std 1233a-1998 on 8 December 1998, it had the following membership: Richard J. Holleman, Chair Donald N. Heirman, Vice Chair Judith Gorman, Secretary *Member Emeritus Valerie E. Zelenty IEEE Standards Project Editor Satish K. Aggarwal Clyde R. Camp James T. Carlo Gary R. Engmann Harold E. Epstein Jay Forster* Thomas F. Garrity Ruben D. Garzon James H. Gurney Jim D. Isaak Lowell G. Johnson Robert Kennelly E. G. cAl d Kiener Joseph L. KoepLnger* Stephen R. Lambert Jim Logothetis Donald C. Loughry L. Bruce McClung Louis-François Pau Ronald C. Petersen Gerald H. Peterson John B. Posey Gary S. Robinson Hans E. Weinrich Donald W. Zipse vi Copyright © 1998 IEEE. All rights reserved. Contents 1. Overview.................................................................................................................... .......................... 1 1.1 Scope...................................................................................................................... ...................... 1 2. References.................................................................................................................. .......................... 1 3. Definitions................................................................................................................. ........................... 2 4. System requirements specification .......................................................................................... ............ 4 4.1 Definition................................................................................................................. .................... 4 4.2 Properties................................................................................................................. .................... 4 4.3 Purpose.................................................................................................................... ..................... 5 4.4 Intended use............................................................................................................... .................. 6 4.5 Benefits................................................................................................................... ..................... 6 4.6 Dynamics of system requirements............................................................................................ ... 7 5. SyRS development process overview........................................................................................... ....... 7 5.1 Customer................................................................................................................... ................... 7 5.2 Environment................................................................................................................ ................. 8 5.3 Technical community........................................................................................................ ......... 10 6. Well-formed requirements.................................................................................................... ............. 11 6.1 Definition of a well-formed requirement................................................................................... 11 6.2 Properties of a requirement................................................................................................ ........ 12 6.3 Categorization............................................................................................................. ............... 13 6.4 Pitfalls................................................................................................................... ..................... 14 7. SyRS development............................................................................................................ ................. 15 7.1 Identify requirements...................................................................................................... ........... 15 7.2 Build a well-formed requirement............................................................................................ ...17 7.3 Organize requirements...................................................................................................... ......... 18 7.4 Present requirements....................................................................................................... ...........19 Annex A (informative) System Requirements Specification outline.......................................................... 20 Annex B (informative) Bibliography............................................................................................. ............. 24 Annex C (informative) Guidelines for compliance with IEEE/EIA 12207.1-1997.................................... 25 Copyright © 1998 IEEE. All rights reserved. 1 IEEE Guide for Developing System Requirements SpeciÞcations 1. Overview 1.1 Scope This guide provides guidance for the development of a set of requirements that, when realized, will satisfy an expressed need. In this guide that set of requirements will be called the System Requirements SpeciÞca- tion (SyRS). Developing an SyRS includes the identiÞcation, organization, presentation, and modiÞcation of the requirements. This guide addresses conditions for incorporating operational concepts, design constraints, and design conÞguration requirements into the speciÞcation. This guide also addresses the necessary charac- teristics and qualities of individual requirements and the set of all requirements. This guide does not specify industry-wide system speciÞcation standards nor state a mandatory System Requirements SpeciÞcation. This guide is written under the premise that the current state of the art of system development does not warrant or support a formal standards document. 2. References This guide shall be used in conjunction with the following publications: IEEE Std 100-1996, IEEE Standard Dictionary of Electrical and Electronics Terms. 1 IEEE Std 610.12-1990, IEEE Standard Glossary of Software Engineering Terminology. IEEE Std 730-1998, IEEE Standard for Software Quality Assurance Plans. IEEE Std 828-1998, IEEE Standard for Software ConÞguration Management Plans. IEEE Std 830-1998, IEEE Recommended Practice for Software Requirements SpeciÞcations. IEEE Std 1074-1997, IEEE Standard for Developing Software Life Cycle Processes. 1 IEEE publications are available from the Institute of Electrical and Electronics Engineers, 445 Hoes Lane, P.O. Box 1331, Pisca taway, NJ 08855-1331, USA (http://www.standards.ieee.org/). IEEE Std 1233, 1998 Edition IEEE GUIDE FOR 2 Copyright © 1998 IEEE. All rights reserved. IEEE Std 1220-1998, IEEE Standard for Application and Management of the Systems Engineering Process. ISO 9000-1: 1994, Quality management and quality assurance standardsÑPart 1: Guidelines for selection and use. 2 ISO 9126: 1991, Information technologyÑSoftware product evaluationÑQuality characteristics and guide- lines for their use. MIL-STD-490A, SpeciÞcation Practices. 3 MIL-STD-498, Software Development and Documentation. 3. DeÞnitions The deÞnitions listed below establish meaning in the context of this guide. Terms not deÞned in this guide are included in IEEE Std 610.12-1990. 4 3.1 analyst: A member of the technical community (such as a systems engineer or business analyst, develop- ing the system requirements) who is skilled and trained to deÞne problems and to analyze, develop, and express algorithms. 3.2 annotation: Further documentation accompanying a requirement such as background information and/ or descriptive material. 3.3 baseline: A speciÞcation or system that has been formally reviewed and agreed upon, that thereafter serves as the basis for further development and can be changed only through formal change control proce- dures. (IEEE Std 610.12-1990) 3.4 constraint: A statement that expresses measurable bounds for an element or function of the system. That is, a constraint is a factor that is imposed on the solution by force or compulsion and may limit or modify the design changes. 3.5 customer(s): The entity or entities for whom the requirements are to be satisÞed in the system being deÞned and developed. This can be an end-user of the completed system, an organization within the same company as the developing organization (e.g., System Management), a company or entity external to the developing company, or some combination of all of these. This is the entity to whom the system developer must provide proof that the system developed satisÞes the system requirements speciÞed. 3.6 derived requirement: A requirement deduced or inferred from the collection and organization of requirements into a particular system conÞguration and solution. 3.7 element: A component of a system; may include equipment, a computer program, or a human. 3.8 end user: The person or persons who will ultimately be using the system for its intended purpose. 2 ISO publications are available from the ISO Central Secretariat, Case Postale 56, 1 rue de Varemb}, CH-1211, Gen"ve 20, Switzer - land/Suisse (http://www.iso.ch/). ISO publications are also available in the United States from the Sales Department, American National Standards Institute, 11 West 42nd Street, 13th Floor, New York, NY 10036, USA (http://www.ansi.org/). 3 MIL publications are available from Customer Service, Defense Printing Service, 700 Robbins Ave., Bldg. 4D, Philadelphia, PA 19111-5094, USA. 4 Information on references can be found in Clause 2. IEEE DEVELOPING SYSTEM REQUIREMENTS SPECIFICATIONS Std 1233, 1998 Edition Copyright © 1998 IEEE. All rights reserved. 3 3.9 environment: The circumstances, objects, and conditions that will inßuence the completed system; they include political, market, cultural, organizational, and physical inßuences as well as standards and policies that govern what the system must do or how it must do it. 3.10 function: A task, action, or activity that must be accomplished to achieve a desired outcome. 3.11 model: A representation of a real world process, device, or concept. 3.12 prototype: An experimental model, either functional or nonfunctional, of the system or part of the sys- tem. A prototype is used to get feedback from users for improving and specifying a complex human inter- face, for feasibility studies, or for identifying requirements. 3.13 raw requirement: An environmental or customer requirement that has not been analyzed and formu- lated as a well-formed requirement. 3.14 representation: A likeness, picture, drawing, block diagram, description, or symbol that logically por- trays a physical, operational, or conceptual image or situation. 3.15 requirement: (A) A condition or capability needed by a user to solve a problem or achieve an objec- tive. (B) A condition or capability that must be met or possessed by a system or system component to satisfy a contract, standard, speciÞcation, or other formally imposed document. (C) A documented representation of a condition or capability as in deÞnition (A) or (B). (IEEE Std 610.12-1990) 3.16 system: An interdependent group of people, objects, and procedures constituted to achieve deÞned objectives or some operational role by performing speciÞed functions. A complete system includes all of the associated equipment, facilities, material, computer programs, Þrmware, technical documentation, services, and personnel required for operations and support to the degree necessary for self-sufÞcient use in its intended environment. 3.17 System Requirements SpeciÞcation (SyRS): A structured collection of information that embodies the requirements of the system. 3.18 testability: The degree to which a requirement is stated in terms that permit establishment of test crite- ria and performance of tests to determine whether those criteria have been met. (IEEE Std 610.12-1990) 3.19 traceability: The degree to which a relationship can be established between two or more products of the development process, especially products having a predecessor-successor or master-subordinate relation- ship to one another; e.g., the degree to which the requirements and design of a given system element match. (IEEE Std 610.12-1990) 3.20 validation: The process of evaluating a system or component during or at the end of the development process to determine whether a system or component satisÞes speciÞed requirements. (IEEE Std 610.12- 1990) 3.21 veriÞcation: The process of evaluating a system or component to determine whether the system of a given development phase satisÞes the conditions imposed at the start of that phase. (IEEE Std 610.12-1990) 3.22 well-formed requirement: A statement of system functionality (a capability) that can be validated, and that must be met or possessed by a system to solve a customer problem or to achieve a customer objective, and is qualiÞed by measurable conditions and bounded by constraints. IEEE Std 1233, 1998 Edition IEEE GUIDE FOR 4 Copyright © 1998 IEEE. All rights reserved. 4. System requirements speciÞcation A System Requirements SpeciÞcation (SyRS) has traditionally been viewed as a document that communi- cates the requirements of the customer to the technical community who will specify and build the system. The collection of requirements that constitutes the speciÞcation and its representation acts as the bridge between the two groups and must be understandable by both the customer and the technical community. One of the most difÞcult tasks in the creation of a system is that of communicating to all of the subgroups within both groups, especially in one document. This type of communication generally requires different formal- isms and languages. 4.1 DeÞnition The SyRS presents the results of the deÞnition of need, the operational concept, and the system analysis tasks. As such, it is a description of what the systemÕs customers expect it to do for them, the systemÕs expected environment, the systemÕs usage proÞle, its performance parameters, and its expected quality and effectiveness. Thus it presents the conclusions of the SyRS development process described in Clause 5. This guide suggests a distinction between this structured collection of information and the way in which it is presented to its various audiences. The presentation of the SyRS should take a form that is appropriate for its intended use. This can be a paper document, models, prototypes, other non-paper document representations, or any combination. All of these representations can be derived from this one SyRS to meet the needs of a speciÞc audience. However, care should be taken to ensure that each of these presentations is traceable to a common source of system requirements information. The audience should be made aware that this struc- tured collection of information remains the one deÞnitive source for resolving ambiguities in the particular presentation chosen. This guide makes a clear distinction between the system requirements (what the system must do) contained in the SyRS and process requirements (how to construct the system) that should be contained in contract documents such as a Statement of Work. 4.2 Properties The collection of requirements should have the following properties: a) Unique set. Each requirement should be stated only once. b) Normalized. Requirements should not overlap (i.e, they shall not refer to other requirements or the capabilities of other requirements). c) Linked set. Explicit relationships should be deÞned among individual requirements to show how the requirements are related to form a complete system. d) Complete. An SyRS should include all the requirements identiÞed by the customer, as well as those needed for the deÞnition of the system. e) Consistent. SyRS content should be consistent and noncontradictory in the level of detail, style of requirement statements, and in the presentation of material. f) Bounded. The boundaries, scope, and context for the set of requirements should be identiÞed. g) ModiÞable. The SyRS should be modiÞable. Clarity and nonoverlapping requirements contribute to this. h) ConÞgurable. Versions should be maintained across time and across instances of the SyRS. i) Granular. This should be the level of abstraction for the system being deÞned. IEEE DEVELOPING SYSTEM REQUIREMENTS SPECIFICATIONS Std 1233, 1998 Edition Copyright © 1998 IEEE. All rights reserved. 5 4.3 Purpose The purpose of the SyRS is to provide a Òblack-boxÓ description of what the system should do, in terms of the systemÕs interactions or interfaces with its external environment. The SyRS should completely describe all inputs, outputs, and required relationships between inputs and outputs. The SyRS organizes and commu- nicates requirements to the customer and the technical community. 4.3.1 Organizing requirements The purpose of the SyRS can best be achieved by organizing the system requirements into conceptual cate- gories. In practice, it is difÞcult to identify and separate requirements from other aspects of the customerÕs perception of the system that are often included in documents that deÞne Òrequirements.Ó Often, traditional user procedures or user or technical community assumptions about the implementation cloud the fundamen- tal statement of need. The analyst should capture and state the fundamental needs of the customer and the technical community, properly form requirements, and organize or group these needs and requirements into meaningful categories. While organizing the unstructured usersÕ statements into a structured set of requirements, the analyst should identify technical requirements without being diverted into stating an implementation approach. To be dis- tracted into implementation issues before a clear understanding of the requirements is achieved may lead to both an inadequate statement of requirements and a faulty implementation. Discerning between technical requirements and technical implementations is a constant challenge to the analyst. The description of the system should be stated in operational and logistical terms. Issues addressed include the systemÕs desired operational capabilities; physical characteristics; performance parameters and expected values; interfaces and interactions with its environment; documentation requirements; reliability require- ments; logistical requirements; and personnel requirements. These requirements should be communicated in a structured manner to ensure that the customer and techni- cal community are able to do the following: a) Identify requirements that are derived from other requirements; b) Organize requirements of different levels of detail into their appropriate levels; c) Verify the completeness of the set of requirements; d) Identify inconsistencies among requirements; e) Clearly identify the capabilities, conditions, and constraints for each requirement; f) Develop a common understanding with the customer of the purpose and objectives of the set of requirements; g) Identify requirements that will complete the SyRS. It is important that structure be added to the set of requirements by the analysts, and that representations of the SyRS communicate the requirements in a structured manner. Clause 6 provides guidelines for explicitly deÞning the requirements. 4.3.2 Communicating to two audiences The SyRS has two primary audiences and essentially serves to document an agreement between the customer and the technical community. IEEE Std 1233, 1998 Edition IEEE GUIDE FOR 6 Copyright © 1998 IEEE. All rights reserved. 4.3.2.1 Customer Customer is a collective term that may include the customer of the proposed system, the funding agency, the acceptor who will sign-off delivery, and the managers who will be responsible for overseeing the implemen- tation, operation, and maintenance of the system. All customers will have vested interests and concerns that should be resolved in the SyRS. In addition, some customers may not understand the process of establishing requirements or the process of creating a system. Although competent in their areas of responsibility and in the application for which the system is being deÞned, they generally may not be familiar with the vocabulary and representation techniques that are often used to specify requirements. Since one of the primary goals of system requirements analysis is to ensure that the SyRS is understood, it will be necessary to provide the customers with a representation of the SyRS in a language that the customer understands and that is complete, concise, and clear. 4.3.2.2 Technical community The SyRS should also communicate the customerÕs requirements to the technical community. The technical community includes analysts, estimators, designers, quality assurance ofÞcers, certiÞers, developers, engi- neers, integrators, testers, maintainers, and manufacturers. For this audience the representation of the SyRS should be technically precise and presented in a formalism from which they can design, build, and test the required system. 4.4 Intended use The recommended uses of the SyRS, which vary as the development cycle progresses, are as follows: a) During systems design, requirements are allocated to subsystems, hardware, software, operations, and other major components of the system. b) The SyRS is utilized in constructing the resulting system. The SyRS is also used to write appropriate system veriÞcation plans. If the system contains hardware and software, then the hardware test plan and software test plan are also generated from the system requirements. c) During the implementation phase, test procedures will be deÞned from the SyRS. d) During the validation process, validation procedures based on the SyRS are used to provide the customer with a basis for acceptance of the system. If any changes to the SyRS baseline are to be made, they should be controlled through a formal change management process. This process should include appropriate negotiation among parties affected by the change and should trigger pertinent risk assessments (e.g., schedules or costs). 4.5 BeneÞts A properly written SyRS beneÞts all subsequent phases of the life cycle in several different ways. The SyRS documents the complete set of system capabilities and provides the following beneÞts: a) Assurance to the customer that the technical community understands the customerÕs needs and is responsive to them; b) An early opportunity for bidirectional feedback between the customer and the technical community; c) A method for the customer and the technical community to identify problems and misunderstand- ings while relatively inexpensive to correct; d) A basis for system qualiÞcation to establish that the system meets the customerÕs needs; IEEE DEVELOPING SYSTEM REQUIREMENTS SPECIFICATIONS Std 1233, 1998 Edition Copyright © 1998 IEEE. All rights reserved. 7 e) Protection for the technical community, providing a baseline for system capabilities and a basis of determining when the construction of the system is complete; f) Support for the developerÕs program planning, design, and development efforts; g) Aid in assessing the effects of the inevitable requirement changes; h) Increased protection against customer and technical community misunderstandings as development progresses. 4.6 Dynamics of system requirements Requirements are rarely static. Although it is desirable to freeze a set of requirements permanently, it is rarely possible. Requirements that are likely to evolve should be identiÞed and communicated to both customers and the technical community. A core subset of requirements may be frozen early. The impact of proposed new requirements must be evaluated to ensure that the initial intent of the requirements baseline is maintained or that changes to the intent are understood and accepted by the customer. 5. SyRS development process overview This clause provides an overview of the steps in the SyRS development process. The system requirements development process, in general, interfaces with three external agentsÑthe customer, the environment, and the technical community. Each of the external agents is described in the text below. Figure 1 shows the inter- actions among the various agents necessary to develop an SyRS. 5.1 Customer Customers are the keystone element of the SyRS context. They are prime system drivers providing their objectives, needs, or problems to the SyRS process. The exchange between customers and SyRS developers is discussed below. 5.1.1 Raw requirements Prior to the SyRS process the customer has an idea for a system, for a process improvement, or for a problem to be solved. At this point, any initial concept for a system may be imprecise and unstructured. Requirements will often be intermingled with ideas and suggestions for potential designs. These raw requirements are often expressed in initiating documents similar to the following: CUSTOMER DEVELOP SYSTEMS REQUIREMENTS COLLECTION RAW REQUIREMENT CUSTOMER FEEDBACK CUSTOMER REPRESENTATION CONSTRAINT/INFLUENCE ENVIRONMENT TECHNICAL COMMUNITY TECHNICAL REPRESENTATION TECHNICAL FEEDBACK Figure 1ÑContext for developing an SyRS IEEE Std 1233, 1998 Edition IEEE GUIDE FOR 8 Copyright © 1998 IEEE. All rights reserved. a) Concept of operations. This type of document focuses on the goals, objectives, and general desired capabilities of the potential system without indicating how the system will be implemented to actu- ally achieve the goals. b) System concept. This type of document includes concept of operations information, but will also include a preliminary interface design for the system and other explicit requirements. c) Marketing speciÞcation. This type of document includes a features list (often in bullet format) for a new system or systems and will identify the scope of the features and their priority (which are mandatory or highly desirable) to provide an edge in the marketplace. It also includes a context or boundary deÞning how the new system must interact with existing systems. A cost/beneÞt analysis and required delivery schedule may be provided. d) Request for proposal (RFP). In some instances an RFP will be prepared. This may include one or more of the above initiating documents. Its purpose will be to solicit bids for consideration from several sources to construct a system, or may simply require assistance to generate system initiating documents. e) External system interfaces. The deÞnition of all interfaces external to the system, literally or by reference, is one of the most important (yet most often overlooked) activities to be accomplished prior to the generation of the SyRS. An approved deÞnition of the systemÕs external universe reason- ably bounds or restricts what the system is required to do internally. All known elements of each separately deÞned interface should be described. This information may be included in the SyRS if it is not too voluminous. However, in most cases it is better to have a System External Interface Control Document (ICD). There are many types of possible interfaces external to the system and a single system may have several interfaces of differing types. The following list provides some examples: Ñ Operational; Ñ Computer to computer; Ñ Electrical; Ñ Data links and protocols; Ñ Telecommunications lines; Ñ Device to system, system to device; Ñ Computer to system, system to computer; Ñ Environmental sense and control interfaces. 5.1.2 Customer representation Feedback to the customer includes SyRS representations and technical interchange or communications clar- ifying and/or conÞrming requirements. 5.1.3 Customer feedback Customer feedback includes information updating the customerÕs objectives, problems, or needs; modifying requirements concerning technical interchange communications; and identifying new requirements. 5.2 Environment In addition to the analyst and the customer, the environment can implicitly or explicitly inßuence or place a constraint on the system requirements. The analyst should be aware of these inßuences on system capabili- ties. In cases where systems are sensitive to environmental inßuences, the customers and analyst will specify environmental inßuences that affect system requirements. Environmental inßuences can be classiÞed into overlapping categories, as follows: a) Political; b) Market; IEEE DEVELOPING SYSTEM REQUIREMENTS SPECIFICATIONS Std 1233, 1998 Edition Copyright © 1998 IEEE. All rights reserved. 9 c) Standards and technical policies; d) Cultural; e) Organizational; f) Physical. These categories are described below. Although these descriptions represent factors that should be consid- ered, this list is not to be construed as exhaustive. 5.2.1 Political inßuence International, federal, state, and local governmental agencies have laws and regulations that inßuence system requirements. Some governmental agencies may have enforcement organizations that check for compliance with their laws and regulations. Examples of governmental laws are copyright, patent, and trademark laws. Examples of governmental regulations are zoning, environmental hazards, waste, recycling, system safety, and health. Political inßuence changes as a function of political boundaries. What affects system requirements in one environment may be completely different in another. Therefore, it is important to conduct research in the political environment where the system will be manufactured and/or used to ensure that the system conforms to all of the governmental laws and regulations. 5.2.2 Market inßuence There are three types of market conditions that inßuence the development of the systems speciÞcation. The Þrst matches the customerÕs needs to the systems by using marketing research or by developing markets to match technical research. Matching the customerÕs needs to systems affects the system requirements up front and becomes part of the customer requirements. The second market inßuence is the demand-fulÞlling inßuence. This inßuence is part of the environmental inputs as shown in Figure 1. The demand-fulÞlling inßuence must be considered because it affects system distribution and accessibility, which adds to the system requirements (e.g., the system should be lightweight to reduce shipping cost, or the system must be of small size to Þt into vending machines). Distribution and accessibility requirements must be identiÞed during system development and before the system is manufac- tured and/or integrated to allow these requirements to be incorporated into the system. Without easy access to the system, system success will be limited. Therefore, it is important to consider the market segments for which the system is targeted and to consider how marketing information can be used to derive system requirements. The third market inßuence is competition. Knowing a competitorÕs systems will help deÞne requirements. To stay competitive, the following should be considered: a) Functionality; b) Price; c) Reliability; d) Durability; e) Performance; f) Maintainability; g) System safety and security. Analyzing the competitive market is a continuous process and will affect requirements for both new and existing systems. Systems can evolve into completely new systems that may have little resemblance to the customerÕs original concepts. IEEE Std 1233, 1998 Edition IEEE GUIDE FOR 10 Copyright © 1998 IEEE. All rights reserved. 5.2.3 Standards and technical policies inßuence System requirements are inßuenced directly by customers who have to conform to standards and technical policies issued by government or industries. Technical policies and associated standards and guidelines help ensure the following: a) System consistency; b) System safety; c) System reliability and maintainability. System consistency standards and guidelines prescribe speciÞc requirements by providing details about how a particular system should be implemented. Industrial safety standards are generally imposed to help prevent safety hazards and potential legal prob- lems. Safety compliance requirements should be clearly identiÞed in a system requirements document [i.e., safety requirements for the toy manufacturing industry, UL certiÞcations, or National Electrical Code¨ requirements]. The customer and technical community may require that the system should pass certain reliability criteria as prescribed in technical standards. Reliability and maintainability requirements should be identiÞed in the SyRS. These requirements can come in many forms. For instance, they may be directly system oriented and may require speciÞcations of maximum outage time and minimum mean time between failure, or minimum mean time to repair. 5.2.4 Cultural inßuence Culture is the integrated human behavior patterns that are transmitted from generation to generation. It is a learned experience that originates from religious beliefs, country of origin, ethnic group, socioeconomic level, language, media, place of employment, and immediate family. To understand the culture of a region or market segment, the values and beliefs of the people must be known. Cultural inßuence should be consid- ered when developing a system because it will affect the system requirements. 5.2.5 Organizational inßuence System requirements are inßuenced by the organization in which the requirements are developed. Company organizational inßuence can take the form of marketing, internal politics, technical policies, and internal standards. The companyÕs inßuences on system requirements are similar to those of the other spheres of inßuence, plus it has its own unique set (i.e., every company has its own culture, purposes, values, and goals that can and will inßuence the system that it develops, manufactures, and/or delivers). 5.2.6 Physical inßuence Physical inßuence includes natural and man-made inßuences such as temperature, radiation, moisture, pres- sure, and chemicals. 5.3 Technical community The technical community, represented in Figure 1, is composed of those involved in the activities of system design, implementation, integration, test, manufacturing, deployment, operations, and maintenance. All elements of the technical community should be involved in the SyRS development process as early as possi- ble. Early inclusion of the technical community provides a mechanism for the SyRS developers to reduce the possibility that new requirements or changes to the original requirements may be discovered later in the system life cycle. IEEE DEVELOPING SYSTEM REQUIREMENTS SPECIFICATIONS Std 1233, 1998 Edition Copyright © 1998 IEEE. All rights reserved. 11 5.3.1 Technical representation Representations of the requirement collection, prepared for the technical community, may include technical interchange or communications that clarify and/or conÞrm requirements. 5.3.2 Technical feedback The technical community provides feedback during various activities that can cause modiÞcation, additions, and/or deletions to the requirement collection. The SyRS is reÞned as necessary to support subsequent life cycle phases of the system. For example, following the requirement phase, a system test plan is developed where individual requirements are allocated to speciÞc tests. This process can reveal requirements that are non-testable, resulting in modiÞcation of the SyRS to ensure testability. Other feedback from the technical community may provide customers with the most recent system features, upcoming technologies, and insight into advanced implementation methods. 6. Well-formed requirements This clause explains the properties of a well-formed requirement, provides an example of a well-formed requirement, and points out requirement pitfalls. 6.1 DeÞnition of a well-formed requirement As previously deÞned, a well-formed requirement is a statement of system functionality (a capability) that can be validated, that must be met or possessed by a system to solve a customer problem or to achieve a customer objective, and that is qualiÞed by measurable conditions and bounded by constraints. This deÞnition helps in the classiÞcation of general customer requirements. Requirements can be taken from customer needs and can be derived from technical analysis. The deÞnition provides a means for distinguish- ing between requirements as capabilities and the attributes of those requirements (conditions and constraints). Constraints may be functional or nonfunctional. An example of a nonfunctional constraint might be that the system is to be painted a particular shade of blue solely for nonrequired decorative purposes. This guide recommends that system implementation process requirements, such as mandating a particular design methodology, not be included in an SyRS. Process requirements should be captured in other system controlling technical documentation such as quality plans, contracts, or statements of work. 6.1.1 Capabilities Capabilities are the fundamental requirements of the system and represent the features or functions of the system needed or desired by the customer. A capability should usually be stated in such a way that it describes what the system should do. The capability should also be stated in a manner that is solution inde- pendent. This will permit consideration of different ways of meeting the need or of providing the feature or function. For example, capabilities of a high-speed rail system between Los Angeles and New York could include the ability to start, accelerate, cruise, decelerate, stop, load passengers, and unload passengers. However, the brand of the computer operating system is not considered to be a capability of the high-speed rail system. 6.1.2 Conditions Conditions are measurable qualitative or quantitative attributes and characteristics that are stipulated for a capability. They further qualify a capability that is needed, and provide attributes that permit a capability to IEEE Std 1233, 1998 Edition IEEE GUIDE FOR 12 Copyright © 1998 IEEE. All rights reserved. be formulated and stated in a manner that can be validated and veriÞed. For example, in the high-speed rail system mentioned above, a condition of the capability to cruise may be a cruise range of 0 km/hr to 300 km/hr or an optimal cruise rate of 200 km/hr. It makes sense to include conditions (measurable attributes) only if they apply to something to be measured, such as a capability. For example, it is meaningless to have a system requirement that states 0Ð200 km/hr in the abstract. This range can qualify a cruising speed for a high-speed rail link but not the speed at which an elevator should lift passengers. Conditions may limit the options open to a designer. It is important to identify conditions as attributes of capabilities, not as primary capabilities, to ensure that the requirements clearly deÞne the need without imposing unnecessary bounds on the solution space. 6.1.3 Constraints Constraints are requirements that are imposed on the solution by circumstance, force, or compulsion. Constraints limit absolutely the options open to a designer of a solution by imposing immovable boundaries and limits. For example, the high-speed rail link mentioned above will be constrained by the need to get people to their destination alive (a safety constraint could be mandatory seatbelts) and could be constrained by technology (the customer may require that all train control software be written in Ada). A list of constraints can include interfaces to already existing systems (e.g., format, protocol, or content) where the interface cannot be changed, physical size limitations (e.g., a controller must Þt within a limited space in an airplane wing), laws of nature, laws of a particular country, available time or budget, priority (e.g., mandatory or optional), or a pre-existing technology platform. Constraints may apply across all requirements or be speciÞed in a relationship to a speciÞc capability or set of capabilities. Constraints may be identiÞed as stand-alone requirements (i.e., not bounding any speciÞc capability), or as constraints upon individual capabilities. Many constraints, such as the choice of technology (e.g., the type of operating system), will apply to the entire set of capabilities. Other constraints will apply to only a single or a few capabilities. For example, there will be safety constraints imposed on acceleration for a high-speed rail system that will not apply to the passenger loading functions. 6.1.4 Example The purpose of this example is to state a well-formed requirement and its associated conditional and capabil- ity requirements, as follows: Move people from New York to California at a maximum speed of 5300 km/hr. Capability: Move people between Los Angeles and New York Condition: Cruising speed of 2500 km/hr Constraint: Maximum speed of 5300 km/hr 6.2 Properties of a requirement Each requirement should possess the following properties: a) Abstract. Each requirement should be implementation independent. b) Unambiguous. Each requirement should be stated in such a way so that it can be interpreted in only one way. IEEE DEVELOPING SYSTEM REQUIREMENTS SPECIFICATIONS Std 1233, 1998 Edition Copyright © 1998 IEEE. All rights reserved. 13 c) Traceable. For each requirement it should be feasible to determine a relationship between speciÞc documented customer statement(s) of need and the speciÞc statements in the deÞnition of the system given in the SyRS as evidence of the source of a requirement. d) Validatable. Each requirement should have the means to prove that the system satisÞes the require- ments. 6.3 Categorization To support the analysis of requirements, the requirements should be categorized by their identiÞcation, priority, criticality, feasibility, risk, source, and type. Each of these categories is described in more detail below. a) IdentiÞcation. Each requirement should be uniquely identiÞed (i.e., number, name tag, mnemonic, buttons, hypertext). IdentiÞcation can reßect linkages and relationships, if needed, or they can be separate from identiÞcation. b) Priority. The customer should identify the priority of each requirement. This may be established through a consensus process among potential customers. As appropriate, a scale such as 1:10 or a simple scheme such as High, Medium, Low, Out, could be used for identifying the priority of each requirement. c) Criticality. The analyst, working with the customer, should deÞne the criticality of each requirement. Some requirements could have a low priority from the userÕs perspective, but nevertheless be essen- tial for the success of the system. For example, a requirement to measure external ambient tempera- ture could be essential to provide support to other requirements such as the maintenance of internal cabin temperature. This relationship should be identiÞed so that if the primary requirement is removed by the customer, the supporting requirement can also be eliminated. d) Feasibility. The customer and analyst working together should identify the feasibility of including each particular requirement in the system, and classify each requirement by types of feasibility appropriate to the system domain. Feasibility could be based upon an understanding of such things as the current state of technology (e.g., commercially available components vs. original research), the customerÕs environment (e.g., readiness or capability to accept change), and the risk or cost asso- ciated with a particular requirement. e) Risk. Risk analysis techniques can be used to determine a grading for system requirements. In terms of their consequences or degree of risk avoidance, major risks are related to potential Þnancial loss, environmental impact, safety and health issues, and national standards or laws. f) Source. Each requirement should be further classiÞed by a label that indicates the originator. There may be multiple sources that can all be considered creators of the requirement. It is useful to identify the creator(s) of each requirement so that if requirements are unclear, conßict, or need to be modiÞed or deleted, it will be possible to identify the individual(s) or organization(s) to be consulted. g) Type. Requirements can also be categorized by one or more of the following types: ÑInput (e.g., receive EDI data); ÑOutput (e.g., export a particular format); ÑReliability (e.g., mean time to failure); ÑAvailability (e.g., expected hours of operation); ÑMaintainability (e.g., ease with which components can be replaced); ÑPerformance (e.g., response time); ÑAccessibility (e.g., different navigation paths for novice and experienced users); ÑEnvironmental conditions (e.g., dust levels that must be tolerated); ÑErgonomic (e.g., use of particular colors to reduce eye strain); ÑSafety (e.g., below speciÞed limits for electrical magnetic radiation); ÑSecurity (e.g., limits to physical, functional, or data access, by authorized or unauthorized users); IEEE Std 1233, 1998 Edition IEEE GUIDE FOR 14 Copyright © 1998 IEEE. All rights reserved. ÑFacility requirements (e.g., use of domestic electrical current); ÑTransportability (e.g., weight limits for portability); ÑTraining (e.g., includes tutorials or computer-based training); ÑDocumentation (e.g., on-line help facility); ÑExternal interfaces (e.g., support for industry standard communication mode/format); ÑTesting (e.g., support for remote diagnostics); ÑQuality provisions (e.g., minimum required calibration intervals); ÑPolicy and regulatory (e.g., environmental protection agency policies); ÑCompatibility to existing systems (e.g., uses analog telephone system as default mode); ÑStandards and technical policies (e.g., products to conform to ASME codes); ÑConversion (e.g., will accept data produced by older versions of system); ÑGrowth capacity (e.g., will support an additional number of users); ÑInstallation (e.g., ability to put a new system into service). 6.4 Pitfalls Some pitfalls to avoid when building well-formed requirements are as follows: a) Design and implementation. There is a tendency on the part of analysts and customers who are deÞning requirements to include design and implementation decisions along with the requirements statements. Such information may still be important. In this case, the information should be docu- mented and communicated in some other form of documentation in order to aid in design and imple- mentation. b) OverspeciÞcation. 1) Requirements that express an exact commercial system set or a system that can be bought rather than made (these are not an expression of what the system should do); 2) Requirements that state tolerances for items deep within the conceptual system (frequently stated as error requirements at very low levels); 3) Requirements that implement solutions (requirements state a need). c) Overconstrained. Requirements with unnecessary constraints. (For example, if a system must be able to run on rechargeable batteries, a derived requirement might be that the time to recharge should be less than 3 h. If this time is too restrictive and a 12 h recharge time is sufÞcient, potential solu- tions are eliminated.) d) Unbounded. 1) Requirements making relative statements. (These requirements cannot be veriÞed and may only need to be restated. For example, the requirement to Òminimize noiseÓ may be restated as Ònoise levels should not exceed...Ó) 2) Requirements that are open-ended (frequently stated as Òincluding, but not limited to...Ó or lists ending in Òetc.Ó). 3) Requirements making subjective or vague statements (frequently contain terms such as Òuser friendly,Ó Òquick response time,Ó or Òcost effectiveÓ). e) Assumptions. 1) Requirements based on undocumented assumptions. (The assumption should be documented as well as the requirement.) 2) Requirements based on the assumption that a particular standard or system undergoing devel- opment will reach completion. (The assumption and an alternative requirement should be docu- mented.) IEEE DEVELOPING SYSTEM REQUIREMENTS SPECIFICATIONS Std 1233, 1998 Edition Copyright © 1998 IEEE. All rights reserved. 15 7. SyRS development System requirements speciÞcation development, as shown in Figure 1, is an iterative process. The four subprocesses are shown in Figure 2. These subprocesses are as follows: a) Identify requirements from the customer, the environment, and the experience of the technical community; b) Build well-formed requirements; c) Organize the requirements into an SyRS; d) Present the SyRS in various representations for different audiences. The purpose of decomposing the system requirements speciÞcation development process into subprocesses is to aid in the full and accurate development of the SyRS. The subprocesses below are presented as occur- ring sequentially. However, there will often be a degree of subprocess overlap or iteration. The iterative application of this process results in the ongoing modiÞcation of the SyRS. ModiÞcations are usually applied against the SyRS baseline, and managed under change control procedures. See IEEE Std 1220-1998 for change control procedures. 7.1 Identify requirements Working with customers, analysts Þlter the various inputs identiÞed in Figure 2 and extract a set of require- ments, establish necessary derived requirements, and create requirements. Requirements may be extracted from initiating documents and through analytical exercises conducted with the customer. The goal of this iterative process is to solicit all system requirements, ensure that each requirement is stated once, and ensure that none are missed. There are a variety of approaches that can be followed in the identiÞcation of customer requirements. In practice, each organization will have its own approach to identifying requirements and initiating the process CUSTOMER ENVIRONMENT CUSTOMER TECHNICAL COMMUNITY RAW REQUIREMENT CONSTRAINT/ INFLUENCE CUSTOMER FEEDBACK TECHNICAL FEEDBACK IDENTIFY REQUIREMENTS REQUIREMENTS REQUIREMENTS COLLECTION BUILD WELL-FORMED REQUIREMENTS WELL-FORMED REQUIREMENTS DATA ORGANIZE REQUIREMENTS PRESENT SyRS ORGANIZED REQUIREMENTS CUSTOMER TECHNICAL COMMUNITY Figure 2ÑSyRS development process IEEE Std 1233, 1998 Edition IEEE GUIDE FOR 16 Copyright © 1998 IEEE. All rights reserved. of creating a system solution. In some organizations, customers will undertake the entire process in-house. In this case the identiÞcation and speciÞcation of requirements will be driven by the customer. In other orga- nizations, customers will identify a preliminary set of requirements and will request assistance from an ana- lyst within their organization or through a contract with an external consultant or systems integrator. The analyst, whether from within the organization or external, will work with the customer to identify and structure the requirements. In some organizations the analyst will work directly with the customer. In other organizations, the analyst will not be given direct access to the customer and will have to work through one or more layers of intermediaries (technical, legal, administrative) who represent the customer. Because of the dynamics involved in identifying requirements, it is important that the customer and analyst agree on the process. The analyst needs to prepare a plan to guide the process, deÞne representations of the SyRS that will be produced for different audiences, and identify the tools and techniques that will be used. The process should move forward toward the goal of developing the SyRS database and provide customers with a system that will meet their needs. The analyst should ensure that the identiÞcation of requirements uses all appropriate techniques within this process. A requirements management process should be used to ensure the following: a) The process is goal-directed and aimed at the production of a set of requirements. b) The system boundaries are deÞned. c) All requirements are solicited, fairly evaluated, and documented. d) Requirements are speciÞed as capabilities, and qualifying conditions and bounding constraints are identiÞed distinctly from capabilities. e) Requirements are validated, or purged, if invalid, from the requirements set. f) Consideration is given to consistency when many individuals (ÒauthorsÓ) may be contributing to the development of the requirements set. g) The developing requirements set is understood, at an appropriate level of detail, by all individuals participating in the process. 7.1.1 Techniques for identifying requirements Requirements begin as ideas or concepts that may originate from a response to a perceived threat to security or market share, from an imposition of legislation or regulation, from a desire to create a new or better sys- tem or process, from the need to replace an existing system, or from some other actual or perceived need. Although the ideas or concepts may originate with one individual, a set of requirements usually is best obtained from the interaction of a group where ideas are shared and shaped. There are a number of techniques for identifying requirements, including the following: a) Structured workshops; b) Brainstorming or problem-solving sessions; c) Interviews; d) Surveys/questionnaires; e) Observation of work patterns (e.g., time and motion studies); f) Observation of the systemÕs organizational and political environment (e.g., sociogram); g) Technical documentation review; h) Market analysis; i) Competitive system assessment; j) Reverse engineering; k) Simulations; l) Prototyping; m) Benchmarking processes and systems. IEEE DEVELOPING SYSTEM REQUIREMENTS SPECIFICATIONS Std 1233, 1998 Edition Copyright © 1998 IEEE. All rights reserved. 17 7.1.2 Interaction between customers and analysts In a situation where an analyst has been hired to work with a customer, it will be necessary to establish an effective process of interaction between the two parties. To make this interaction effective, each party needs to understand that they have a role in educating the other party and that they should work together to jointly deÞne the requirements. 7.1.2.1 Mutual education Education must be a two-way process. First, the analysts need to learn about the customerÕs environment, current systems (if any), and requirements. Time and effort need to be allocated on both sides to accommo- date this education process. Second, customers may also need education. They may need edu

less