Docstoc

System Requirements Specification Inspection Checklist

Document Sample
System Requirements Specification Inspection Checklist Powered By Docstoc
					Donald Firesmith                    Document ID: SYSRS IC     Version:     0.2
System Requirements Specification Inspection Checklist        Date: 12/14/2000




 OPEN Process Framework
 System Requirements Specification
  Inspection Checklist (SYSRS IC)
                                   Version 1.0




Public                            2000 by Donald Firesmith                Page 1
Donald Firesmith                    Document ID: SYSRS IC                    Version:     0.2
System Requirements Specification Inspection Checklist                       Date: 12/14/2000


                                Revision History
   Date      Version                        Description                                Author

4/5/2000    0.1        Initial draft incorporating contents from use case model   Donald Firesmith
                       inspection checklist

6/30/2000   0.2        Incorporated new format                                    Donald Firesmith




Public                              2000 by Donald Firesmith                               Page 2
Donald Firesmith                    Document ID: SYSRS IC                                              Version:     0.2
System Requirements Specification Inspection Checklist                                                 Date: 12/14/2000


                                             Table of Contents
1      Checklist Guidelines ................................................................................................... 5
    1.1 Inception Phase Usage ............................................................................................ 5
    1.2 Elaboration Phase Usage......................................................................................... 5
    1.3 Construction Phase Usage....................................................................................... 5
2      Front Matter Defects ................................................................................................... 6
    2.1 Title Page ................................................................................................................ 6
    2.2 Revision History ..................................................................................................... 6
    2.3 Table of Contents .................................................................................................... 6
    2.4 Table of Figures ...................................................................................................... 6
3      Introduction Defects.................................................................................................... 7
    3.1 Specification Objectives ......................................................................................... 7
    3.2 Intended Audiences ................................................................................................. 7
    3.3 References ............................................................................................................... 7
    3.4 Specification Overview ........................................................................................... 7
4      System Overview Defects ........................................................................................... 8
    4.1 Definition Defects ................................................................................................... 8
    4.2 System Functions .................................................................................................... 8
    4.3 System Context ....................................................................................................... 8
       4.3.1 External Data Repositories ............................................................................. 8
       4.3.2 External Hardware .......................................................................................... 8
       4.3.3 External Roles ................................................................................................. 8
       4.3.4 External Software............................................................................................ 8
       4.3.5 External Systems ............................................................................................. 9
    4.4 Usage....................................................................................................................... 9
5      System Operational Requirements Defects .............................................................. 10
    5.1 General Defects ..................................................................................................... 10
    5.2 Context Defects ..................................................................................................... 10
    5.3 External Description Defects ................................................................................ 10
    5.4 Use Case Description Defects ............................................................................... 12
    5.5 Use Case Path Description Defects....................................................................... 12
6      System Quality Requirements Defects ..................................................................... 15
    6.1 Auditability Defects .............................................................................................. 15
    6.2 Configurability Defects ......................................................................................... 15
       6.2.1 Functional Variants Defects .......................................................................... 15
       6.2.2 Internationalization Defects .......................................................................... 15
       6.2.3 Personalization Defects ................................................................................. 15
    6.3 Correctness Defects .............................................................................................. 15
       6.3.1 Allowable Latent Defects ............................................................................. 16
       6.3.2 Accuracy Defects .......................................................................................... 16
       6.3.3 Precision Defects .......................................................................................... 16
       6.3.4 Timeliness Defects ........................................................................................ 16
    6.4 Efficiency Defects ................................................................................................. 16
    6.5 Extensibility Defects ............................................................................................. 16
    6.6 Interoperability Defects ........................................................................................ 16

