Topic: Software Testing-Software Requirements Specifica..

Software Testing-Software Requirements Specification

1. Purpose. This document specifies the requirements for a system and the methods to be used to ensure that each requirement has been met.
2. Scope. This paragraph describes the scope of requirements covered by this document. It shall depict the context of the covered requirements with respect to other related and interfacing systems to illustrate what requirements are not covered herein.
3. Documentation Conventions. This section provides a list of notational and other document conventions used within the document. Include a depiction of symbology used in diagrams along with the meaning of each symbol. Provide a description of special text usage such as fixed width fonts, alert, and warning icons.
4. System Identification and Overview. This paragraph shall briefly state the purpose of the system to which this document applies. It shall describe the general nature of the system; summarize the history of system development, operation, and maintenance; identify the project sponsor, acquirer, user, developer, and support agencies; and identify current and planned operating and user sites.

5. Required States and Modes. If the system is required to operate in more than one state or mode having requirements distinct from other states or modes, this paragraph shall identify and define each state and mode. Examples of states and modes include: idle, ready, active, post-use analysis, training, degraded, emergency, back up, wartime, peacetime. The distinction between states and modes is arbitrary. A system may be described in terms of states only, modes only, states within modes, modes within states, or any other scheme that is useful. If no states or modes are required, this paragraph shall so state, without the need to create artificial distinctions. If states and/or modes are required, each requirement or group of requirements in this specification shall be correlated to the states and modes.
6. Requirements
6.1.Functional and Performance. This paragraph shall be divided into subparagraphs to itemize the requirements associated with each capability of the system. A "capability" is defined as a group of related requirements. The word "capability" may be replaced with "function," "subject," "object," or other term useful for presenting the requirements.
This paragraph shall identify a required system capability and shall itemize and uniquely identify the requirements associated with the capability. If the capability can be more clearly specified by dividing it into constituent capabilities, the constituent capabilities shall be specified in subparagraphs. The requirements shall specify required behavior of the system and shall include applicable parameters, such as response times, throughput times, other timing constraints, sequencing, accuracy, capacities (how much/how many), priorities, continuous operation requirements, and allowable deviations based on operating conditions. The requirements shall include, as applicable, required behavior under unexpected, unallowed, or "out of bounds" conditions; user roles responsible for performing functions; requirements for error handling; and any provisions to be incorporated into the system to provide continuity of operations in the event of emergencies.
6.2. Organizational. This paragraph shall specify organizations, locations, roles and other user attributes and the functional requirements that each must execute.
6.3. Security and Privacy Protection. This paragraph shall specify the system requirements, if any, concerned with maintaining security and privacy. These requirements shall include, as applicable, the security/privacy environment in which the system must operate, the type and degree of security or privacy to be provided, the security/privacy risks the system must withstand, required safeguards to reduce those risks, the security/privacy policy that must be met, the security/privacy accountability the system must provide, access instructions for user roles, and the criteria that must be met for security/privacy certification/accreditation.
6.4. Human-Factors Engineering (Ergonomics). This paragraph shall specify the system requirements, if any, included to accommodate the number, skill levels, duty cycles, training needs, or other information about the personnel who will use or support the system. Examples include requirements for number of simultaneous users and for built-in help or training features. Also included shall be the human factors engineering requirements, if any, imposed on the system. These requirements shall include, as applicable, considerations for the capabilities and limitations of humans; foreseeable human errors under both normal and extreme conditions; and specific areas where the effects of human error would be particularly serious. Examples include requirements for color and duration of error messages, physical placement of critical indicators or keys, and use of auditory signals.
6.5. Operations and Maintenance. This paragraph shall state requirements associated with operations and maintenance such as system availability, backup and recovery, monitoring and tuning, installation and configuration, auditing, batch scheduling, support, enhancement, and defect repairs.
6.6. System External Interface. This paragraph shall identify the required external interfaces of the system (that is, relationships with other systems that involve sharing, providing or exchanging data). The identification of each interface shall include an application-unique identifier and shall designate the interfacing systems by name, number, version, and documentation references, as applicable. The identification shall state which systems have fixed interface characteristics (and therefore impose interface requirements on interfacing systems) and which are being developed or modified (thus having interface requirements imposed on them). One or more interface diagrams shall be provided to depict the interfaces.
6.7.Application-unique identifier of interface. This paragraph shall identify a system external interface by application-unique identifier, shall briefly identify the interfacing system, and shall be divided into subparagraphs as needed to state the requirements imposed on the system to achieve the interface. Interface characteristics of the other systems involved in the interface shall be stated as assumptions or as "When [the system not covered] does this, the system shall..," not as requirements on the other systems. This paragraph may reference other documents (such as data dictionaries, standards for communication protocols, and standards for user interfaces) in place of stating the information here. The requirements shall include the following, as applicable, presented in any order suited to the requirements, and shall note any differences in these characteristics from the point of view of the interfacing system (such as different expectations about the size, frequency, or other characteristics of data elements):

