3 pages

3.2.1.3 Hardware interfaces

This should specify the logical characteristics of each interface between the software product and the hardware components of the system This includes configuration characteristics (number of ports, instruction Sets, etc.) It also covers such matters as what devices are to be supported, how they are to be supported, and protocols. For example, terminal support may specify full Screen support as opposed to line by line.

3.2.1.4 Software interfaces

This should specify the use of other required software products (for example, a data management system, an operating system, or a mathematical package), and interfaces with other application systems (for example, the linkage between an accounts receivable system and a general ledger system). For each required software product, the following should be provided:

a)      Name: Teacher's Desktop

b)      Mnemonic

c)      Specification number: N/A

d)      Version number: 1.1.1

e)      Source

For each interface, the following should be provided.

a)      Discussion of the purpose of the interfacing software as related to this software product.

b)      Definition of the interface in terms of message content and format. It is not necessary to detail any well-documented interface, but a reference t~ the document defining the interface is required.

3.2.1.5 Communications interfaces

This should specify the various interfaces to communications such as local network protocols, etc.

3.2.1.6 Memory constraints

This should specify any applicable characteristics and limits on primary and secondary memory.

3.2.1.7 Operations

This should specify the normal and special operations required by the user such as

a)      The various modes of operations in the user organization; for example user-initiated operations

b)      Periods of interactive operations and periods of unattended operations

c)      Data processing support functions

d)      Backup and recovery operations

NOTE - This is sometimes specified as part of the User Interfaces section.

3.2.1.9 Site adaptation requirements

This could

a)      Define the requirements for any data or initialization sequences that are specific to a given site, mis­sion, or operational mode, for example, grid values, safety limits, etc.

b)      Specify the Site or mission-related features that should be modified to adapt the software to a partic­ular installation.

• There is not site because we are using Microsoft cloud services

3.2.2 Product functions (2.2 of the SRS)

This subsection of the SRS should provide a summary of the major functions that the software will perform. For example, an SRS for an accounting program may use this part of  address customer account maintenance, customer statement, and invoice preparation without mentioning the vast amount of detail that each of those functions requires.

Sometimes the function summary that is necessary for this pan can be taken directly from the section of the higher level specification (if one exists) that allocates particular functions to the software product. Note that for the sake of clarity:

a)      The functions should he organized in a way that makes the list of functions understandable to the customer or to anyone else reading the document for the first time.

b)      Textual or graphical methods can be used to show the different functions and their relationships. Such a diagram is not intended to show a design of a product but simply shows the logical relationships among variables.

3.2.3 User characteristics (2.3 of the SRS)

This subsection of the SRS should describe those general characteristics of the intended users of the product including educational level, experience, and technical expertise. It should not he used to state specific requirements but rather should provide the reasons why certain specific requirements are later specified in Section 3 of the SRS.

• Teacher

• Student

• Admin

3.2.4 Constraints (2.4 of the SRS)

This subsection of the SRS should provide a general description of any operations. These include:

a)      Regulatory policies

b)      Hardware limitations (for example, signal timing requirements)

c)      Interfaces to other applications

d)      Parallel operation

f)       Control functions:

g)      Higher-order language requirements

h)      Signal handshake protocols (for example, XON-XOFF, ACK-NACK)

i)      Reliability requirements

j)      Criticality of the application

k)     Safety and security considerations

3.2.5 Assumptions and dependencies (2.5 of the SRS}

This subsection of the SRS should list each of the factors that affect the requirements stated in the SRS. These factors are not design constraints on the software but are, rather, any changes to them that can affect the requirements in the SRS. For example, an assumption- may be that a specific operating system will be available on the hardware designated for the software product. If, in fact, the operating system is not available, the SRS would then have to change accordingly.

3.2.6 Apportioning of requirements (2.6 of the SRS)

This subsection of the SRS should identify that may be delayed until future versions of the system.