Public                                             2000 by Donald Firesmith                                               Page 3
Donald Firesmith                    Document ID: SYSRS IC                                        Version:     0.2
System Requirements Specification Inspection Checklist                                           Date: 12/14/2000

 6.7 Maintainability Defects ......................................................................................... 17
 6.8 Operational Availability Defects .......................................................................... 17
 6.9 Performance Defects ............................................................................................. 17
    6.9.1 Capacity Defects ........................................................................................... 17
    6.9.2 Latency Defects ............................................................................................ 17
    6.9.3 Response Time Defects................................................................................. 17
    6.9.4 Throughput Defects ...................................................................................... 18
 6.10 Portability Defects ............................................................................................ 18
 6.11 Reliability Defects ............................................................................................ 18
 6.12 Reusability Defects ........................................................................................... 18
 6.13 Robustness Defects ........................................................................................... 18
 6.14 Safety Defects ................................................................................................... 19
 6.15 Scalability Defects ............................................................................................ 19
 6.16 Security Defects ................................................................................................ 19
    6.16.1 Identification Defects .................................................................................... 19
    6.16.2 Authentication Defects.................................................................................. 19
    6.16.3 Authorization Defects ................................................................................... 19
    6.16.4 Content Protection Defects ........................................................................... 20
    6.16.5 Privacy Defects ............................................................................................. 20
    6.16.6 Integrity Defects............................................................................................ 20
    6.16.7 Intrusion Detection Defects .......................................................................... 20
    6.16.8 Nonrepudiation Defects ................................................................................ 20
    6.16.9 System Maintenance Defects ........................................................................ 20
 6.17 Testability Defects ............................................................................................ 21
 6.18 Usability Defects ............................................................................................... 21
    6.18.1 Installation Defects ....................................................................................... 21
    6.18.2 Usage Defects ............................................................................................... 21
7 System Design Constraints Defects .......................................................................... 22
 7.1 Software Constraints ............................................................................................. 22
    7.1.1 Components .................................................................................................. 22
    7.1.2 Databases ...................................................................................................... 22
    7.1.3 High-Level Languages .................................................................................. 22
    7.1.4 Standards ....................................................................................................... 22
 7.2 Hardware Design Constraints ............................................................................... 22




Public                                          2000 by Donald Firesmith                                           Page 4
Donald Firesmith                    Document ID: SYSRS IC            Version:     0.2
System Requirements Specification Inspection Checklist               Date: 12/14/2000


1 Checklist Guidelines
The following list of questions has been developed as a guide to help:
    Members of the system requirements team avoid commonly occurring defects in
       the systems requirements specification they create.
    Inspectors identify any of these defects that manage to get into the system
       requirements specification.

An answer of “yes” to any of the following questions should be considered a red flag that
almost, but not always, implies a defect in the system requirements specification.

Use this checklist when creating or inspecting a system requirements specification. If a
large part of the use case model is to be inspected, different inspectors may divide the
work between them so that each answers a different set of questions.

1.1 Initiation Phase Usage
1.2 Elaboration Phase Usage
1.3 Construction Phase Usage




Public                            2000 by Donald Firesmith                        Page 5
Donald Firesmith                    Document ID: SYSRS IC          Version:     0.2
System Requirements Specification Inspection Checklist             Date: 12/14/2000


2 Front Matter Defects
2.1 Title Page
Yes No
O    O    Does the SYSRS have a title page?
O    O    Does the title page correctly identify the customer?
O    O    Does the title page correctly identify the project?
O    O    Does the title page correctly identify the version number of the SYSRS?
O    O    Does the title page correctly identify the status of the SYSRS?

2.2 Revision History
O    O    Does the SYSRS have a revision history page?
O    O    Does the revision history page correctly document each version?
O    O    Does the revision history page adequately describe the major changes?
O    O    Does the revision history page adequately describe the primary authors?

2.3 Table of Contents
O    O    Does the SYSRS have a table of contents?
O    O    Is the table of contents up to date?

2.4 Table of Figures
O    O    Does the SYSRS have a table of figures?
O    O    Is the table of figures up to date?




Public                            2000 by Donald Firesmith                     Page 6
Donald Firesmith                    Document ID: SYSRS IC           Version:     0.2
System Requirements Specification Inspection Checklist              Date: 12/14/2000


3 Introduction Defects
3.1 Specification Objectives
Yes No
O    O    Does the Introduction document the objectives of the SYSRS.

3.2 Intended Audiences
O    O    Does the Introduction document the intended audience of the SYSRS.

