Спецификации и моделирование
Аналитик превращает размытые пожелания в артефакты, по которым команда строит систему без домыслов. Эта тема — про три языка такой формализации: текст (требования и спецификации), картинку (диаграммы UML) и строгий контракт (SOAP/XML, который до сих пор жив в enterprise). Хорошее требование однозначно, атомарно и проверяемо; хорошая диаграмма экономит страницу прозы; хороший контракт не даёт двум системам разойтись в понимании формата.
Разберём, как написать требование, которое не порождает вопросов разработчиков; чем user story отличается от use case и от SRS; когда диаграмма побеждает текст и какую именно рисовать; и почему банки и госсектор всё ещё держатся за SOAP. По пути назовём ловушки собеседований: «нефункциональное требование — формальность», дробление истории по слою архитектуры, путаница агрегации и композиции, вера в то, что XSD описывает JSON. Полная карта — в слоях ниже.
Карта темы
- Спецификации — функциональные и нефункциональные требования, критерии хорошего требования, user story и критерии приёмки, use case, структура SRS, трассируемость, приоритизация по MoSCoW, ТЗ/ЧТЗ.
- Диаграммы UML — какие диаграммы рисует аналитик и когда: use-case, class, sequence, activity, state, component/deployment; ER для данных; BPMN для процессов; когда картинка лучше прозы.
- SOAP и XML — конверт SOAP, контракт WSDL, валидация по XSD, namespaces, SOAP против REST, XML против JSON и где SOAP всё ещё уместен.
Частые ошибки и ловушки
| Ошибка | Последствие |
|---|---|
| Писать «система должна работать быстро» | Требование непроверяемо; QA нечего проверять, а спор о «быстро» уходит в прод |
| Считать нефункциональные требования формальностью | Пропущенные лимиты нагрузки и SLA всплывают отказом под пиком |
| Дробить user story по слою (UI → бэкенд → БД) | Ни один срез не поставляет ценность и не тестируется отдельно |
| Путать user story, use case и SRS | Не тот уровень детализации: то мелко, то на 200 страниц |
| Путать агрегацию (пустой ромб) и композицию (закрашенный) | Неверная модель удаления: части либо переживают целое, либо гибнут с ним |
Считать XSD описанием JSON, а REST — протоколом как SOAP | Неверно выбранный инструмент валидации и контракта интеграции |
Значение для собеседований
Тему спрашивают, чтобы проверить, умеете ли вы формализовать систему так, чтобы её поняли и разработчик, и QA, и заказчик. Кандидат, который формулирует требование через «наблюдаемый и измеримый результат» и рисует правильную диаграмму под задачу, сразу опережает того, кто пересказывает шаблоны наизусть.
Что обычно проверяют:
- Разницу функциональных и нефункциональных требований и признаки хорошего требования (однозначное, атомарное, тестируемое).
- Отличие user story от use case и когда пишут SRS или ТЗ/ЧТЗ вместо бэклога.
- Какие диаграммы UML аналитик рисует и когда диаграмма понятнее текста.
- Устройство SOAP-сообщения, роль WSDL и XSD и когда SOAP всё ещё предпочитают REST.
Типичный неверный ответ: «требование — это когда написано, что система должна делать». На деле требование бесполезно, пока его нельзя проверить: без измеримого критерия приёмки «должна» превращается в спор на демо, а не в зелёный тест.