Answer.

SRS is a structured document that outlines all requirements for the developed system. Its purpose is to convey business expectations as clearly and completely as possible into the language of the project team. The main sections include:

1. Introduction (goals, scope, terminology)
2. Product description and business context
3. User descriptions and their roles
4. Functional requirements (use cases, user stories)
5. Non-functional requirements (security, performance, usability)
6. Constraints
7. Interfaces
8. External dependencies
9. Acceptance criteria for requirements
10. Glossary of terms

Key features:

• The SRS contains both functional and non-functional requirements.
• Requirements are formulated clearly, with minimal ambiguity.
• The SRS must reflect use cases, constraints, and criteria for successful outcomes.

To control completeness and quality, the analyst uses validation checklists, templates, IEEE 830 standards, and regular agreements with key stakeholders.

Tricky Questions.

Is it sufficient to describe only user stories for a complete SRS?

No. User stories demonstrate the functional side but do not cover non-functional requirements, constraints, interfaces, exception scenarios, and acceptance criteria.

Can different terms be used for the same entity in the document?

No. It is essential to maintain consistency in terminology: a glossary of terms is created and cross-review of the document is conducted.

Should the SRS include requirements for security and performance?

Yes. Non-functional requirements are critically important; their absence can lead to technical debt or inability to operate the system.

Common Mistakes and Anti-Patterns

• Insufficient detail in requirements, lack of examples and acceptance criteria.
• Using ambiguous phrases: "fast", "convenient", "reliable" without numerical specifications.
• Ignoring non-functional requirements.

Real-life Example

Negative Case

The SRS is written solely based on user stories, forgetting performance and security requirements.

Pros:

• Fast preparation of documentation.

Cons:

• The project failed a security audit and cannot handle the required number of simultaneous users.

Positive Case

The SRS covers the complete list of necessary attributes – functionality, non-functional requirements, acceptance criteria, and glossary.

Pros:

• Preparedness for audits, clear requirements for all participants, high manageability of changes.

Cons:

• Increased effort in preparing and agreeing on documentation.