3.3 References
O    O    Does the Introduction document the all of the references of the SYSRS.

3.4 Specification Overview
O    O    Does the Introduction provide a correct overview of the structure of the
          SYSRS.




Public                            2000 by Donald Firesmith                          Page 7
Donald Firesmith                    Document ID: SYSRS IC            Version:     0.2
System Requirements Specification Inspection Checklist               Date: 12/14/2000


4 System Overview Defects
4.1 Definition Defects
Yes No
O    O    Is the system clearly and correctly defined?
O    O    Is the system definition consistent with that in the Application Vision
          Statement?

4.2 System Functions
O    O    Are the major functions of the system listed?
O    O    Are the system functions consistent with those in the Application Vision
          Statement?

4.3 System Context
O    O    Is the context of the system summarized in terms of one or more context
          diagrams?
O    O    Are the context diagrams complete?
O    O    Are the context diagrams syntactically correct?
O    O    Are the context diagrams cohesive?
O    O    Are the context diagrams modular (i.e., not too cluttered)?

4.3.1 External Data Repositories
O O Are all external data repositories briefly listed and described?
O O Are all external data repositories names and descriptions correct?
O O Are all external data repositories names and descriptions consistent with the
          project glossary?

4.3.2 External Hardware
O O Are all external hardware devices briefly listed and described?
O O Are all external hardware device names and descriptions correct?
O O Are all external hardware device names and descriptions consistent with the
          use case model and project glossary?

4.3.3 External Roles
O O Are all external roles briefly listed and described?
O O Are all external role names and descriptions correct?
O O Are all external role names and descriptions consistent with the use case
          model and project glossary?

4.3.4 External Software
O O Is all external software briefly listed and described?
Public                            2000 by Donald Firesmith                         Page 8
Donald Firesmith                    Document ID: SYSRS IC           Version:     0.2
System Requirements Specification Inspection Checklist              Date: 12/14/2000

O    O    Are all external software names and descriptions correct?
O    O    Are all external software names and descriptions consistent with the use case
          model and project glossary?

4.3.5 External Systems
O O Are all external systems briefly listed and described?
O O Are all external system names and descriptions correct?
O O Are all external system names and descriptions consistent with the use case
          model and project glossary?

4.4 Usage
O    O    Is the typical usage of the system documented?
O    O    Is the usage of the system documented using one or more workflow diagrams
          capturing how the actors collaborate ?




Public                            2000 by Donald Firesmith                      Page 9
Donald Firesmith                    Document ID: SYSRS IC                        Version:     0.2
System Requirements Specification Inspection Checklist                           Date: 12/14/2000


5 System Operational Requirements Defects
5.1 General Defects
Yes No
O     O      Does the use case model lack a clear, coherent organization?1
O     O      Is the use case model not documented in accordance with the project
             requirements specification content and format standard?
O     O      Is any operational requirement not specified in any use case or use case path?

5.2 Context Defects
             Is the boundary of the application (business, system, or software):
O     O        - Incorrect?
O     O        - Unclear?
O     O        - Inconsistently defined?2
O     O      Is the context diagram missing?
             Is the context diagram incomplete?
O     O        - Is a relevant (possibly indirect) external missing?
O     O        - Is a relevant relationship missing?
O     O        - Is the label of a referential relationship missing or unclear?
O     O        - Is the multiplicity of an external missing?
O     O        - Is the boundary of the application missing?
O     O      Is the context diagram too complex?3
O     O      Is the context diagram not understandable without ancillary text?
O     O      Is the context diagram incompatible with its associated ancillary text (if any)?

5.3 External Description Defects
Yes No
O     O      Has a relevant external been overlooked?
             Is any external improperly named?
O     O        - Does the name use computer jargon instead of the terminology of the
               domain?
O     O        - Is the name of any external inconsistent with its definition?
O     O        - Is the name of any external not in the Glossary?
             Do any externals lack cohesion?
O     O        - Is the external an incomplete abstraction?
O     O        - Does the external capture parts of multiple roles?
O     O      Do any human actors correspond to individual persons or job titles instead of
             roles played by people?
