IEEE Software Requirements Specifications

SRS should not specify details like partitioning software into modules, allocating functions to modules, describing information/control flow between modules, or choosing data structures. It should focus on what the software should do, not how it should be built.

Project requirements like cost, delivery schedules, development methods, etc., are separate from the software's functionality. They are contractual agreements between customer and supplier, not part of the software's behavioral specification.

The SRS should describe the software product itself, not the process of producing it. Think of it as the user's manual, not the software engineer's instruction manual.

The 'Overall Description' section in the SRS provides context and background for the software's requirements. It sets the stage for understanding the specific requirements that will be defined later.

This subsection of the SRS explains how the software fits into a larger system, if applicable. It identifies any interfaces between the software and other components.

This subsection describes the various functions the software should perform, focusing on what the software does rather than details of how it does it.

This subsection describes the expected users of the software, considering their skills, experience, and how they will interact with the software.

This subsection outlines any restrictions, limitations, or external factors that impact the software's design. For example, hardware constraints, data formats, etc.

This subsection clarifies any assumptions made about the environment, dependencies on other software, or external factors that affect the SRS.

Software will be unacceptable if these requirements are not met.

Requirements that enhance the software, but not crucial for acceptance.

Features that may or may not be valuable and are not essential for acceptance.

A working model of a system used to gather feedback and refine requirements.

Requirements based on experience or knowledge of future events.

Using a prototype to elicit feedback and refine requirements.

The SRS should specify what functions the system performs, on what data, to produce what results, for whom, and at what location.

Design elements that are required as part of the system's functionality.

A requirement specifies an externally visible function or attribute of a system, while design describes a particular subcomponent.

Every requirement limits design choices, but not every requirement is a design element.

A software requirements specification (SRS) is a document that describes the intended functionality and behavior of a software product. It outlines the expectations and requirements of the software from a user perspective, without delving into implementation details.

The SRS should strictly focus on defining what the software should do, avoiding any specifics on how it should be built. This includes details like data structures, module allocations, or flow control.

The SRS should be complete and cover all significant requirements, including functionality, performance, design constraints, attributes, and interface specifications. Any external system requirements should be acknowledged and addressed within the SRS.

A well-written SRS should be unambiguous, meaning each requirement can be interpreted in only one way. This helps avoid confusion and misinterpretations during development.

Consistency in an SRS refers to the absence of conflicting statements or requirements. All requirements should be logically connected and not contradict each other.

The SRS should prioritize requirements based on their importance and stability. This helps developers focus on the most crucial aspects and manage potential changes.

An SRS should be verifiable, meaning you can check if the software meets each specified requirement through testing or other means. This ensures the software fulfills the outlined expectations.

Modifiable means the SRS can be easily updated and changed without causing significant disruption to the document or software development process.

Traceability refers to the ability to follow the connection between requirements and design elements throughout the software development lifecycle. This ensures each requirement is addressed and accounted for in the final product.

This defines the factors required to establish the necessary reliability of the software system at the time of delivery. It is essential for gauging the software's ability to perform its intended functions without failures.

This specifies the factors needed to ensure a defined availability level for the entire system. It covers aspects like system recovery, restarts, and checkpoints, keeping the software accessible and functioning even in the face of unexpected issues.

This specifies the protective measures needed to safeguard the software against unauthorized or accidental access, use, modification, destruction, or disclosure. It might involve encryption, access controls, and logging mechanisms.

This specifies the design features that make the software easy to maintain and modify. This emphasizes attributes like modularity, clear interfaces, and reduced complexity.

This outlines the criteria that make it easy to port the software to different operating systems or machines. It might involve factors like the percentage of code tied to a specific platform, compatible programming languages, and suitable compilers.

A document that outlines the technical and organizational requirements, costs, and schedule for a software product.

The individuals who fund the development of the software and often determine its requirements.

The individuals responsible for creating and delivering the software product.

Those who interact directly with the software, using it to perform their tasks.

The software requirements specification (SRS) describes what the software should do, not how it should be built.

The SRS document should address what the software needs to accomplish, how it interacts with external systems or people, its performance parameters (speed, uptime, etc.), and its overall qualities (reliability, maintainability, etc.).

The SRS should be a collaborative effort, ideally involving both the customer and supplier representatives.

The SRS is not a static document; It evolves as the project progresses and new insights are gained.

Prototyping helps visualize the requirements and gather feedback, allowing the SRS to be more accurate and aligned with user needs.

Include necessary design elements within the SRS without going into excessive detail. The SRS should focus on what the software should do, not how it is built.