🧾 SRS вручную?

Сегодня есть специализированные инструменты для управления требованиями: они помогают создавать требования, связывать их с функциями безопасности, тестами, изменениями и замечаниями, формировать матрицы прослеживаемости.

В нашей работе ещё встречаются проекты, где общие требования и требования безопасности создаются и ведутся вручную — в текстовых редакторах, электронных таблицах или наборе отдельных файлов.

📌 Сам по себе ручной режим не запрещён. ГОСТ Р МЭК 61508 не требует, чтобы SRS/СТБ обязательно создавалась в специализированной системе управления требованиями. Однако стандарт требует, чтобы требования безопасности были определены, проверяемы, согласованы, актуальны и прослеживаемы на протяжении жизненного цикла безопасности.

⚠️ И вот здесь начинаются сложности, которые мы видим достаточно часто при ручном ведении SRS:
➜ документ SRS устарел и не отражает текущую конфигурацию системы;
➜ отсутствуют связи между требованиями, тестами и другими доказательными материалами;
➜ нет понятной иерархии требований;
➜ отсутствует прослеживаемость требований на разных стадиях проекта;
➜ изменения требований не отслеживаются;
➜ разработчик не может ответить на вопрос: "все ли требования взяты в работу?".

✅ SRS можно вести вручную, если есть строгая дисциплина (процедура) управления требованиями, документами и изменениями. Но чем сложнее проект, тем выше вероятность, что ручной режим станет источником ошибок.

🎯 Инструмент управления требованиями сам по себе не обеспечивает функциональную безопасность. Однако отсутствие такого инструмента требует ещё более строгой дисциплины и наличия зрелого процесса менеджмента ФБ (FSM).

❓ А как у вас ведутся требования ФБ — в специализированной системе или вручную? Используете ли отечественные или open-source системы?