Комментарии 12
Все прекрасно. Живых картинок только много. Не установлены ограничения и требования к производительности. Но это тренд нашего времени — без видео современным сапиенсам «не заходит». За статью спасибо!
Хорошая статья, жаль не могу плюсануть. Подпишусь, почти, под каждым словом. Собственно, мы аналогично подходим. А какие метрики могут быть для оценки качества проработки (особенно интересует стадия "как?" так как приходится много работать с заказчиком)?
Заметил, что на средних проектах по созданию веб-приложения, время разработки ТЗ примерно равно времени непосредственной разработки.
Спасибо за комментарий.
Метрики — это отдельная тема.Честно говоря, с централизованной и адекватной оценкой качества аналитики я не сталкивалась. Качество своей работы отслеживаю по % вопросов/переделок/багов, связанных с аналитикой.
Вообще требования должны быть:
У Вигерса это глава «Пишем идеальные требования».
По поводу распределения времени у меня, кстати, схожие ощущения. Но вот если убрать/сильно сократить этап ТЗ — время разработки возрастает обычно больше, чем в 2 раза, а количество попоболей по экспоненте.
Метрики — это отдельная тема.Честно говоря, с централизованной и адекватной оценкой качества аналитики я не сталкивалась. Качество своей работы отслеживаю по % вопросов/переделок/багов, связанных с аналитикой.
Вообще требования должны быть:
- полными
- корректными
- осуществимыми
- необходимыми
- приоритизированными
- недвусмысленными
- проверяемыми
- согласованными и отслеживаемыми (в рамках набора)
У Вигерса это глава «Пишем идеальные требования».
По поводу распределения времени у меня, кстати, схожие ощущения. Но вот если убрать/сильно сократить этап ТЗ — время разработки возрастает обычно больше, чем в 2 раза, а количество попоболей по экспоненте.
Отличная статья, но живые картинки очень отвлекают от чтения. Сложно сфокусироваться на статическом тексте, когда рядом что-то мельтешит перед глазами. Надеюсь, я не один такой.
У меня сложилось впечатление, что в последовательности шагов-вопросов есть ошибка. Будто бы автор взяла на вооружение подход Impact Mapping, но спутала порядок в алгоритме.
В примере с уровнями требований я также вижу неточности:
1. Всё перечисленное ниже — разные формулировки одного функционального требования про прикрепление файла с фото к анкете.
2. Это также функциональное требование, в которое, впрочем, зачем-то замешан кусок дизайна про БД.
В примере с уровнями требований я также вижу неточности:
1. Всё перечисленное ниже — разные формулировки одного функционального требования про прикрепление файла с фото к анкете.
Анкета должна содержать файл с фото, так как фото необходимо при оформлении документов
… у пользователя должна быть возможность прикрепить фото к анкете
система должна иметь функционал прикрепления фото к анкете
2. Это также функциональное требование, в которое, впрочем, зачем-то замешан кусок дизайна про БД.
Будем хранить все фото в формате base64 в отдельной таблице в БД
Подскажите, а на чем основывается Ваш комментарий?
Информация в посте основывается на теории разработки требований, в т.ч. указанной там книге Вигерса.
О терминах, конечно, бесполезно спорить, но называть требования к данным «функциональными» — это совсем неправильно.
Информация в посте основывается на теории разработки требований, в т.ч. указанной там книге Вигерса.
О терминах, конечно, бесполезно спорить, но называть требования к данным «функциональными» — это совсем неправильно.
Ответ основан на собственных знаниях, которые сформировались в том числе благодаря труду Вигерса. Можете указать раздел книги, где требования к данным автор приписывает к нефункциональным?
Поясню вопрос:
1) «в последовательности шагов-вопросов есть ошибка» — ошибка по отношению к чему? Где указан «правильный» алгоритм вопросов, к которому Вы аппелируете?
2) «Всё перечисленное ниже — разные формулировки одного функционального требования про прикрепление файла с фото к анкете.… Это также функциональное требование...» — На основе какого определения функциональных требований Вы сделали такое заключение?
У Вигерса не дается понятия нефункциональных требований, но требования к данным описаны НЕ как функциональные. (см. главу Документирование требований, например, или примерный процесс создания требований в главе 3)
Ну и в принципе само название функциональных требований говорит о том, что устройство БД тут не при чем.
1) «в последовательности шагов-вопросов есть ошибка» — ошибка по отношению к чему? Где указан «правильный» алгоритм вопросов, к которому Вы аппелируете?
2) «Всё перечисленное ниже — разные формулировки одного функционального требования про прикрепление файла с фото к анкете.… Это также функциональное требование...» — На основе какого определения функциональных требований Вы сделали такое заключение?
У Вигерса не дается понятия нефункциональных требований, но требования к данным описаны НЕ как функциональные. (см. главу Документирование требований, например, или примерный процесс создания требований в главе 3)
Ну и в принципе само название функциональных требований говорит о том, что устройство БД тут не при чем.
1) Однозначно правильного алгоритма на все случаи, конечно, не существует. Однако обычно, когда переходят от цели («зачем?) к требованиям, то пытаются тем самым ответить на вопрос „что?“; вопрос „как?“ возникает уже при проработке дизайна. В то же время существуют и другие методы анализа (например, Impact Mapping), в которых порядок вопросов может быть иным.
2) Посмотрите внимательнее определения и примеры Вигерса. Бизнес-требование содержит метрики в бизнес-терминах (например: ускорить процесс оформления анкеты). Пользовательское требование направлено на конечную цель пользователя (например: заполнить анкету). Функциональное требование же сводится к конкретной возможности в системе (например: возможность прикрепить файл к анкете).
Всё у Вигерса чётко расписано. Он относит к нефукциональным требованиям, в частности, атрибуты качества и ограничения (см. Главу 14). Рассматривая требования к данным (см. Главу 13), он рассуждает „Везде где есть функции, существуют и данные“. Я не утверждаю, что всегда требования к данным стоит относить к функциональным — как по мне, это скорее часть дизайна. А грань между требованиями и дизайном, как известно, довольно размыта.
2) Посмотрите внимательнее определения и примеры Вигерса. Бизнес-требование содержит метрики в бизнес-терминах (например: ускорить процесс оформления анкеты). Пользовательское требование направлено на конечную цель пользователя (например: заполнить анкету). Функциональное требование же сводится к конкретной возможности в системе (например: возможность прикрепить файл к анкете).
Всё у Вигерса чётко расписано. Он относит к нефукциональным требованиям, в частности, атрибуты качества и ограничения (см. Главу 14). Рассматривая требования к данным (см. Главу 13), он рассуждает „Везде где есть функции, существуют и данные“. Я не утверждаю, что всегда требования к данным стоит относить к функциональным — как по мне, это скорее часть дизайна. А грань между требованиями и дизайном, как известно, довольно размыта.
Спасибо за развернутый комментарий. Честно, не запомнила, что Вигерс писал про нефункциональные требования что-то.
По поводу п.2 — примеры Вигерса не противоречат моим и не делают из них функциональные. Пример в тексте специально сделала утрированным, чтобы показать разницу в смысле типов требований на пальцах.
Ну а „Везде где есть функции, существуют и данные“ — не говорит о том, что требования к данным можно отнести к функциональным, все же.
И видимо термин «дизайн» мы тоже понимаем по-разному.
По поводу п.2 — примеры Вигерса не противоречат моим и не делают из них функциональные. Пример в тексте специально сделала утрированным, чтобы показать разницу в смысле типов требований на пальцах.
Ну а „Везде где есть функции, существуют и данные“ — не говорит о том, что требования к данным можно отнести к функциональным, все же.
И видимо термин «дизайн» мы тоже понимаем по-разному.
Спасибо за статью! Очень доступно и понятно!
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Требования к ПО на пальцах