Из чего состоит Software Requirements Specification (SRS)
Что проверяют
Знаете ли вы, как устроен документ с требованиями и зачем нужен каждый его раздел. Следом часто спрашивают, как вы пишете нефункциональные требования и чем SRS отличается от пользовательских историй.
Как отвечать
Классическая структура описана в IEEE 830, на смену которому пришёл стандарт ISO/IEC/IEEE 29148. В российских проектах похожую роль играют ГОСТ 34.602 (техническое задание на автоматизированную систему) и ГОСТ 19.201. Каркас SRS:
- введение: цель документа и его читатели, границы системы (что входит и что нет), глоссарий, ссылки на другие документы;
- общее описание: место продукта среди других систем, основные функции, классы пользователей, ограничения (законодательство, платформа, интеграции), допущения и зависимости;
- внешние интерфейсы: пользовательские, программные (API других систем), аппаратные и коммуникационные;
- функциональные требования: что система делает, по функциям, сценариям использования или ролям. Каждое требование с идентификатором;
- нефункциональные требования: производительность, надёжность и доступность, безопасность, сопровождаемость, переносимость. Каждое должно быть измеримым: не «быстро», а «95% запросов поиска выполняются быстрее 500 мс при заданной нагрузке»;
- приложения: модели данных, диаграммы, матрица трассировки требований к бизнес-целям и тестам.
Назовите и свойства хорошего требования: корректное, однозначное, полное, непротиворечивое, проверяемое, трассируемое, с приоритетом.
В продуктовой разработке полный SRS встречается редко, требования живут в Confluence и Jira как истории с критериями приёмки. Но в заказной разработке, госпроектах и интеграциях документ остаётся основой договора и приёмки.
Где спотыкаются
Пишут требования, которые нельзя проверить. «Удобный интерфейс» и «высокая надёжность» тестировщик не сможет ни принять, ни отклонить.
Смешивают требования с решением: вместо «система хранит историю изменений заказа» описывают таблицы и выбранный фреймворк.
Не фиксируют границы системы. Без явного списка того, что не входит в объём, каждое обсуждение превращается в спор о новых функциях.