SRS Template My Program name Software Requirements Specification Document approval     Second Name     Date    Sign Prepared             Verified             Quality control             Approved             Access list Company    Second name    Position    For approval/ Information                                         Change history Version    Date    Author    Description    Section                 FUN Document information Date of creation     File name         Location     Number of pages     Introduction Goals This document aims to provide a complete description of the system software requirements. It fully describes the external behavior of the application or the subsystems described. It also describes non-functional requirements, design constraints, and other factors necessary to provide a complete and comprehensive description of software requirements. An application or product is described whose functionality will be described in the SRS.  For example: This document describes the functionality of a centralized program for monitoring remote devices. The customer needs to provide general centralized control of all monitored areas, as well as provide multi-level remote access for control and monitoring. Links  The submitted document refers to the following documents. ● Reductions ● Document structure  The first section describes functional and non-functional requirements. The second section comprehensively describes the use cases in terms of how the model is structured into groups and what are the use cases for the participants in the model. Section 1: Requirements Overview Introduction This section describes the various requirements (functional and non-functional) Content This section contains the following topics Topic     See page Requirements type     Functional requirement list     Non-Functional requirement list     Requirements type Definitions  Requirement is defined as "a state or opportunity that a system must conform to." Functional requirement define the actions that the system should be able to perform without taking physical constraints into account. They are often best described in the use-case model and use cases. The functional requirements thus determine the input and output behavior of the system. Requirements that are not functional are sometimes referred to as non-functional requirements. Many requirements are not functional and only describe system attributes or features of the system's environment. FURPS+ There are many different kinds of requirements. One way to categorize them is described as FURPS+ model, using an acronym to describe the main categories and subcategories of requirements, as shown below. ●Functionality, ●Usability, ●Reliability, ●Performance,  ●Supportability. "+" also helps you remember to include requirements such as ●design constraints, ●requirements for interfaces, ●physical requirements. Functionality (FUN)  Functional requirements may include: sets of functions, possibilities, security. Usability (USA) Usability requirements can include subcategories such as: human factor, aesthetics, consistency of the user interface, online and context-sensitive help, masters and agents, user documentation, educational materials. Reliability (REL) Reliability requirements to be considered: availability (percentage of available time, operating hours, maintenance access, ...) frequency / degree of failure rate, recover-ability, predictability, accuracy, mean time between failures (MTBF). Performance (PER) Performance requirements impose conditions on functional requirements. For example, for a specified action, they can specify performance parameters for: throughput (for example, transactions per second), response time, recovery time, use of resources (memory, disk, processor, ...). Supportability (SUP) Maintainability requirements may include: testability, extensibility, adaptability, maintainability, compatibility, configure-ability, ease of maintenance, install-ability, localization (internationalization). Design requirements (DES) Design requirements, often referred to as design constraints, indicate or constrain the design of a system. This section should indicate any design constraints in the system under construction. Design constraints are design considerations that are introduced and must be followed. Examples include programming languages, software development process requirements, prescribed use of development tools, architectural and design constraints, purchased components, class libraries, and more. Interface requirements (INT) This section defines the interfaces that the application must support. It should contain adequate specifications, protocols, ports and logical addresses, etc., such that the program can be designed and tested to meet the interface requirements. Interface requirements can be divided into: User interface (user interfaces to be implemented with software) Hardware interface (hardware interfaces that must be supported by the software, including logical structure, physical addresses and expected behavior, etc.) Programming interface (programmatic interfaces for other system components. They can be purchased, components reused from another application, components developed for a subsystem that is outside the scope of this project, but with which this application must interact). Hardware requirements (HAR) Hardware requirements define the physical characteristics that a system must have; for example: material, the form, the size, the weight. This type of requirement can be used to represent hardware requirements such as the required physical network configuration. Applied standards (STD) This section describes any applicable standards and specific clauses of such standards that apply to the described system. For example legal, regulatory, industry standards, quality standards, compatibility, localization, compliance with operating systems, etc. Functional requirements list Introduction  Functional requirements define the actions that the system must be able to perform without taking physical constraints into account. They are often best described in the use-case model and use cases. The functional requirements thus determine the input and output behavior of the system. List of functional requirements Each defined functional requirement is assigned a unique key "FUN-nn", where nn is a sequential number that identifies the functional requirement. The table below lists all functional requirements: Functional requirement identifier     Description FUN-01    Supports up to 16 video input streams from H.264 / MJPEG HD IP video cameras. FUN-02     Output of video images and audio signals with the possibility of local recording to the archive. FUN-03     FUN-04     FUN-05     FUN-06     FUN-07     FUN-08     FUN-09     Non-functional requirements list Introduction Non-functional requirements describe only the attributes of the system or features of the environment of the system. Each specific non-functional requirement is assigned a unique key "XXX-nn", where XXX is the abbreviation of the requirement type, nn is a sequence number that identifies the non-functional requirement. Usability requirements (USA) The table below lists all of the usability requirements: Usability requirement identifier     Description USA-01    Split screen into 1, 4, 8, 16 cameras. USA-02    Grab - move the position of the camera windows. USA-03     USA-04     USA-05     Reliability (REL) The table below lists all the reliability requirements: Reliability requirement identifier     Description REL-01     REL-02     REL-03         Performance (PER) The table below lists all the performance requirements: Performance requirement identifier     Description PER-01             Supportability (SUP) The table below lists all of the supportability requirements: Supportability requirement identifier     Description SUP-01     SUP-02     SUP-03     SUP-04     SUP-05     SUP-06     SUP-07       Design requirements (DES) The table below lists all design requirements: Design requirement identifier     Description DES-01     DES-02     DES-03     DES-04     Interface requirements (INT) The table below lists all the interface requirements: Interface requirements identifier     Description INT-01     INT-02     INT-03     INT-04     INT-05     INT-06     INT-07     INT-08     Hardware requirements (HAR) The table below lists all hardware requirements: Hardware requirements identifier     Description HAR-01     HAR-02     HAR-03     HAR-04     Compatibility (COM) The table below lists all compatibility requirements: Compatibility requirements identifier     Description COM-01     COM-02     COM-03     COM-04     Security (SEC) The table below lists all the security requirements: Security requirements identifier     Description SEC-01    Differentiation of user access rights. SEC-02   SEC-03     SEC-04     Applied standards (STD) The table below lists all applicable standards: Standards requirement identifier     Description STD-01     STD-02     STD-03     STD-04     Use cases For example: The program can be used both by students in the learning process and by professional security organizations to provide centralized control of remote devices. ![file](62bbfd6dd25e063422c11f79/SRS_template.docx)