четверг, 19 января 2012 г.

Запах скверной спецификации

Если у разрабатываемой системы есть пользовательский интерфейс, то понять, что спецификация скверная, несложно.

Правило "ноль") После прочтения документа в голове ровный гул. То есть непонятно вообще ничего. И вопросов не возникает.

Теперь более конкретные запахи, которые можно сосканировать с документа, не вчитываясь в детали

1) Не определены рамки системы. Что система делает, какие требования реализует, Сколько у пользовательского интерфейса вообще экранов -- если это не понятно тебе, не будет понятно и разработчику.

2) Структура документа не соответствует структуре интерфейса. то есть - каждому логическому блоку интерфейса (странице, списку, форме) должен соответствовать отдельный раздел с описанием. Если нет -- спецификацией будет сложно пользоваться

3) Хорошо освещено очевидное. То есть "под фонарем ищем, где и так светло". Примеры

- "Нажатие на кнопку ОК закрывает окно"
- "Нажатие на кнопку Отмена отменяет операцию"
- "На форме "Список пользователей" отображен список пользователей"
- "Выпадающий список "Пользователи" должен позволять выбрать пользователя"

4) Нет описания тонкостей. 

Например, для списка пользователей

- Есть ли неявные фильтры
- Какая сортировка по умолчанию
- Как выглядит список если ничего не найдено

Для форм

- Каковы правила валидации для каждого элемента
- Как выглядит форма с валидаторами
- Сохраняются ли умолчательные зрачения (и на каком уровне - cookies, профиль пользователя, 

2 комментария:

Андрей Радосельский комментирует...

ТЗ разные важны, ТЗ разные нужны!
------
В реальности, если предметом разработки является, в том числе, интерфейс, то писать в ТЗ к нему детальные требования не требуется.

Строго говоря - ТЗ это задание на проведение работ. И ничто не мешает указывать что "состав, структура и дизайн GUI должна быть разработана в ходе эскизного проектирования\макетирования\ и доработана по результатам опытной эксплуатации и тп...

А то что ты требуешь, ИМХО, есть ТЗ самого низкого уровня. По сути не ТЗ, а уже, как минимум, полноценный эскизный проект.

Сам посуди. Чтобы описать требования к интерфейсу надо спроектировать как минимум:
1. Информационную модель - состав полей данных
2. Организационную модель - состав пользователей с правами и ролями
3. Модель использования - use-case и тп

И кто и за какие деньги это будет делать? Заказчик это делать не будет -)

А то что Заказчик написал плохое ТЗ, так это фигня. Либо помочь надо любимому партнеру сделать нормальное ТЗ, либо не связыватся с мудаком. Нужное выбирается -)

Yury Skaletskiy комментирует...

Терминология :-)

Андюха, ты говоришь о ГОСТовой трактовке ТЗ
А я тут пою о - да - об эскизном проекте. В терминологии RapidSoft - о функциональной спецификации

то есть имеется в виду документ, целью которого является объяснить разработчикам, что должно быть сделано, а тестировщикам - что конкретно надо тестировать

Сейчас поправлю, заменю ТЗ на функциональную спецификацию, чтобы никто не путался :-)