1
  The use case model should be organized by benefiting external or possibly by major business workflows.
2
  A clear and consistent boundary is necessary to determine if something is external or internal.
3
  Perhaps the context diagram should be decomposed into multiple smaller diagrams.

Public                                  2000 by Donald Firesmith                               Page 10
Donald Firesmith                    Document ID: SYSRS IC                             Version:     0.2
System Requirements Specification Inspection Checklist                                Date: 12/14/2000

             Is any external improperly defined?
O     O        - Is the definition of any external incorrect?
Yes No
O     O        - Is the definition of any external unclear or ambiguous?
O     O        - Is the definition of any external inconsistent with the definition in the
               Glossary?
O     O      Is any relevant responsibility of an external not documented clearly or
             correctly?
O     O      Do the responsibilities provide an understandable context for the associated
             requirements?
O     O      Does the model fail to document the state machine of an external that is
             relevant to the preconditions and postconditions of some use case path.
O     O      Does the model inadvertently specify requirements on externals?
O     O      Is the type (e.g., role, organization, hardware, software, data repository,
             network) of any external unclear?
O     O      Is the use case diagram for an external missing?
             Is the use case diagram for an external incomplete?
O     O        - Is there a use case description that does not have a corresponding use case
               oval on the diagram?
O     O        - Is there any use case icon that is not connected to either another use case
               icon or external icon?
             Is the use case diagram for an external inconsistent with the rest of the model?
O     O        - Is the name of an external on the diagram inconsistent with its name in the
               associated external description?
O     O        - Is there a use case on the diagram that does not have a corresponding use
               case description?
O     O        - Does a use case have different names in the use case diagram and the use
               case description?
             Is the syntax of the use case diagram incorrect?
O     O        - Is the direction of any dependency relationship between nodes not drawn
               in the correct direction?
O     O        - Is an invokes relationship used incorrectly? 4
O     O        - Is an extends relationship used incorrectly? 5
O     O        - Is an inheritance relationship used incorrectly?
             Is the use case diagram too complex?
O     O        - Are there too many use cases?
O     O        - Are there too many unnecessary relationships?


4
  Invokes should imply a common set of reusable interactions (i.e., point at a “subroutine”).
5
  Extends should describe an optional extension of the path and include extension points within the
interactions. Unfortunately, the extends relationship is rarely used correctly in practice and is probably best
left off of the use case diagram.

Public                                    2000 by Donald Firesmith                                  Page 11
Donald Firesmith                    Document ID: SYSRS IC                    Version:     0.2
System Requirements Specification Inspection Checklist                       Date: 12/14/2000

5.4 Use Case Description Defects
Yes No
O     O     Does the name of any use case not capture its abstraction?
O     O     Is the name of any use case not written from the external’s viewpoint?6
O     O     Has a use case for the external been overlooked?
O     O     Has a use case been allocated to the wrong external?
            Is any use case not functionally cohesive?
O     O       - Is it an incomplete abstraction?
O     O       - Does it combine multiple abstractions?
O     O     Does any use case not provide something of value to its primary external?7
O     O     Does any use case not have a documented business justification?
O     O     Is the business justification unclear or incorrect?
O     O     Does any use case description use computer jargon rather than the
            terminology of the domain experts?
O     O     Does any use case not have a clearly documented, testable textual requirement
            statement?
O     O     Does any use case description contain unnecessary design information or
            design constraints?
O     O     Are there any paths through the use case, to which the primary external is not
            entitled?

5.5 Use Case Path Description Defects
Yes No
            Does the name of any use case path not imply the path?
O     O       - The name is too general?
O     O       - The name is too specific?
O     O       - Does the name not imply the preconditions of the path?
O     O     Does any use case path not have a clearly documented, testable textual
            requirement statement?
O     O     Is any normal path through the use case overlooked?
O     O     Is any relevant or important exceptional path through the use case missing?
O     O     Is the list of preconditions for a use case path missing, incomplete, or contain
            incorrect preconditions?
O     O     Is any precondition incorrectly specified as a requirement?
O     O     Is any relevant interaction missing?
O     O     Is each interaction testable?



