Если у разрабатываемой системы есть пользовательский интерфейс, то понять, что спецификация скверная, несложно.
Правило "ноль") После прочтения документа в голове ровный гул. То есть непонятно вообще ничего. И вопросов не возникает.
Теперь более конкретные запахи, которые можно сосканировать с документа, не вчитываясь в детали
1) Не определены рамки системы. Что система делает, какие требования реализует, Сколько у пользовательского интерфейса вообще экранов -- если это не понятно тебе, не будет понятно и разработчику.
2) Структура документа не соответствует структуре интерфейса. то есть - каждому логическому блоку интерфейса (странице, списку, форме) должен соответствовать отдельный раздел с описанием. Если нет -- спецификацией будет сложно пользоваться
3) Хорошо освещено очевидное. То есть "под фонарем ищем, где и так светло". Примеры
- "Нажатие на кнопку ОК закрывает окно"
- "Нажатие на кнопку Отмена отменяет операцию"
- "На форме "Список пользователей" отображен список пользователей"
- "Выпадающий список "Пользователи" должен позволять выбрать пользователя"
4) Нет описания тонкостей.
Например, для списка пользователей
- Есть ли неявные фильтры
- Какая сортировка по умолчанию
- Как выглядит список если ничего не найдено
Для форм
- Каковы правила валидации для каждого элемента
- Как выглядит форма с валидаторами
- Сохраняются ли умолчательные зрачения (и на каком уровне - cookies, профиль пользователя,
Правило "ноль") После прочтения документа в голове ровный гул. То есть непонятно вообще ничего. И вопросов не возникает.
Теперь более конкретные запахи, которые можно сосканировать с документа, не вчитываясь в детали
1) Не определены рамки системы. Что система делает, какие требования реализует, Сколько у пользовательского интерфейса вообще экранов -- если это не понятно тебе, не будет понятно и разработчику.
2) Структура документа не соответствует структуре интерфейса. то есть - каждому логическому блоку интерфейса (странице, списку, форме) должен соответствовать отдельный раздел с описанием. Если нет -- спецификацией будет сложно пользоваться
3) Хорошо освещено очевидное. То есть "под фонарем ищем, где и так светло". Примеры
- "Нажатие на кнопку ОК закрывает окно"
- "Нажатие на кнопку Отмена отменяет операцию"
- "На форме "Список пользователей" отображен список пользователей"
- "Выпадающий список "Пользователи" должен позволять выбрать пользователя"
4) Нет описания тонкостей.
Например, для списка пользователей
- Есть ли неявные фильтры
- Какая сортировка по умолчанию
- Как выглядит список если ничего не найдено
Для форм
- Каковы правила валидации для каждого элемента
- Как выглядит форма с валидаторами
- Сохраняются ли умолчательные зрачения (и на каком уровне - cookies, профиль пользователя,
2 комментария:
ТЗ разные важны, ТЗ разные нужны!
------
В реальности, если предметом разработки является, в том числе, интерфейс, то писать в ТЗ к нему детальные требования не требуется.
Строго говоря - ТЗ это задание на проведение работ. И ничто не мешает указывать что "состав, структура и дизайн GUI должна быть разработана в ходе эскизного проектирования\макетирования\ и доработана по результатам опытной эксплуатации и тп...
А то что ты требуешь, ИМХО, есть ТЗ самого низкого уровня. По сути не ТЗ, а уже, как минимум, полноценный эскизный проект.
Сам посуди. Чтобы описать требования к интерфейсу надо спроектировать как минимум:
1. Информационную модель - состав полей данных
2. Организационную модель - состав пользователей с правами и ролями
3. Модель использования - use-case и тп
И кто и за какие деньги это будет делать? Заказчик это делать не будет -)
А то что Заказчик написал плохое ТЗ, так это фигня. Либо помочь надо любимому партнеру сделать нормальное ТЗ, либо не связыватся с мудаком. Нужное выбирается -)
Терминология :-)
Андюха, ты говоришь о ГОСТовой трактовке ТЗ
А я тут пою о - да - об эскизном проекте. В терминологии RapidSoft - о функциональной спецификации
то есть имеется в виду документ, целью которого является объяснить разработчикам, что должно быть сделано, а тестировщикам - что конкретно надо тестировать
Сейчас поправлю, заменю ТЗ на функциональную спецификацию, чтобы никто не путался :-)
Отправить комментарий