ATIS 0800052-2011 IIF Requirements Guidelines.pdf

1、 ATIS-0800052 IIF REQUIREMENTS GUIDELINES ATIS is the leading technical planning and standards development organization committed to the rapid development of global, market-driven standards for the information, entertainment and communications industry. More than 200 companies actively formulate sta

2、ndards in ATIS Committees, covering issues including: IPTV, Cloud Services, Energy Efficiency, IP-Based and Wireless Technologies, Quality of Service, Billing and Operational Support, Emergency Services, Architectural Platforms and Emerging Networks. In addition, numerous Incubators, Focus and Explo

3、ratory Groups address evolving industry priorities including Smart Grid, Machine-to-Machine, Connected Vehicle, IP Downloadable Security, Policy Management and Network Optimization. ATIS is the North American Organizational Partner for the 3rd Generation Partnership Project (3GPP), a member and majo

4、r U.S. contributor to the International Telecommunication Union (ITU) Radio and Telecommunications Sectors, and a member of the Inter-American Telecommunication Commission (CITEL). ATIS is accredited by the American National Standards Institute (ANSI). For more information, please visit . Notice of

5、Disclaimer for traceability it is always listed in the document but marked as deprecated. The requirement reference is always before any sentence with requirement language. The requirement reference is always in Bold type. 4.5.1 Requirement Reference Figure 1 shows the requirement reference structur

6、e. A period “.” is used to delimit the parameters. Figure 1: Requirement Numbering 4.5.1.1 Requirement Number Header The text “REQ” is used to indicate the requirement reference. REQ. Deprecated.KKKOptional deprecated notice and version/date when deprecatedDocument Version or Date if not initial rel

7、easeEnumerated Requirement NumberATIS Published Specification Number or WT number ATIS-0800052 6 4.5.1.2 Document Number The document number for published specifications is the ATIS document number. For working texts, it is the WT number (e.g., WT-104). 4.5.1.3 Version Number For initial release of

8、non-ANSI ATIS documents, this field is not included. For other than initial release of non-ANSI ATIS document, this field will be one of the following: Year of release for ANSI ATIS documents. Version of released ANSI documents (e.g., v002). Revision of working text (e.g., R33). 4.5.1.4 Requirements

9、 Number An enumerated number is assigned to each requirement. Once a document is released, these numbers are fixed to that requirement. For working text, the editor may choose to fix these numbers or modify them. It should be noted that Microsoft Word allows for simple enumeration using the SEQ fiel

10、d code. These can be converted to text by using the shortcut key. 4.5.1.5 Requirements Deprecation Notice If a requirement has been deprecated, only then is the deprecation notice added. This notice is enclosed within brackets, and contains the word “Deprecated” followed by a period and the version

11、of the document from which it was deprecated. 4.5.2 Released Documents The proposed requirement reference includes the version number of the released document that the requirement first appears. For example: REQ.0000000.1 The example device shall implement the example function. (Requirement originat

12、es in initial release of document.) REQ.0000000.v002.42 The example device shall implement a new example function. (Requirement originates in V002 of document.) 4.5.3 Working Texts If a requirement is added while the document is in working text, then the working text version is included, and will be

13、 modified when the ATIS document is released. For example: REQ.WT00.R1.43 The example device shall implement another new example function. (Requirement originates in WT00, R1). Contributions can contain the requirement number; however, it may be modified at the editors discretion, for example, if th

14、ere are conflicting requirement numbers between different contributions. If a requirement is removed from a working text that was not in a released document, then the requirement is deleted (e.g., not deprecated). 4.5.4 Deprecated Requirements Once a document has been released, requirements are neve

15、r deleted. Requirements that are no longer valid are deprecated and so noted. For example: ATIS-0800052 7 REQ.0000000.1Deprecated.v003 The example device shall implement the example function. This requirement has been deprecated. (Requirement originates in initial release of document, is deprecated

16、in v003 of released document.) 4.5.5 Normatively Edited Requirements If there is a desire to normatively edit a requirement, then the original requirement is deprecated and a new requirement is added. Explanatory text is added after both requirements. For example: REQ.0000000.1Deprecated.v003 The ex