6
  For example, “ATM customer withdraws funds” is better than “Withdrawal transaction” or “ATM
handles withdrawal”.
7
  Each use case should support some goal of its primary external.

Public                                2000 by Donald Firesmith                            Page 12
Donald Firesmith                    Document ID: SYSRS IC                        Version:     0.2
System Requirements Specification Inspection Checklist                           Date: 12/14/2000

Yes No
             Does the statement of any interaction not correctly and clearly document the:
O     O        - Initiator of the interaction (external or application)?
O     O        - Name of the interaction?
O     O        - Type of the interaction (request, response, event notification, display)?
O     O        - Receiver of the interaction (external or application)?
O     O        - Important information that flows with the interaction?8
O     O      For interactions involving a GUI, does any interaction statement not use the
             associated standard interaction format? For example:
              The system shall display a Y request prompting the following information
                  from actor X: a, b, c.
              The system shall display a Y response containing the following
                  information to actor X: a, b, c.
              The system shall display a Y event notification containing the following
                  information to actor X: a, b, c.
              Actor X enters a Y request containing the following information into the
                  system: a, b, c.
              Actor X enters the following information into the system: a, b, c.
              Actor X makes a Y selection and notifies the system.
O     O      For interactions involving an API, does any interaction statement not use the
             associated standard interaction format? For example:
              External X sends a Y request containing the following information to the
                  system: a, b, c.
              The system shall send a Y request containing the following information to
                  external X: a, b, c.
              External X sends a Y response containing the following information to the
                  system: a, b, c.
              The system shall send a Y response containing the following information
                  to external X: a, b, c.
              External X sends a Y event notification containing the following
                  information to the system: a, b, c.
              The system shall send a Y event notification containing the following
                  information to external X: a, b, c.
O     O      Is any important information that flows with the interaction not defined in the
             Glossary?
O     O      Is the list of information that flows with an interaction inconsistent with the
             corresponding API specification in the external interface specification or the
             corresponding design in the GUI design document?
             Is any interaction an incorrectly labeled:
O     O        - Precondition?

8
 Only the existence of the information should be documented here. The format and semantics should be
documented in the external interface specification. Also, commonly occurring collections of information
should be listed fully once, given a name, and only the name used in subsequent interactions.

Public                                  2000 by Donald Firesmith                               Page 13
Donald Firesmith                    Document ID: SYSRS IC             Version:     0.2
System Requirements Specification Inspection Checklist                Date: 12/14/2000

O    O      - Hidden internal calculation?
O    O      - Postcondition?
O    O    Are functionally cohesive subsets of interactions not pulled out of large
          complex paths as invoked subordinate use cases?
O    O    Are common reused sets of interactions not pulled out as invoked subordinate
          use cases?
O    O    Are loops and critical regions not documented in the interactions?
O    O    Is any interaction initiated by the application not specified as a requirement?
O    O    Is any interaction initiated by an external incorrectly specified as a
          requirement?
O    O    Does any interaction contain unnecessary design information or design
          constraints?
O    O    Does any interaction use computer jargon rather than the terminology of the
          domain experts?
          If a sequence diagram for the path exists, is it inconsistent with the listed
          interactions?
O    O      - Is an interaction not represented as an arc on the diagram?
O    O      - Is there any arc on the diagram that does not represent an interaction?
O    O      - Are any arcs on the diagram in a different order than that of the listed
            interactions?
O    O      - Is the direction of any arc on the diagram inconsistent with the
            directionality of the interaction?
O    O      - Is the label on the arc inconsistent with the name of the interaction?
O    O    Is the list of postconditions for a use case path missing, incomplete, or does it
          contain an incorrect postcondition?
O    O    Is any complex algorithm not correctly specified as a postcondition?
O    O    Is any postcondition not specified as a requirement (i.e., written using the
          word “shall”)?
O    O    Is any postcondition not testable?
O    O    Is the categorization of the use case path missing, incomplete, or incorrect?




