Требования и их сбор
Требования — то, ради чего существует системный аналитик. Ошибка здесь дороже любой другой: неизмеримое или двусмысленное требование тянет переделку через анализ, разработку и тестирование. Поэтому требования собирают методично, проверяют по критериям и ведут по жизненному циклу до проверенной реализации.
Ловушки называем сразу: функциональные путают с нефункциональными, «недвусмысленность» подменяют длиной, нефункциональное требование оставляют без измеримой цели, а сам аналитик сводится то к тестировщику, то к «пересыльщику пожеланий». Полная карта — в слоях ниже.
Карта темы
- Роль системного аналитика — мост между бизнесом и разработкой и с кем он взаимодействует.
- Виды требований — бизнес, функциональные, нефункциональные и пользовательские требования.
- Нефункциональные требования — свойства системы (доступность, производительность, безопасность) и их измеримость.
- Методики сбора требований — интервью, анкетирование, анализ документов и внутренний против внешнего заказчика.
- Критерии качества требования — недвусмысленность, полнота, проверяемость, трассируемость.
- Жизненный цикл требования — от бизнес-потребности через анализ и реализацию до проверки, с трассировкой.
Частые ошибки и ловушки
| Ошибка | Последствие |
|---|---|
| Путать функциональные (что делает) и нефункциональные (как хорошо) | Свойства системы теряются, ими никто не владеет |
| Заявлять НФТ без измеримой цели | Требование нельзя проверить и приёмка невозможна |
| Считать бизнес-требования низкоуровневой деталью | Теряются рамки и обоснование проекта |
| Путать недвусмысленность с длиной | Длинное, но двусмысленное требование ломает реализацию |
| Считать, что требование нельзя тестировать | Ошибки всплывают только в коде, поздно и дорого |
| Свести роль аналитика к тестировщику или «пересыльщику» | Пропадает анализ, декомпозиция и постановка задач |
Значение для собеседований
Это ядро собеседования системного аналитика. Проверяют не заучивание списков, а умение отличить свойство от функции, сделать требование измеримым и провести его по циклу. Кандидат, который на «какие НФТ ставили» отвечает измеримыми целями («доступность 99.9%», «отклик < 200 мс»), сразу опережает того, кто называет «быстро и надёжно».
Что обычно проверяют:
- Виды требований и разницу функциональных и нефункциональных.
- Критерии качества (недвусмысленность, проверяемость, трассируемость).
- Методики сбора и различие внутреннего и внешнего заказчика.
- Жизненный цикл требования и то, что требования сами тестируются, а не только код.
Типичный неверный ответ: «требования нельзя протестировать — тестируют только код». На самом деле требования проверяют послойно: аналитик — по критериям качества, команда — на общее понимание, QA — по сценариям, выведенным из требований.