SRS(Software Requriment Specification)

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.