Public                            2000 by Donald Firesmith                        Page 14
Donald Firesmith                    Document ID: SYSRS IC              Version:     0.2
System Requirements Specification Inspection Checklist                 Date: 12/14/2000


6 System Quality Requirements Defects
This section of the checklist focuses on finding defects in the system quality requirements
section of the system requirements specification.

6.1 Auditability Defects
Yes No
O    O     Are all auditability requirements specified (i.e., requirements ensuring that the
           system must store adequate records to enable an audit to occur)?
O    O     Are all specified auditability requirements correct?
O    O     Are all specified auditability requirements testable?

6.2 Configurability Defects
O    O     Are all configurability requirements specified?
O    O     Are all specified configurability requirements correct?
O    O     Are all specified configurability requirements testable?

6.2.1 Functional Variants Defects
O O Are all functional variants requirements specified?
O O Are all specified requirements functional variants correct?
O O Are all specified functional variants requirements testable?

6.2.2 Internationalization Defects
O O Are all requirements concerning native language and character set specified?
O O Are all requirements concerning financial currency specified?
O O Are all requirements concerning legal issues (e.g., import/export laws and
           tariffs, sales tax, trademarks, and privacy laws) specified?
O    O     Are all requirements concerning cultural differences specified?
O    O     Are all specified internationalization requirements correct?
O    O     Are all specified internationalization requirements testable?

6.2.3 Personalization Defects
O O Are all personalization requirements specified?
O O Are all specified personalization requirements correct?
O O Are all specified personalization requirements testable?

6.3 Correctness Defects
O    O     Are all correctness requirements specified?
O    O     Are all specified correctness requirements correct?
O    O     Are all specified correctness requirements testable?



Public                             2000 by Donald Firesmith                        Page 15
Donald Firesmith                    Document ID: SYSRS IC             Version:     0.2
System Requirements Specification Inspection Checklist                Date: 12/14/2000

6.3.1 Allowable Latent Defects
Yes No
O    O    Are all requirements concerning the maximum amount of latent defects
          specified?
O    O    Are all specified requirements concerning allowable latent defects correct?
O    O    Are all specified requirements concerning allowable latent defects
          validatable?

6.3.2 Accuracy Defects
O O Are all accuracy requirements specified?
O O Are all specified accuracy requirements correct?
O O Are all specified accuracy requirements testable?

6.3.3 Precision Defects
O O Are all precision requirements specified?
O O Are all specified precision requirements correct?
O O Are all specified precision requirements testable?

6.3.4 Timeliness Defects
O O Are all requirements concerning the timeliness of displayed information
          specified?
O    O    Are all data archival requirements specified?
O    O    Are all data deletion requirements specified?
O    O    Are all specified timeliness requirements correct?
O    O    Are all specified timeliness requirements testable?

6.4 Efficiency Defects
O    O    Are all efficiency requirements specified?
O    O    Are all specified efficiency requirements correct?
O    O    Are all specified efficiency requirements validatable?

6.5 Extensibility Defects
O    O    Are all extensibility requirements specified?
O    O    Are all specified extensibility requirements correct?
O    O    Are all specified extensibility requirements validatable?

6.6 Interoperability Defects
O    O    Are all interoperability requirements specified (e.g., is each external system to
          which the current system must be integrated identified including versions)?
O    O    Are all interoperability requirements correct?

Public                            2000 by Donald Firesmith                        Page 16
Donald Firesmith                    Document ID: SYSRS IC            Version:     0.2
System Requirements Specification Inspection Checklist               Date: 12/14/2000

O    O    Are all interoperability requirements testable?

6.7 Maintainability Defects
Yes No
O    O    Are all maintainability requirements specified?
O    O    Are all specified maintainability requirements correct?
O    O    Are all specified maintainability requirements validatable?

6.8 Operational Availability Defects
O    O    Are all operational availability requirements specified?
O    O    Are all specified operational availability requirements correct?
O    O    Are all specified operational availability requirements achievable given
          current or projected technology?
O    O    Are all specified operational availability requirements unambiguous (e.g.,
          99.99% as opposed to 7x24)?
