IEEE Guide for Developing System Requirements Speci cations

Ieee Guide For Developing System Requirements Speci Cations-PDF Download

  • Date:06 Apr 2020
  • Views:17
  • Downloads:0
  • Pages:36
  • Size:342.74 KB

Share Pdf : Ieee Guide For Developing System Requirements Speci Cations

Download and Preview : Ieee Guide For Developing System Requirements Speci Cations


Report CopyRight/DMCA Form For : Ieee Guide For Developing System Requirements Speci Cations


Description:

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

Transcription:

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 five years for revision or reaffirmation When a document is more. than five years old and has not been reaffirmed it is reasonable to conclude that its contents. although still of some value do not wholly reflect 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 affiliation 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 specific 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, 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. 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. Introduction, This introduction is not a part of IEEE Std 1233 1998 Edition IEEE Guide for Developing System Requirements Spec. ifications, The purpose of this guide is to provide guidance for capturing system requirements This guide serves the.
analyst by providing a clear definition for identifying well formed requirements and ways of organizing. 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 Software life cycle processes. 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. Louis E Miller Chair William N Sabor Secretary,Bakul Banerjee P Michael Guba Jim Longbucco. David Byrch James R Hughes Donald F Parsons,Kim A Cady Joe Iaquinto Eric Peterson. Larry Diehr Marybeth A Jupina John Sheckler,Charles A Droz Thomas M Kurihara Jess Thompson. Larry C Forrest Richard C Lee Eva D Williams,Other contributors included.
Geoff Cozens Kristin Dittmann Virginia Nuckolls,Paul Davis Christof Ebert Anne O Neill. Don McCash,The following persons balloted IEEE Std 1233 1996. H Ronald Berlack Eitan Froumine J Dennis Lawrence,Mark Bilger Yair Gershkovitch Ben Livson. William J Boll Adel N Ghannam Harold Mains,Fletcher Buckley Julio Gonzalez Sanz Roger Martin. Edward R Byrne Patrick J Griffin James W McClean,Fran ois Coallier David A Gustavson Sue McGrath.
Christopher Cooke John Harauz Louis E Miller,Geoff Cozens Derek J Hatley Dennis E Nickle. Alan M Davis William Hefley Indradeb P Pal, Robert E Dwyer Umesh P Hiriyannaiah Joseph A Palermo. Sherman Eagles Jody Howard Stephen R Schach,Leo G Egan Eiichi Kaneko Norman Schneidewind. Caroline L Evans Jerry Kickenson Wolf A Schnoege, Richard L Evans Janet Kintner Gregory D Schumacher. John W Fendrich Thomas M Kurihara Carl S Seddio,Peter Fillery Renee Lamb David M Siefert.
Larry Forrest John B Lane Richard S Sky,Eugene P Friedman Boniface Lau Alfred R Sorkowitz. Copyright 1998 IEEE All rights reserved iii,Robert N Sulgrove Leonard L Tripp Dolores Wallace. Tanehiro Tatsuta Tom Vaiskunas William M Walsh,Richard H Thayer Thomas E Vollman Paul R Work. George D Tice Ronald L Wade Janusz Zalewski, 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.
Edward Byrne Dennis Lawrence Terry Rout,Paul R Croll David Maibor Richard Schmidt. Perry DeWeese Ray Milovanovic Norman F Schneidewind. Robin Fralick James Moore David Schultz, Marilyn Ginsberg Finner Timothy Niesen Basil Sherlund. John Harauz Dennis Rilling Peter Voldner,Mark Henley Ronald Wade. The following persons balloted IEEE Std 1233a 1998. Syed Ali Julio Gonzalez Sanz Lawrence S Przybylski. Robert E Barry L M Gunther Kenneth R Ptack,Leo Beltracchi David A Gustafson Annette D Reilly. H Ronald Berlack Jon D Hagar Dennis Rilling,Richard E Biehl John Harauz Helmut Sandmayr.
Michael A Blackledge Herbert Hecht Stephen R Schach. Sandro Bologna William Hefley Norman Schneidewind,Kathleen L Briggs Mark Heinrich David J Schultz. M Scott Buck Debra Herrmann Lisa A Selmon,Michael Caldwell John W Horch Robert W Shillato. James E Cardow Jerry Huller David M Siefert,Enrico A Carrara Peter L Hung Carl A Singer. Antonio M Cicu George Jackelen Richard S Sky,Theo Clarke Frank V Jorgensen Alfred R Sorkowitz. Sylvain Clermont Vladan V Jovanovic Donald W Sova,Rosemary Coleman William S Junk Luca Spotorno.
Virgil Lee Cooper George X Kambic Julia Stesney,W W Geoff Cozens Ron S Kenett Fred J Strauss. Paul R Croll Judith S Kerner Toru Takeshita,Gregory T Daich Robert J Kierzyk Richard H Thayer. Geoffrey Darnton Thomas M Kurihara Booker Thomas,Taz Daughtrey John B Lane Patricia Trellue. Bostjan K Derganc J Dennis Lawrence Leonard L Tripp. Perry R DeWeese Randal Leavitt Theodore J Urbanowicz. Evelyn S Dow Fang Ching Lim Glenn D Venables,Carl Einar Dragstedt John Lord Udo Voges. Sherman Eagles Stan Magee David D Walden,Christof Ebert Harold Mains Dolores Wallace.
Leo Egan Robert A Martin William M Walsh,Richard E Fairley Tomoo Matsubara John W Walz. John W Fendrich Patrick D McCray Scott A Whitmire,Jay Forster Bret Michael P A Wolfgang. Kirby Fortenberry Alan Miller Paul R Work,Eva Freund James W Moore Natalie C Yopconka. Barry L Garner Pavol Navrat Janusz Zalewski, Marilyn Ginsberg Finner Alex Polack Geraldine Zimmerman. John Garth Glynn Peter T Poon Peter F Zoll,iv Copyright 1998 IEEE All rights reserved.
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,Satish K Aggarwal James H Gurney L Bruce McClung. Clyde R Camp Jim D Isaak Louis Fran ois Pau,James T Carlo Lowell G Johnson Ronald C Petersen. Gary R Engmann Robert Kennelly Gerald H Peterson,Harold E Epstein E G Al Kiener John B Posey. Jay Forster Joseph L Koepfinger Gary S Robinson, Thomas F Garrity Stephen R Lambert Hans E Weinrich.
Ruben D Garzon Jim Logothetis Donald W Zipse,Donald C Loughry. Member Emeritus,Valerie E Zelenty,IEEE Standards Project Editor. Copyright 1998 IEEE All rights reserved v,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. vi Copyright 1998 IEEE All rights reserved,IEEE Guide for Developing System. Requirements Speci cations,1 Overview, 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. 1IEEE publications are available from the Institute of Electrical and Electronics Engineers 445 Hoes Lane P O Box 1331 Piscataway. NJ 08855 1331 USA http www standards ieee org,Copyright 1998 IEEE All rights reserved 1. Std 1233 1998 Edition IEEE GUIDE FOR, 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. 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. 2ISO 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. 3MIL publications are available from Customer Service Defense Printing Service 700 Robbins Ave Bldg 4D Philadelphia PA. 19111 5094 USA, 4Information on references can be found in Clause 2. 2 Copyright 1998 IEEE All rights reserved, DEVELOPING SYSTEM REQUIREMENTS SPECIFICATIONS Std 1233 1998 Edition. 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. 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. Copyright 1998 IEEE All rights reserved 3,Std 1233 1998 Edition IEEE GUIDE FOR. 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. 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. 4 Copyright 1998 IEEE All rights reserved, DEVELOPING SYSTEM REQUIREMENTS SPECIFICATIONS Std 1233 1998 Edition. 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,Copyright 1998 IEEE All rights reserved 5. Std 1233 1998 Edition IEEE GUIDE FOR,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.
6 Copyright 1998 IEEE All rights reserved, DEVELOPING SYSTEM REQUIREMENTS SPECIFICATIONS Std 1233 1998 Edition. 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. RAW REQUIREMENT,DEVELOP TECHNICAL,SYSTEMS FEEDBACK. CUSTOMER REPRESENTATION REQUIREMENTS,COLLECTION,CONSTRAINT INFLUENCE.
ENVIRONMENT,TECHNICAL TECHNICAL,REPRESENTATION COMMUNITY. Figure 1 Context for developing 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. Copyright 1998 IEEE All rights reserved 7,Std 1233 1998 Edition IEEE GUIDE FOR. 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. 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,8 Copyright 1998 IEEE All rights reserved. DEVELOPING SYSTEM REQUIREMENTS SPECIFICATIONS Std 1233 1998 Edition. 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,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,Copyright 1998 IEEE All rights reserved 9.

Related Books