17、ample device should implement the example function A. This requirement has been deprecated and replaced with requirement REQ.0000000.v003.100. (Requirement originates in initial release of document, is deprecated in v003 of released document and replaced with new requirement.) REQ.0000000.v003.100 T

18、he example device shall implement the example function A. This is an updated version of REQ.0000000.1. (New normatively edited requirement.) 4.5.6 Non-Normative Edited Requirements If there is a desire to editorially edit a requirement, for example due to spelling, then no change is made to the requ

19、irement reference. New text is included within brackets and removed text is indicated with strikethrough within brackets. If necessary, informative text of the change follows the requirement. If a single letter is modified, it is suggested that the entire word be updated for clarity. For example: RE

20、Q.0000000.1 The example device shall implamentimplement the example function. (Requirement originated in initial release of document, editorially changed in later release to fix misspelled word.) 4.6 Requirements Language 4.6.1 Types of Requirements There are four types of requirements: Mandatory Re

21、commended Optional Conditional-Mandatory Each type has different requirement language formats. 4.6.1.1 Mandatory A Mandatory Requirement is one that must be implemented in order to meet correct operation, certification, regulatory, and interoperability. The Mandatory Requirements are written so that

22、, within a single sentence, the word “shall” is present once in italics. An example is: REQ.0000000.24 The example device shall implement the DHCP protocols for IPV4 and IPV6. Mandatory requirements that state a conditional operation and the required function will use the word “When”. 4.6.1.2 Recomm

23、ended A Recommended Requirement is one that is recommended to be implemented but does not have to be implemented. Usually, this is because of planned future functions, perceived better operation, or some ATIS-0800052 8 other reason. Recommended Requirements are written so that, within a single sente

24、nce, the word “should” is present once in italics. An example is: REQ.0000000.25 The example device should implement the SNMP protocol. 4.6.1.3 Optional An Optional Requirement is one that is completely optional to be implemented. Test procedures are not required to test optional requirements but th

25、ey can. This is usually to allow alternative methods be utilized that would not interfere with the specific function or operation. Optional Requirements are written so that, within a single sentence, the word “may” is present once in italics. An example is: REQ.0000000.26 The example device may impl

26、ement proprietary diagnostic tools. 4.6.1.4 Conditional-Mandatory A Conditional-Mandatory Requirement is one that is optional to implement, but if it is implemented must be done as a Mandatory Requirement. The Conditional-Mandatory Requirements are written so that, within a single sentence, there is

27、 an initial conditional statement using “If” and the word “shall” is present once in italics. 4.6.1.5 Not The word “not” when following a requirement language word is italicized. 4.6.1.6 Logic Words The logic words “AND” and “IF” are capitalized when used to define logic conditions. This helps clari

28、fy the intent. These are not italicized. 4.6.2 Avoiding Confusion Requirements need to avoid confusion and be explicit in their description. Below are some guidelines to follow in writing requirements: Avoid pronouns unless the thing that they reference can be explicitly understood. o Bad “It shall

29、have printed its model number somewhere on the external chassis.” o Better “The example device shall have its model number printed somewhere on the external chassis.” Avoid relative references; make them absolute. o Bad “The example device shall implement the DHCP options in the following table.” o

30、Better “The example device shall implement the DHCP options defined in Table 9.” Do not nest requirements i.e., have requirements within a bulleted list or table. o Bad “The example device shall support the following: The example device shall support DHCP option 21. The example device may support DH

31、CP option 22.” o Better “The example device shall follow Table 42 for DHCP options.” Table 42 DHCP Option Implementation 21 Mandatory 22 Optional23 Mandatory Avoid bulleted lists; use a table. ATIS-0800052 9 Include references where possible. o “The example device shall implement the DHCP protocol p

32、er RFC 2131 42.” Explicitly state the destination. See section 4.8 for definition of destinations. o Bad “The Example Element metadata shall be included.” o Better “The Example schema shall include the Example Element.” o Bad “The device shall have the model number printed on its exterior chassis.”

33、o Better “The Example device shall have the model number printed on its exterior chassis.” 4.6.3 External References External references may need to be updated. This should always be considered a normative editing of a requirement. Additionally, it is recommended that an external reference be explic

34、itly stated, not just the cross-reference identifier. For example: REQ.0000000.1 The example device shall implement the example protocol defined in RFC 42 3. (Reference does not include version number.) REQ.0000000.2 The example device shall implement the example protocol defined in ATIS-0800000.v00