Some of the other requirements considered are
1. Priority that the system must assign the interface
2. Requirements on the type of interface (such as real-time data transfer, storage-and-retrieval of data, etc.) to be implemented
3. Required characteristics of individual data elements that the system must provide, store, send, access, retrieve, etc., such as:
4. Names/identifiers
5. User access requirements to review, monitor, or trigger interface input or output
6. Application-unique identifiers
7. Non-technical (natural-language) name
8. Technical name (e.g., variable or field name in code or database)
9. Abbreviation or synonymous names
10. Data type (alphanumeric, integer, etc.)
11. Size and format (such as length and punctuation of a character string)
12. Units of measurement (such as meters, dollars, nanoseconds)
13. Range of enumeration of possible values (such as 0-99)
14. Accuracy (how correct) and precision (number of significant digits)
15. Priority, timing, frequency, volume, sequencing, and other constraints, such as whether the data element may be updated and whether business rules apply
16. Security and privacy constraints
17. Sources (setting/sending entities) and recipients (using/receiving entities)
18. Required characteristics of data element assemblies (records, messages, files, arrays, displays, reports, etc.) that the system must provide, store, send, access, receive, etc., such as:
19. Names/identifiers
20. Application-unique identifiers
21. Non-technical (natural-language) name
22. Technical name (e.g., record or data structure name in code or database)
23. Abbreviation or synonymous names
24. Data elements in the assembly and their structure (number, order, grouping)
25. Medium (such as disk) and structure of data elements/assemblies on the medium
26. Visual and auditory characteristics of displays and other outputs (such as colors, layouts, fonts, icons and other display elements, beeps, lights)
27. Relationships among assemblies, such as sorting/access characteristics
28. Priority, timing, frequency, volume, sequencing, and other constraints, such as whether the assembly may be updated and whether business rules apply
29. Security and privacy constraints
30. Sources (setting/sending entities) and recipients (using/receiving entities)
31. Required characteristics of communication methods that the system must use for the interface, such as:
32. Application-unique identifiers
33. Communication links/bands/frequencies/media and their characteristics
34. Message formatting 35. Flow control (such as sequence numbering and buffer allocation)
36. Data transfer rate, whether periodic/aperiodic, and interval between transfers
37. Routing, addressing, and naming conventions
38. Transmission services, including priority and goals
39. Safety/security/privacy considerations, such as encryption, user authentication, compartmentalization, and auditing
40. Required characteristics of protocols the system must use for the interface, such as:
41. Application-unique identifiers
42. Priority/layer of the protocol
43. Packeting, including fragmentation and reassembly, routing, and addressing
44. Legality checks, error control, and recovery procedures
45. Synchronization, including connection establishment, maintenance, termination
46. Status, identification, and any other reporting features
47. Other required characteristics, such as physical compatibility of the interfacing entities (dimensions, tolerances, loads, plug compatibility, etc.), voltages, etc.
Include or reference the Memorandums of Agreement, which record the understanding between those responsible for interfacing systems, subsystems, and databases.
6.8. Design Constraints and Qualification This paragraph shall specify the requirements, if any, that constrain the design and implementation of the system. These requirements may be specified by reference to appropriate commercial or military standards and specifications. Examples include requirements concerning:
a) Use of a particular system architecture or requirements on the architecture, such as required databases or other software units; use of standard or existing components; or use of Government/acquirer-furnished property (equipment, information, or software)
b) Use of particular design or implementation standards; use of particular data standards; use of a particular programming language
c) Flexibility and expandability that must be provided to support anticipated areas of growth or changes in technology, threat, or mission.
6.9. Computer Resource
6.9.1. Computer Hardware. This paragraph shall specify the requirements, if any, regarding computer hardware that must be used by the system. The requirements shall include, as applicable, number of each type of equipment, type, size, capacity, and other required characteristics of processors, memory, input/output devices, auxiliary storage, communications/network equipment, and other required equipment.
6.9.2. Computer Hardware Resource (including utilization requirements). This paragraph shall specify the requirements, if any, on the system's computer hardware resource utilization, such as maximum allowable use of processor capacity, memory capacity, input/output device capacity, auxiliary storage device capacity, and communications/network equipment capacity. The requirements (stated, for example, as percentages of the capacity of each computer hardware resource) shall include the conditions, if any, under which the resource utilization is to be measured.
6.9.3. Computer Software. This paragraph shall specify the requirements, if any, regarding computer software that must be used by, or incorporated into, the system. Examples include operating systems, database management systems, communications/network software, utility software, input and equipment simulators, test software, and manufacturing software. The correct nomenclature, version, and documentation references of each such software item shall be provided.
6.9.4. Computer Communications. This paragraph shall specify the additional requirements, if any, concerning the computer communica�tions that must be used by the system. Examples include geographic locations to be linked; configuration and network topology; transmission techniques; data transfer rates; gateways; required system use times; type and volume of data to be transmitted/received; time boundaries for transmission/reception/response; peak volumes of data; and diagnostic features.
6.10. Internal Data. This paragraph shall specify the requirements, if any, imposed on data internal to the system. Included shall be requirements, if any, on databases and data files to be included in the system. If all decisions about internal data are left to the design, this fact shall be so stated.
This section lists data requirements to be met by the system. Most data requirements will come from the data model itself. Use a separate subsection of this section to represent each entity. The subsection header will list the entity�s name and abbreviation. The body of each entity section will provide entity details including, but not limited to, subtype, transaction volumes, description, user role access requirements, and notes. It shall also include relationships to other entities as well as information regarding each relationship end such as name, optionality, and cardinality. Each entity section shall also list the required attributes, each in its own subsection. The attribute information shall include, but not be limited to, name, description, sequence within the entity, domain, format, average length, maximum length, decimal places, optionality, unit of measure, default value, allowable values and ranges, volumes (percent used initially and on average), authority, responsibility, validation rules, comments, and notes.
6.11. Personnel, Training, and Logistics.
Personnel-related requirements. This paragraph shall specify the personnel and skill requirements needed to use, operate and maintain the system. Examples include system managers, business analysts, computer operators, network engineers, security specialists, database administrators, system administrators, and end-users. Training-related requirements. This paragraph shall specify the system requirements, if any, pertaining to training. Examples include training software to be included in the system.
Logistics-related requirements. This paragraph shall specify the system requirements, if any, concerned with logistics considerations. These considerations may include: system maintenance, software support, system transportation modes, supply system requirements, impact on existing facilities, and impact on existing equipment.
6.12. Distribution and Installation. This section shall specify the requirements, if any, for labeling, installation, and handling the system for delivery (for example, delivery in files compressed in a certain way). Applicable military specifications and standards may be referenced if appropriate.
6.13. Precedence and Criticality. This paragraph shall specify, if applicable, the order of precedence, criticality, or assigned weights indicating the relative importance of the requirements in this specification. Examples include identifying those requirements deemed critical to safety, security, or privacy for purposes of singling them out for special treatment. If all requirements have equal weight, this paragraph shall so state. Requirements could also be ranked using the MoSCoW method. Each requirement is designated as Must have, Should have, Could have, or Won�t have. This provides a basis for moving requirements to later releases as necessary.
7. System Quality Characteristics. This paragraph shall specify the system requirements, if any, concerned with software quality factors identified in the contract or derived from a higher level specification. Examples include quantitative requirements regarding system functionality (the ability to perform all required functions), reliability (the ability to perform with correct, consistent results), maintainability (the ability to be easily corrected), availability (the ability to be accessed and operated when needed), flexibility (the ability to be easily adapted to changing requirements), portability (the ability to be easily modified for a new environment), reusability (the ability to be used in multiple applications), testability (the ability to be easily and thoroughly tested), usability (the ability to be easily learned and used), and other attributes.
8. Requirements Traceability.
8.1. Traceability from System Requirements to Operational Requirements. This section provides Traceability from each system requirement in this specification to the operational requirement it addresses. Operational requirements are those specified in the ORD.
8.2. Traceability from Operational Requirements to System Requirements. This section provides Traceability from each operational requirement to the system requirement that address it.
9. Change History. This section shall provide a running history of changes applied to the SRS by version number. < ="text/"> < ="text/" ="http://pagead2.googlesyndication.com/pagead/show_ads.js"> < ="text/"> < ="text/" ="http://pagead2.googlesyndication.com/pagead/show_ads.js">