Software requirements are specified in this document, including the revision or release number. Describe the scope of the product that is covered by this SRS, particularly if this SRS describes only part of the system or a single subsystem. This software requirements document specification provides complete information about the system called BeFriend which will be developed by our project team Visiondary. The system is planned as a camera and sensor integrated hardware device for blind people. In this section, we.
2. IDENTIFICATION NUMBER
DI-IPSC-81431
3. DESCRIPTION/PURPOSE
3.1 The System/Subsystem Specification (SSS) specifies the requirementsfor a system or subsystem and the methods to be used to ensurethat each requirement has been met. Requirements pertaining tothe system or subsystem's external interfaces may be presentedin the SSS or in one or more Interface Requirements Specifications(IRSs) (DI-IPSC-81434) referenced from the SSS.
3.2 The SSS, possibly supplemented by IRSs, is used as the basisfor design and qualification testing of a system or subsystem.Throughout this DID, the term 'system' may be interpretedto mean 'subsystem' as applicable. The resulting documentshould be titled System Specification or Subsystem Specification(SSS).
4. APPROVAL DATE (YYMMDD)
941205
5. OFFICE OF PRIMARY RESPONSIBILITY
EC
6a. DTIC APPLICABLE
6b. GIDEP APPLICABLE
7. APPLICATION/INTERRELATIONSHIP
7.1 This Data Item Description (DID) contains the format and contentpreparation instructions for the data product generated by specificand discrete task requirements as delineated in the contract.
7.2 This DID is used when the developer is tasked to define andrecord the requirements to be met by a system or subsystem.
7.3 Requirements pertaining to system or subsystem interfacesmay be presented in the SSS or in IRSs.
7.4 The Contract Data Requirements List (CDRL) (DD 1423) shouldspecify whether deliverable data are to be delivered on paperor electronic media; are to be in a given electronic form (suchas ASCII, CALS, or compatible with a specified word processoror other support software); may be delivered in developer formatrather than in the format specified herein; and may reside ina computer-aided software engineering (CASE) or other automatedtool rather than in the form of a traditional document.
7.5 This DID supersedes DI-CMAN-80008A and DI-IPSC-80690.
8. APPROVAL LIMITATION
Limited Approval from 12/5/94 through 12/5/96
9a. APPLICABLE FORMS
9b. AMSC NUMBER
N7074
10. PREPARATION INSTRUCTIONS
10.1 General instructions.
a. Automated techniques. Use of automated techniques isencouraged. The term 'document' in this DID means acollection of data regardless of its medium.
b. Alternate presentation styles. Diagrams, tables, matrices,and other presentation styles are acceptable substitutes for textwhen data required by this DID can be made more readable usingthese styles.
c. Title page or identifier with signature blocks. Thedocument shall include a title page containing, as applicable:document number; volume number; version/revision indicator; securitymarkings or other restrictions on the handling of the document;date; document title; name, abbreviation, and any other identifierfor the system, subsystem, or item to which the document applies;contract number; CDRL item number; organization for which thedocument has been prepared; name and address of the preparingorganization; distribution statement; and signature blocks forthe developer representative authorized to release the document,the acquirer representative authorized to approve the document,and the dates of release/approval. For data in a database or otheralternative form, this information shall be included on externaland internal labels or by equivalent identification methods.
d. Table of contents. The document shall contain a tableof contents providing the number, title, and page number of eachtitled paragraph, figure, table, and appendix. For data in a databaseor other alternative form, this information shall consist of aninternal or external table of contents containing pointers to,or instructions for accessing, each paragraph, figure, table,and appendix or their equivalents.
e. Page numbering/labeling. Each page shall contain a uniquepage number and display the document number, including version,volume, and date, as applicable. For data in a database or otheralternative form, files, screens, or other entities shall be assignednames or numbers in such a way that desired data can be indexedand accessed.
f. Response to tailoring instructions. If a paragraph istailored out of this DID, the resulting document shall containthe corresponding paragraph number and title, followed by 'Thisparagraph has been tailored out.' For data in a databaseor other alternative form, this representation need occur onlyin the table of contents or equivalent.
g. Multiple paragraphs and subparagraphs. Any section,paragraph, or subparagraph in this DID may be written as multipleparagraphs or subparagraphs to enhance readability.
h. Standard data descriptions. If a data description requiredby this DID has been published in a standard data element dictionaryspecified in the contract, reference to an entry in that dictionaryis preferred over including the description itself.
i. Substitution of existing documents. Commercial or otherexisting documents may be substituted for all or part of the documentif they contain the required data.
10.2 Content requirements.
Content requirements begin on the following page. The numbersshown designate the paragraph numbers to be used in the document.Each such number is understood to have the prefix '10.2'within this DID. For example, the paragraph numbered 1.1 is understoodto be paragraph 10.2.1.1 within this DID.
1. Scope.
This section shall be divided into the following paragraphs.
1.1 Identification.
This paragraph shall contain a full identification of the systemto which this document applies, including, as applicable, identificationnumber(s), title(s), abbreviation(s), version number(s), and releasenumber(s).
1.2 System overview.
This paragraph shall briefly state the purpose of the system towhich this document applies. It shall describe the general natureof the system; summarize the history of system development, operation,and maintenance; identify the project sponsor, acquirer, user,developer, and support agencies; identify current and plannedoperating sites; and list other relevant documents.
1.3 Document overview.
This paragraph shall summarize the purpose and contents of thisdocument and shall describe any security or privacy considerationsassociated with its use.
2. Referenced documents.
This section shall list the number, title, revision, and dateof all documents referenced in this specification. This sectionshall also identify the source for all documents not availablethrough normal Government stocking activities.
3. Requirements.
This section shall be divided into the following paragraphs tospecify the system requirements, that is, those characteristicsof the system that are conditions for its acceptance. Each requirementshall be assigned a project-unique identifier to support testingand traceability and shall be stated in such a way that an objectivetest can be defined for it. Each requirement shall be annotatedwith associated qualification method(s) (see section 4) and, forsubsystems, traceability to system requirements (see section 5.a),if not provided in those sections. The degree of detail to beprovided shall be guided by the following rule: Include thosecharacteristics of the system that are conditions for system acceptance;defer to design descriptions those characteristics that the acquireris willing to leave up to the developer. If there are no requirementsin a given paragraph, the paragraph shall so state. If a givenrequirement fits into more than one paragraph, it may be statedonce and referenced from the other paragraphs.
3.1 Required states and modes.
If the system is required to operate in more than one state ormode 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-useanalysis, training, degraded, emergency, backup, wartime, peacetime.The distinction between states and modes is arbitrary. A systemmay be described in terms of states only, modes only, states withinmodes, 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 statesand/or modes are required, each requirement or group of requirementsin this specification shall be correlated to the states and modes.The correlation may be indicated by a table or other method inthis paragraph, in an appendix referenced from this paragraph,or by annotation of the requirements in the paragraphs where theyappear.
3.2 System capability requirements.
This paragraph shall be divided into subparagraphs to itemizethe 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 usefulfor presenting the requirements.
3.2.x (System capability).
This paragraph shall identify a required system capability andshall itemize the requirements associated with the capability.If the capability can be more clearly specified by dividing itinto constituent capabilities, the constituent capabilities shallbe specified in subparagraphs. The requirements shall specifyrequired 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 basedon operating conditions. The requirements shall include, as applicable,required behavior under unexpected, unallowed, or 'out ofbounds' conditions, requirements for error handling, andany provisions to be incorporated into the system to provide continuityof operations in the event of emergencies. Paragraph 3.3.x ofthis DID provides a list of topics to be considered when specifyingrequirements regarding inputs the system must accept and outputsit must produce.
3.3 System external interface requirements.
This paragraph shall be divided into subparagraphs to specifythe requirements, if any, for the system's external interfaces.This paragraph may reference one or more Interface RequirementsSpecifications (IRSs) or other documents containing these requirements.
3.3.1 Interface identification and diagrams.
This paragraph shall identify the required external interfacesof the system. The identification of each interface shall includea project-unique identifier and shall designate the interfacingentities (systems, configuration items, users, etc.) by name,number, version, and documentation references, as applicable.The identification shall state which entities have fixed interfacecharacteristics (and therefore impose interface requirements oninterfacing entities) and which are being developed or modified(thus having interface requirements imposed on them). One or moreinterface diagrams shall be provided to depict the interfaces.
3.3.x (Project-unique identifier of interface).
This paragraph (beginning with 3.3.2) shall identify a systemexternal interface by project-unique identifier, shall brieflyidentify the interfacing entities, and shall be divided into subparagraphsas needed to state the requirements imposed on the system to achievethe interface. Interface characteristics of the other entitiesinvolved in the interface shall be stated as assumptions or as'When [the entity not covered] does this, the system shall...,'not as requirements on the other entities. This paragraph mayreference other documents (such as data dictionaries, standardsfor communication protocols, and standards for user interfaces)in place of stating the information here. The requirements shallinclude the following, as applicable, presented in any order suitedto the requirements, and shall note any differences in these characteristicsfrom the point of view of the interfacing entities (such as differentexpectations about the size, frequency, or other characteristicsof data elements):
a. Priority that the system must assign the interface
b. Requirements on the type of interface (such as real-time datatransfer, storage-and-retrieval of data, etc.) to be implemented
c. Required characteristics of individual data elements that thesystem must provide, store, send, access, receive, etc., suchas:
1) Names/identifiers
a) Project-unique identifier
b) Non-technical (natural-language) name
c) DoD standard data element name
d) Technical name (e.g., variable or field name in code ordatabase)
e) Abbreviation or synonymous names
2) Data type (alphanumeric, integer, etc.)
3) Size and format (such as length and punctuation of a characterstring)
4) Units of measurement (such as meters, dollars, nanoseconds)
5) Range or enumeration of possible values (such as 0-99)
6) Accuracy (how correct) and precision (number of significantdigits)
7) Priority, timing, frequency, volume, sequencing, and otherconstraints, such as whether the data element may be updated andwhether business rules apply
8) Security and privacy constraints
9) Sources (setting/sending entities) and recipients (using/receivingentities)
d. Required characteristics of data element assemblies (records,messages, files, arrays, displays, reports, etc.) that the systemmust provide, store, send, access, receive, etc., such as:
1) Names/identifiers
a) Project-unique identifier
b) Non-technical (natural language) name
c) Technical name (e.g., record or data structure name incode or database)
d) Abbreviations or synonymous names
2) Data elements in the assembly and their structure (number,order, grouping)
3) Medium (such as disk) and structure of data elements/assemblieson the medium
4) Visual and auditory characteristics of displays and otheroutputs (such as colors, layouts, fonts, icons and other displayelements, beeps, lights)
5) Relationships among assemblies, such as sorting/accesscharacteristics
6) Priority, timing, frequency, volume, sequencing, and otherconstraints, such as whether the assembly may be updated and whetherbusiness rules apply
7) Security and privacy constraints
8) Sources (setting/sending entities) and recipients (using/receivingentities)
e. Required characteristics of communication methods that thesystem must use for the interface, such as:
1) Project-unique identifier(s)
2) Communication links/bands/frequencies/media and their characteristics
3) Message formatting
4) Flow control (such as sequence numbering and buffer allocation)
5) Data transfer rate, whether periodic/aperiodic, and intervalbetween transfers
6) Routing, addressing, and naming conventions
7) Transmission services, including priority and grade
8) Safety/security/privacy considerations, such as encryption,user authentication, compartmentalization, and auditing
f. Required characteristics of protocols the system must use forthe interface, such as:
1) Project-unique identifier(s)
2) Priority/layer of the protocol
3) Packeting, including fragmentation and reassembly, routing,and addressing
4) Legality checks, error control, and recovery procedures
5) Synchronization, including connection establishment, maintenance,termination
6) Status, identification, and any other reporting features
g. Other required characteristics, such as physical compatibilityof the interfacing entities (dimensions, tolerances, loads, plugcompatibility, etc.), voltages, etc.
3.4 System internal interface requirements.
This paragraph shall specify the requirements, if any, imposedon interfaces internal to the system. If all internal interfacesare left to the design or to requirement specifications for systemcomponents, this fact shall be so stated. If such requirementsare to be imposed, paragraph 3.3 of this DID provides a list oftopics to be considered.
3.5 System internal data requirements.
This paragraph shall specify the requirements, if any, imposedon 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 orto requirements specifications for system components, this factshall be so stated. If such requirements are to be imposed, paragraphs3.3.x.c and 3.3.x.d of this DID provide a list of topics to beconsidered.
3.6 Adaptation requirements.
This paragraph shall specify the requirements, if any, concerninginstallation-dependent data that the system is required to provide(such as site-dependent latitude and longitude or site-dependentstate tax codes) and operational parameters that the system isrequired to use that may vary according to operational needs (suchas parameters indicating operation-dependent targeting constantsor data recording).
3.7 Safety requirements.
This paragraph shall specify the system requirements, if any,concerned with preventing or minimizing unintended hazards topersonnel, property, and the physical environment. Examples includerestricting the use of dangerous materials; classifying explosivesfor purposes of shipping, handling, and storing; abort/escapeprovisions from enclosures; gas detection and warning devices;grounding of electrical systems; decontamination; and explosionproofing. This paragraph shall include the system requirements,if any, for nuclear components, including, as applicable, requirementsfor component design, prevention of inadvertent detonation, andcompliance with nuclear safety rules.
3.8 Security and privacy requirements.
This paragraph shall specify the system requirements, if any,concerned with maintaining security and privacy. The requirementsshall include, as applicable, the security/privacy environmentin which the system must operate, the type and degree of securityor privacy to be provided, the security/privacy risks the systemmust withstand, required safeguards to reduce those risks, thesecurity/privacy policy that must be met, the security/privacyaccountability the system must provide, and the criteria thatmust be met for security/privacy certification/accreditation.
3.9 System environment requirements.
This paragraph shall specify the requirements, if any, regardingthe environment in which the system must operate. Examples fora software system are the computer hardware and operating systemon which the software must run. (Additional requirements concerningcomputer resources are given in the next paragraph). Examplesfor a hardware-software system include the environmental conditionsthat the system must withstand during transportation, storage,and operation, such as conditions in the natural environment (wind,rain, temperature, geographic location), the induced environment(motion, shock, noise, electromagnetic radiation), and environmentsdue to enemy action (explosions, radiation).
3.10 Computer resource requirements.
This paragraph shall be divided into the following subparagraphs.Depending upon the nature of the system, the computer resourcescovered in these subparagraphs may constitute the environmentof the system (as for a software system) or components of thesystem (as for a hardware-software system).
3.10.1 Computer hardware requirements.
This paragraph shall specify the requirements, if any, regardingcomputer hardware that must be used by, or incorporated into,the system. The requirements shall include, as applicable, numberof each type of equipment, type, size, capacity, and other requiredcharacteristics of processors, memory, input/output devices, auxiliarystorage, communications/network equipment, and other requiredequipment.
This paragraph shall specify the requirements, if any, on thesystem's computer hardware resource utilization, such as maximumallowable use of processor capacity, memory capacity, input/outputdevice capacity, auxiliary storage device capacity, and communications/networkequipment capacity. The requirements (stated, for example, aspercentages of the capacity of each computer hardware resource)shall include the conditions, if any, under which the resourceutilization is to be measured.
3.10.3 Computer software requirements.
This paragraph shall specify the requirements, if any, regardingcomputer software that must be used by, or incorporated into,the system. Examples include operating systems, database managementsystems, communications/ network software, utility software, inputand equipment simulators, test software, and manufacturing software.The correct nomenclature, version, and documentation referencesof each such software item shall be provided.
3.10.4 Computer communications requirements.
This paragraph shall specify the additional requirements, if any,concerning the computer communications that must be used by, orincorporated into, the system. Examples include geographic locationsto be linked; configuration and network topology; transmissiontechniques; data transfer rates; gateways; required system usetimes; type and volume of data to be transmitted/received; timeboundaries for transmission/reception/response; peak volumes ofdata; and diagnostic features.
3.11 System quality factors.
This paragraph shall specify the requirements, if any, pertainingto system quality factors. Examples include quantitative requirementsconcerning system functionality (the ability to perform all requiredfunctions), reliability (the ability to perform with correct,consistent results -- such as mean time between failure for equipment),maintainability (the ability to be easily serviced, repaired,or corrected), availability (the ability to be accessed and operatedwhen needed), flexibility (the ability to be easily adapted tochanging requirements), portability of software (the ability tobe easily modified for a new environment), reusability (the abilityto be used in multiple applications), testability (the abilityto be easily and thoroughly tested), usability (the ability tobe easily learned and used), and other attributes.
3.12 Design and construction constraints.
This paragraph shall specify the requirements, if any, that constrainthe design and construction of the system. For hardware-softwaresystems, this paragraph shall include the physical requirementsimposed on the system. These requirements may be specified byreference to appropriate commercial or military standards andspecifications. Examples include requirements concerning:
a. Use of a particular system architecture or requirements onthe architecture, such as required subsystems; use of standard,military, or existing components; or use of Government/acquirer-furnishedproperty (equipment, information, or software)
b. Use of particular design or construction standards; use ofparticular data standards; use of a particular programming language;workmanship requirements and production techniques
c. Physical characteristics of the system (such as weight limits,dimensional limits, color, protective coatings); interchangeabilityof parts; ability to be transported from one location to another;ability to be carried or set up by one, or a given number of,persons
d. Materials that can and cannot be used; requirements on thehandling of toxic materials; limits on the electromagnetic radiationthat the system is permitted to generate
e. Use of nameplates, part marking, serial and lot number marking,and other identifying markings
f. Flexibility and expandability that must be provided to supportanticipated areas of growth or changes in technology, threat,or mission
3.13 Personnel-related requirements.
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 willuse or support the system. Examples include requirements for thenumber of work stations to be provided and for built-in help andtraining features. Also included shall be the human factors engineeringrequirements, if any, imposed on the system. These requirementsshall include, as applicable, considerations for the capabilitiesand limitations of humans, foreseeable human errors under bothnormal and extreme conditions, and specific areas where the effectsof human error would be particularly serious. Examples includerequirements for adjustable-height work stations, color and durationof error messages, physical placement of critical indicators orbuttons, and use of auditory signals.
3.14 Training-related requirements.
This paragraph shall specify the system requirements, if any,pertaining to training. Examples include training devices andtraining materials to be included in the system.
3.15 Logistics-related requirements.
This paragraph shall specify the system requirements, if any,concerned with logistics considerations. These considerationsmay include: system maintenance, software support, system transportationmodes, supplysystem requirements, impact on existing facilities,and impact on existing equipment.
3.16 Other requirements.
This paragraph shall specify additional system requirements, ifany, not covered in the previous paragraphs. Examples includerequirements for system documentation, such as specifications,drawings, technical manuals, test plans and procedures, and installationinstruction data, if not covered in other contractual documents.
3.17 Packaging requirements.
This section shall specify the requirements, if any, for packaging,labeling, and handling the system and its components for delivery.Applicable military specifications and standards may be referencedif appropriate.
3.18 Precedence and criticality of requirements.
This paragraph shall specify, if applicable, the order of precedence,criticality, or assigned weights indicating the relative importanceof the requirements in this specification. Examples include identifyingthose requirements deemed critical to safety, to security, orto privacy for purposes of singling them out for special treatment.If all requirements have equal weight, this paragraph shall sostate.
4. Qualification provisions.
This section shall define a set of qualification methods and shallspecify for each requirement in Section 3 the method(s) to beused to ensure that the requirement has been met. A table maybe used to present this information, or each requirement in Section3 may be annotated with the method(s) to be used. Qualificationmethods may include:
a. Demonstration: The operation of the system, or a part of thesystem, that relies on observable functional operation not requiringthe use of instrumentation, special test equipment, or subsequentanalysis.
b. Test: The operation of the system, or a part of the system,using instrumentation or other special test equipment to collectdata for later analysis.
c. Analysis: The processing of accumulated data obtained fromother qualification methods. Examples are reduction, interpolation,or extrapolation of test results.
d. Inspection: The visual examination of system components, documentation,etc.
e. Special qualification methods. Any special qualification methodsfor the system, such as special tools, techniques, procedures,facilities, acceptance limits, use of standard samples, preproductionor periodic production samples, pilot models, or pilot lots.
5. Requirements traceability.
For system-level specifications, this paragraph does not apply.For subsystem-level specifications, this paragraph shall contain:
a. Traceability from each subsystem requirement in this specificationto the system requirements it addresses. (Alternatively, thistraceability may be provided by annotating each requirement inSection 3.)
Note: Each level of system refinement may result in requirementsnot directly traceable to higher-level requirements. For example,a system architectural design that creates two subsystems mayresult in requirements about how the subsystems will interface,even though these interfaces are not covered in system requirements.Such requirements may be traced to a general requirement suchas 'system implementation' or to the system design decisionsthat resulted in their generation.
b. Traceability from each system requirement that has been allocatedto the subsystem covered by this specification to the subsystemrequirements that address it. All system requirements allocatedto the subsystem shall be accounted for. Those that trace to subsystemrequirements contained in IRSs shall reference those IRSs.
6. Notes.
This section shall contain any general information that aids inunderstanding this document (e.g., background information, glossary,rationale). This section shall contain an alphabetical listingof all acronyms, abbreviations, and their meanings as used inthis document and a list of any terms and definitions needed tounderstand this document.
A. Appendixes.
Appendixes may be used to provide information published separatelyfor convenience in document maintenance (e.g., charts, classifieddata). As applicable, each appendix shall be referenced in themain body of the document where the data would normally have beenprovided. Appendixes may be bound as separate documents for easein handling. Appendixes shall be lettered alphabetically (A, B,etc.).