35、2 4. (Reference includes a version number, if the reference were to be changed to ATIS-0800000.v003, then this requirement would be deprecated and a new requirement generated.) 4.7 Requirement Destinations Requirements within a specification can be written to various destinations. A single requireme

36、nt has only one destination. Some destination examples are: Component Device System Another specification Data file Software Schema Documentation Protocol Operation Graphical User Interface Graphics Packaging Media Many others A good requirement has the specific destination explicitly stated prior t

37、o the requirements key word (e.g., shall, should, or may). 5 Requirement Guidelines (Normative) 5.1 Requirements Language REQ.0800052.1 The explicit style of writing requirements shall be used (section 4.3.2). ATIS-0800052 10 REQ.0800052.2 A requirements table should be generated and included in the

38、 specification (section 4.3.2). REQ.0800052.3 A mandatory requirement shall be a single sentence which contains a single instance of the word “shall” in italics (section 4.6.1.1). REQ.0800052.4 A recommended requirement shall be a single sentence which contains a single instance of the word “should”

39、 in italics (section 4.6.1.2). REQ.0800052.5 An optional requirement shall be a single sentence which contains a single instance of the word “may” in italics (section 4.6.1.3). REQ.0800052.6 A conditional-mandatory requirement shall be a single sentence beginning with conditional language word “if”

40、AND contains a single instance of the word “shall” in italics (section 4.6.1.4). REQ.0800052.7 When a conditional-mandatory requirement has multiple logical conditions, then the requirement should have the words “AND” and “OR” capitalized. This helps understand the logic (section 4.6.1.6). REQ.08000

41、52.8 A negative requirement should capitalize the word “NOT” (section 4.6.1.5). REQ.0800052.9 When a mandatory, recommended, or optional requirement has an operational condition, then the requirement should have the word “when” as the first word of the sentence. This should be prior to the destinati

42、on declaration (section 4.6.1.1). REQ.0800052.10 When a mandatory, recommended, or optional requirement has multiple operation conditions, then the requirement should have the words “AND” and “OR” capitalized. This helps understand the logic (section 4.6.1.6). REQ.0800052.11 When writing a requireme

43、nt, pronouns with external references should not be used (section 4.6.2). REQ.0800052.12 When writing a requirement, references outside of the requirement should be absolute and not relative (section 4.6.2). REQ.0800052.13 Requirements should not be nested within referenced bullet lists or tables (s

44、ection 4.6.2). REQ.0800052.14 Requirements that reference multiple configurations should reference these configurations using a table (section 4.6.2). REQ.0800052.15 Requirements that reference multiple configuration should not use a bulleted list (section 4.6.2). REQ.0800052.16 Requirements that re

45、ference external references should explicitly name the reference and include the document cross-reference (section 4.7.2). REQ.0800052.17 Requirements should explicitly state the destination of the requirement (section 4.7.2). 5.2 Requirements References REQ.0800052.18 Every requirement sentence sha

46、ll have a requirement reference before the sentence. REQ.0800052.19 A requirement reference shall have a header of “REQ” (section 4.5.1.1). REQ.0800052.20 A requirement reference shall have the document number following the header. This follows REQ.0800052.19 (section 4.5.1.2). ATIS-0800052 11 REQ.0

47、800052.21 When the document is not an initial ATIS non-ANSI released document, then the requirement reference shall have the document version number or date. Initial ATIS non-ANSI released documents do not have to have the version field populated. This follows REQ.0800052.20 (section 4.5.1.3). REQ.0

48、800052.22 A requirement reference shall have a unique number following the version number or document number, whichever is appropriate per REQ.0800052.21 (section 4.5.1.4). REQ.0800052.23 When a requirement is deprecated, then the requirement reference shall have “Deprecated.YYYY” following the requ

49、irement reference number called out in REQ.0800052.22 (section 4.5.1.5). 5.3 Requirements Version Management REQ.0800052.24 When a document goes from Working Text to released document, the reference requirement numbers shall become fixed. The intent of this is so that the requirement reference number will forever be associated with that requirement (section 4.5.3). REQ.0800052.25 If a requirement is no longer valid in subsequent document releases, then it shall be