O    O    Do the specified operational availability requirements clearly differentiate
          between scheduled and unscheduled downtime?
O    O    Are all specified operational availability requirements testable?

6.9 Performance Defects
O    O    Are all performance requirements specified?
O    O    Are all specified performance requirements correct?
O    O    Are all specified performance requirements achievable given current or
          projected technology?
O    O    Are all specified performance requirements testable?

6.9.1 Capacity Defects
O O Are all capacity requirements specified?
O O Are all specified capacity requirements correct?
O O Are all specified capacity requirements testable?

6.9.2 Latency Defects
O O Are all latency requirements specified?
O O Are all specified latency requirements correct?
O O Are all specified latency requirements testable?

6.9.3 Response Time Defects
O O Are all response time requirements specified?
O O Are all specified response time requirements correct?
O O Are all specified response time requirements testable?

Public                            2000 by Donald Firesmith                       Page 17
Donald Firesmith                    Document ID: SYSRS IC          Version:     0.2
System Requirements Specification Inspection Checklist             Date: 12/14/2000

6.9.4 Throughput Defects
Yes No
O    O    Are all throughput requirements specified?
O    O    Are all specified throughput requirements correct?
O    O    Are all specified throughput requirements testable?

6.10 Portability Defects
O    O    Are all portability requirements specified?
O    O    Do the specified portability requirements address hardware and operating
          systems?
O    O    Are all specified portability requirements correct?
O    O    Are all specified portability requirements testable?

6.11 Reliability Defects
O    O    Are all reliability requirements specified?
O    O    Are the specified reliability requirements correctly differentiated from
          robustness requirements?
O    O    Do the specified reliability requirements address mean time between failure
          and maximum number of failures per unit time?
O    O    Are all specified reliability requirements correct?
O    O    Are all specified reliability requirements validable?

6.12 Reusability Defects
O    O    Are all reusability requirements specified?
O    O    Do the reusability requirements address reuse of existing components?
O    O    Do the reusability requirements address reuse of components to be developed
          as part of the system?
O    O    Are all specified reusability requirements correct?
O    O    Are all specified reusability requirements testable?

6.13 Robustness Defects
O    O    Are all robustness requirements specified?
O    O    Do the robustness requirements address failover?
O    O    Do the robustness requirements address degraded modes of operation?
O    O    Do the robustness requirements address disaster recovery?
O    O    Do the robustness requirements address how to handle invalid input?
O    O    Do the robustness requirements address failure of hardware?
O    O    Do the robustness requirements address failure of software?
O    O    Do the robustness requirements address failure of external systems?
O    O    Are all specified robustness requirements correct?

Public                            2000 by Donald Firesmith                     Page 18
Donald Firesmith                    Document ID: SYSRS IC               Version:     0.2
System Requirements Specification Inspection Checklist                  Date: 12/14/2000

O    O      Are all specified robustness requirements testable?
         Failure of external systems on which the system depends.

6.14 Safety Defects
Yes No
O    O      Are all safety requirements specified (including safety of data as property)?
O    O      Are all specified safety requirements correct?
O    O      Are all specified safety requirements validatable?

6.15 Scalability Defects
O    O      Are all scalability requirements specified?
O    O      Are all specified scalability requirements correct?
O    O      Are all specified scalability requirements validatable?

6.16 Security Defects
O    O      Are all security requirements specified?
O    O      Are all specified security requirements actually requirements as opposed to
            unnecessary design constraints?
O    O      Are all specified identification, authentication, and authorization requirements
            correctly categorized?
O    O      Are all specified security requirements correct?
O    O      Are all specified security requirements validatable?

6.16.1 Identification Defects
O O Are all identification requirements specified?
O O Are all specified identification requirements correct?
O O Are all specified identification requirements validatable?

6.16.2 Authentication Defects
O O Are all authentication requirements specified?
O O Are all specified authentication requirements correct?
O O Are all specified authentication requirements validatable?

6.16.3 Authorization Defects
O O Are all authorization requirements (i.e., for each external actor and system)
            specified?
O    O      Are all specified authorization requirements correct?
O    O      Are all specified authorization requirements validatable?




