На что я смотрю при оценке качества работы кандидата:

1. Сделана попытка сформулировать цели доработки, выраженные в бизнес-показателях;
2. Описана ролевая модель (какие категории пользователей будут пользоваться модулем);
3. Задан контекст и объём программного модуля, через:
   — Диаграмму экосистемы и/или
   — Контекстную диаграмму и/или
   — Диаграмму юскейсов и/или
   — Реестр юксейсов и/или
   — Реестр функциональных требований и/или
   — Карту пользовательских историй;
4. Если используются функциональные требования, то они:
   — Атомарны;
   — Имеют уникальные идентификаторы;
   — Понятно действующее лицо, выполняющее/запускающее функцию (система или конкретная роль);
   — Понятен результат функции;
   — Указаны входные и выходные атрибуты функции или даны ссылки на словарь данных;
5. Поведение программного модуля проиллюстрировано через:
   — Диаграмму состояний и/или
   — Сквозной неформальный сценарий использования
   (регламент бизнес-процесса) и/или
   — Сценарии использования (use cases) и/или
   — User stories и BDD-сценарии;
6. Структурные аспекты программного модуля описаны через
   — Диаграмму данных и/или
   — Словарь данных и/или
   — Диаграмму навигации;
7. Поведение и структура проиллюстрированы макетами интерфейса;
8. Нефункциональные свойства программного модуля описаны через:
   — Ограничения (Совместимость по ОС/ПО, протоколы взаимодействия со смежными модулями/системами, разрешение экрана);
   — Атрибуты качества, как минимум: производительность, надёжность.
9. Бизнес-правила описаны отдельно, со ссылками на них из ФТ или юскейсов.
10. По всем неоднозначным вопросам выше составлен перечень открытых вопросов.