Software Requirements Definition
The software requirements definition document should be a functional requirements definition for the software. It should be based on the business functional requirements definition document. The business functional requirements definition document must be formally documented and signed by the business sponsors of the project. The software requirements definition document must be formally documented and signed by project stakeholders. No software coding beyond conceptual coding for demonstration purposes only or to test whether a method required (determine project feasability) should be permitted until the software requirements definition document is formally approved.
Without a software requirements definition document approved, the project risk is extremely high and the project sponsors and stakeholders must accept the risk and the responsibility when (not if) software does not perform the expected function.
The software requirements are tied to the required business functionality. The first step in creating the software requirements definition is to define what the business requires the application or system to do. See the document titled Project Requirements Gathering for information about determining business and functional requirements.
Software requirements include the following categories and specifics:
Data security categorizations - How data is categorized according to security needs such as confidentiality, integrity, and availability. How the data is categorized determines how it should be stored and transmitted.
Data encryption for stored sensitive data must be implemented.
Data encryption for transmitted sensitive data must be implemented.
Data encryption/hashing/truncation for account information such as passwords during storage must be implemented.
Data encryption/hashing for account information such as passwords during transmission must be implemented.
For internet and intranet applications, HTML commands should be used to tell the user browser not to cache pages with sensitive data or passwords using the following:
Access controls - Users must not be able to gain access to data or modify data without authority.
The <META HTTP-EQUIV="Pragma" CONTENT="no-cache"> command to tell the browser not to cache the page.
Use the HTML expires command to indicate the page is already expired which should tell the browser to delete the page.
Role based access - Users should have privileges based on roles or levels and only access to the data required. Users cannot view data in other business units even if they have the proper security level.
User group support - The software must support use of user groups to help control permissions.
Password controls including minimum password complexity rules, maximum password age, and minimum password age must be implemented.
Account lockout controls must exist to prevent brute force attacks against accounts.
Privilege control - The software must consider the part of access control dealing with the user's ability to use privileges such as reading, writing, and modifying files and directories. This includes the users privileges to modify permissions or attributes of other objects such as giving another user access to other files, changing their group, deleting them, or adding users.
Logging - The system ands/or software must provide logging of records and changes including (helps ensure data integrity):
Change of data security level.
Change of data from one functional area to another.
Change of user security access level.
Change of user functional area access either removed or added.
Adding a user to a group or removing a user from a group.
User access of any sensitive data.
User modification to data.
All logs must contain a time and date stamp.
System logs must be protected from users who do not have privileges to view them
The design must not rely upon Windows File Sharing or drive mapping for client access to information or for clients to provide information.
Quality assurance must be part in the project including:
Checks for buffer overflow errors.
Checking of user input to be sure it does not contain hostile content such as an attempt to perform an SQL injection or email injection attack.
Checking of output to the user to be sure it does not contain information that could be used to attack a user (in the event your database has been modified by an unauthorized third party) to prevent liability.
Configuration files and library files should be checked when loaded by the program to be sure they are legitimate and were not modified by a third party.
The program should ensure that modification of environment variables or file names will not cause substitute files to be loaded in error by the program.
Assurance that the program is prepared for the following errors:
Coding on internet applications to prevent unauthorized cookie access including:
File access failure.
Registry access failure.
Database access failure.
One or more configuration files are not available.
A library file is not available.
Use of DOMAIN and PATH attributes to restrict cookie access.
Use of the HTTPOnly attribute to increase security of Internet Explorer and other browsers in the future - Indicates that the cookie can only be sent to the server that it originated from.
All code must comply with the software standards specification.
After the software requirements are defined, a design document should be created which defines the plan for how the software will be designed to meet the requirements. The design document should be reviewed to determine whether it satisfies the requirements and whether the design algorithm(s) can be improved. This document does not discuss the software design documentation in depth.