Public                               2000 by Donald Firesmith                      Page 19
Donald Firesmith                    Document ID: SYSRS IC            Version:     0.2
System Requirements Specification Inspection Checklist               Date: 12/14/2000

6.16.4 Content Protection Defects
Yes No
O    O    Are all content protection requirements (e.g., concerning viruses, Trojans)
          specified?
O    O    Are all specified content protection requirements correct?
O    O    Are all specified content protection requirements validatable?

6.16.5 Privacy Defects
O O Are all communications privacy requirements specified?
O O Are all data privacy requirements specified?
O O Are all specified privacy requirements correct?
O O Are all specified privacy requirements testable?

6.16.6 Integrity Defects
O O Are all communications integrity requirements specified?
O O Are all data integrity requirements specified?
O O Are all specified privacy requirements correct?
O O Are all specified privacy requirements testable?

6.16.7 Intrusion Detection Defects
O O Are all intrusion detection requirements specified?
O O Are all specified intrusion detection requirements correct?
O O Are all specified intrusion detection requirements testable?

6.16.8 Nonrepudiation Defects
O O Are all nonrepudiation requirements specified?
O O Are all requirements concerning recording when and how a user used the
          system specified?
O    O    Are all requirements specified concerning recording the sender, recipient, and
          the time of messages involving the system?
O    O    Are all specified requirements concerning nonrepudiation correct?
O    O    Are all specified requirements concerning nonrepudiation validatable?

6.16.9 System Maintenance Defects
O O Are all system maintenance security requirements specified?
O O Are all specified system maintenance security requirements correct?
O O Are all specified system maintenance security requirements validatable?




Public                            2000 by Donald Firesmith                      Page 20
Donald Firesmith                    Document ID: SYSRS IC           Version:     0.2
System Requirements Specification Inspection Checklist              Date: 12/14/2000

6.17 Testability Defects
Yes No
O    O    Are all testability requirements specified?
O    O    Are all specified testability requirements correct?
O    O    Are all specified testability requirements validatable?

6.18 Usability Defects
O    O    Are all usability requirements specified?
O    O    Are all specified usability requirements correct?
O    O    Are all specified usability requirements validatable?

6.18.1 Installation Defects
O O Are all installation requirements specified?
O O Are all specified installation usability requirements correct?
O O Are all specified installation usability requirements validatable?

6.18.2 Usage Defects
O O Are all user usability requirements specified?
O O Are all specified user usability requirements correct?
O O Are all specified user usability requirements validatable?




Public                            2000 by Donald Firesmith                     Page 21
Donald Firesmith                    Document ID: SYSRS IC             Version:     0.2
System Requirements Specification Inspection Checklist                Date: 12/14/2000


7 System Design Constraints Defects
This section of the checklist focuses on finding defects in the system design constraints
section of the system requirements specification.

7.1 Software Constraints
Yes No
O    O     Are all software design constraints specified?
O    O     Are the specified software design constraints correct?
O    O     Are the specified software design constraints necessary?

7.1.1 Components
O O Are all design constraints regarding the use of COTS package software
           specified?
O    O     Are all licensing restrictions addressed?
O    O     Are all usage restrictions?
O    O     Are the specified COTS design constraints correct?
O    O     Are the specified COTS design constraints necessary?

7.1.2 Databases
O O Are all database design constraints specified?
O O Are the specified database design constraints correct?
O O Are specified database design constraints necessary?

7.1.3 High-Level Languages
O O Are all high-level language design constraints specified?
O O Are the specified high-level language constraints correct?
O O Are specified high-level language constraints necessary?

7.1.4 Standards
O O Are all software standards design constraints specified?
O O Are all relevant industry standards addressed?
O O Are all relevant regulatory standards addressed?
O O Are the specified software standards constraints correct?
O O Are specified software standards constraints necessary?

7.2 Hardware Design Constraints
O    O     Are all hardware design constraints specified?
O    O     Are the specified hardware design constraints correct?
O    O     Are specified hardware design constraints necessary?


Public                             2000 by Donald Firesmith                       Page 22