Совершенное задание на разработку сайта

Создание технического задания на сайт: разработка проекта без лишних нервов

Владимир Завертайлов

Фото с сайта: forwallpaper.com

Даже когда 8 лет назад мы делали свои первые сайты, обязательной частью каждого договора на разработку у нас было техническое задание, или попросту ТЗ (может первые пару проектов мы и пробовали сделать без него, но быстро одумались). Тогда этот шедевр мысли включал разделы «Назначение сайта», «Дизайн» и «Содержание сайта».

Текст реального ТЗ на приложение для социальной сети Facebook

«Данное техническое задание является дополнением к прототипу приложения, расположенного по адресу. В случае расхождения технического задания и прототипа — приоритет имеет прототип. В случае расхождения утвержденного дизайна и прототипа — приоритет имеет дизайн».

Наступив на все возможные грабли, мы году этак в 2008 пришли к нудным, подробным многостраничным техническим заданиям на разработку сайта, которые писались больше для того, чтобы не сделать ничего лишнего в рамках проекта и доказать клиенту, что «мы это делать не должны».

Про них я еще расскажу подробнее, ведь это «обычные» технические задания программистам, которыми и сейчас пользуется большинство разработчиков сайтов.

Потом нам это надоело — при таком подходе проекты очень редко вписывались в первоначальную оценку и сдавались обычно «с нервами». Проблему решили. Теперь у нас «хорошие» ТЗ на разработку сайта, точнее не совсем ТЗ.

«Обычное» техническое задание

Зачастую техническое задание (если оно вообще есть) это нудный документ, в котором постранично текстом описано, что должно быть на сайте, с перечислением элементов и блоков через запятую или списком. Если очень повезет — для некоторых страниц нарисованы схемы. Делается оно обычно путем копирования кусков из старых технических заданий. Так например, в этом году я видел несколько ТЗ с требованием верстки под 800×600 и IE 6 (люди, откуда вы это копируете?? срочно сотрите!) Проверяется через строку (длинное, вычитывать лень). Заказчиком вообще читается через абзац — по той же причине.

Потом по брифу и этому «замечательному» документу несчастный дизайнер рисует страницы, пытаясь как-то собрать их из перечисленных через запятую кусков. В процессе часть блоков изменяется, добавляются новые, что-то удаляется (а дизайнер то хороший, про юзабилити думает!) Менеджер проектов это не всегда отслеживает (кто же будет эту уйму макетов с ТЗ сверять, и тестером проверять на этапе дизайна как-то не принято). Иногда клиент принимает макеты, особо не глядя, где какая кнопка (ему сдают красивые картинки).

Потом — это все верстается и программируется. Программисты долго пытаются состыковать ТЗ с макетами, и в результате что-то получается.

И тут начинаются пляски проджект менеджеров с бубном, чтобы сдать проект. Все тратят кучу времени и нервов, проект выходит за рамки бюджета. Проблема решается короткими итерациями и постоянными переговорами с клиентом, плюс частыми демонстрациями. При это очень важно быстро сдавать проект/этап, фиксировать сдачу и переходить к следующей итерации. Остальное не работает.

Альтернативное техническое задание

При составлении ТЗ на интернет-магазин или сайт я преследую несколько целей. Во-первых, обозначить рамки проекта. Во-вторых, дать понятные всем участникам проекта критерии его завершения. В-третьих, получить рабочий документ, на основании которого я смогу посчитать стоимость с высокой точностью и спрогнозировать максимально количество рисков. Заказчик чувствует «контроль» над процессом. А у команды значительно повышается мотивация.

Итак, хорошее техническое задание:

• должно полностью описывать результат работ,
• должно быть максимально простым и понятным,
• должно быть наглядным,
• не должно быть излишне длинным,
• должно быть измеримым (в рублях и часах),
• его должно быть в кайф читать, смотреть, тыкать и делать.

Вывод один: делать текстовые технические задания на сайты (и не только) — не самое эффективное занятие. Чтобы ТЗ было понятно всем, кто участвует в процессе на всех этапах работы, техническое задание должно включать прототип (это такая штуковина, которая очень сильно похожа на реальный сайт, но черно-белая и не работает). По интерактивным прототипам даже можно походить-покликать, и посмотреть механику работы сайта с точки зрения обычного пользователя). Прототип может дополняться текстовым техническим заданием. Я искренне считаю, что приоритет должен отдаваться прототипу, так как больше вероятность, что заказчик смотрел и тыкал в прототип, чем что он прочел и понял ТЗ.

К сожалению, многие заказчики под ТЗ понимают совсем не то, чем оно должно быть. А как раз то, с чем приходят клиенты (например: «Нужен простенький сайт-визитка с интернет магазином и небольшой социальной сетью, чтоб можно было видео загружать… Как у всех»).

Директор студии E-Time, Григорий Овсепян придумал название таким ТЗ: «декларация о намереньях».

Так вот. Техническое задание — это постановка задачи в таком виде, чтобы СРЕДНИЙ специалист по программированию или дизайну сразу без лишних вопросов смог приступить и выполнить ее. То есть не надо туда писать бизнес-стратегии. Не надо зауми. Не надо ориентации на карманных оракулов.

Цель ТЗ — помочь разработчику сделать проект именно таким, как его хотел бы видеть заказчик.

Еще. ТЗ нифига не защищают разработчика, особенно письменные. Попробуйте более-менее конкретно расписать какой-то сайт. Если клиент захочет, он сможет ЛЮБОЙ пункт интерпретировать по другому, или считать какие-то «допфункционалы» с точки зрения разработчика дефолтными. То есть он сможет при желании оспаривать любой пункт и приводить какие-либо доводы, о том, что «он думал что будет так», или что «так есть у всех», или что «так принято в моей отрасли», или что-то еще.

Я думаю, никакого способа побороть это на уровне формализации ТЗ нет. Нужно отстраивать отношения с клиентом, понимать его потребности, говорить с ним ГОЛОСОМ, а процесс работы сделать максимально интерактивным.

У клиента вообще не должно возникать желания докапываться к формулировкам в техническом задании на интернет-магазин (или любой другой сайт), даже мысли какой-то туда заглянуть лишний раз не должно быть. А должно быть ощущение, «что все идет по плану» ©, и, мало того, это именно так и должно быть. Этому способствуют короткие итерации (двухнедельные!), на которые есть четкие зафиксированные требования, которые понятны как менеджеру проекта, так и заказчику.

Люди быстрее понимают картинки и наглядное представление — поэтому рулят прототипы. Однако описать технические аспекты и механику работы web-приложений на прототипах до конца нельзя, поэтому текстовые ТЗ/постановки/диаграммы так же нужны. Это не обязательно должны быть отдельные документы. Иногда достаточно презентации в PowerPoint, иногда — даже просто комментариев к прототипу.

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

«Перезапустить» такой проект — очень сложно и дорого.

Длинные и толстые технические задания нужны в случае, если планируется вести разработку другой командой (не той, которая готовит ТЗ), или есть риск такого варианта развития событий.

Если риск не очень большой, можно делать общее короткое тех.задание на проект (фиксировать список требований), плюс делать ТЗ на конкретную итерацию. Это добавляет гибкости в процессе работы, но такой подход не очень любят программисты.

Еще раз об экономии времени. Разработка прототипа и ТЗ к нему обычно съедает 12% бюджета проекта. На первый взгляд — много. (И это реально много!) Но она не более трудозатратна

, чем создание традиционного технического задания на разработку сайта. К тому же она прогнозируема по срокам, и позволяет избежать гораздо большего вылезания из сроков и бюджета.

В маленьких проектах жопа проблема в разработке хорошего технического задания еще и в том, что его нужно готовить до того, как будет готов договор. А на это жалко времени, так как есть риск, что договор в итоге не будет подписан. Но тут нет каких-то вариантов. Или вы разрабатываете ТЗ за отдельную плату (но тогда это нужно суметь продать и обеспечить качество выполнения), или вы делаете это «бесплатно» (в этом случае имеете риски по написанию ТЗ задаром). Лично я — за проработанные платные ТЗ, и многие адекватные клиенты на это идут с удовольствием.

Что еще можно оптимизировать при разработке ТЗ:

1. Не забываем указать роли пользователей и доступные для каждого типа пользователей действия. (Эта штука называется Use Case Diagram в UML. У UML-парадигмы есть куча адептов и ненавистников, но в целом — подход рабочий, если не тратить на него много времени).

2. Структура сайта — расписываем какие разделы и подразделы сайт включает. Описываем страницы. Если схему страницы нарисовать проще, чем расписать какой блок где находится — рисуем. Если страница простая — ограничиваемся текстовым описанием. Иногда это удобно сделать с помощью ментальных карт (карт ума, mind map). Мы используем Free Mind для их построения.

3. Если ваше ТЗ включает раздел про дизайн, не надо там переписывать бриф. Достаточно качественно заполнить бриф вместе с заказчиком и сделать отсылку к нему, включив в договор отдельным приложением. В техническом же задании фиксируем только формальные требования к дизайну, количеству итераций, и порядок работ по нему. Иногда выгодно к ТЗ приложить скетч — схематичный набросок, в котором грубо прорисованы основные идеи концепции, без детализации и цвета (к сожалению со многими клиентами из России — номер не проходит и может вызвать крайне негативную реацию, так как не все воспринимают адекватно эскизы. Тут многое зависит от самого клиента и от того, насколько аккуратно менеджер проекта подготовит его к демонстрации).

4. Если используется коробочная CMS, не изобретаем велосипед — указываем редакцию, даем ссылку на ее описание на официальном сайте и перечисляем какие модули из включенных в данную редакцию настраиваем для сайта.

Вообще, средств прототипирования довольно много. В крайнем случае можно нарисовать прототип от руки на бумаге или сделать в одном из обычных офисных приложений. Мне приходилось видеть прототипы сделанные и в Word, и в Excell и в Power Point. Но гораздо удобнее использовать специальное программное обеспечение. При разработке прототипов мы пользуемся Axure Pro (рекомендую, если есть $500) или Evolus Pencil. Также популярны Visio и InDesign. Хороший обзор средств прототипирования можно найти в блоге нашего коллеги (Павел, привет! ;-)).

Давайте похоливарим в комментах: Я считаю, ТЗ делать надо, а интерактивный прототипы и короткий спек — рулят. Кто против?

Обоснование необходимости технического задания (ТЗ)

Нужно ли вообще составлять ТЗ на сайт? Заказчик четко объясняет: «Хочу простой сайт. На нем должен быть каталог наших товаров, корзина, форма для заказа. Еще добавляем условия доставки, карту проезда к нам, информацию о компании и контактные данные. И все». Что может быть непонятно? Все обычно и даже рутинно.

Разработчик читает и четко представляет, что от него требуется. По его мнению, сделать необходимо так:

Когда работа уже почти закончена, заказчик присылает свой дизайн. Тут-то и становится понятно, что клиент видит задачу слегка по-другому. Если быть точнее, заказчик хочет, чтобы было так:

И что мы имеем? Разработчик, поняв задачи по-своему, выполнил оценку объема работ и сроков их выполнения, а также рассчитал стоимость всего проекта. Все это он озвучил заказчику. А теперь выясняется, что клиент хотел и по-прежнему хочет совершенно другого.

Если «вычесть» одно изображение из другого и сделать так называемый diff, то получится та самая разница между тем, чего ожидал заказчик, и тем, что запланировал разработчик. Отличия могут быть достаточно заметными:

Именно тут и возникает конфликт, в котором, как ни удивительно, правы обе стороны. Заказчик убежден, что его пытаются «кинуть»: он же не получил того, что хотел, за заранее оговоренную цену. Разработчик уверен, что сделал все правильно и в соответствии с заказом, а возникшие у клиента «хотелки» — это как раз попытка «кинуть» исполнителя. Разрешиться такой конфликт может абсолютно по-разному: заказчик может принять выполненное, разработчик может доделать (а то и переделать) все бесплатно, обе стороны могут договориться и пойти на уступки. Но, конечно, пострадавшие (как минимум, недовольные) будут при любом раскладе.

Вот почему важно составить ТЗ. Его задача — минимизировать разницу между представлениями и ожиданиями клиента и исполнителя. Подробное техническое задание даст маленький diff, а плохое — большой.

Но не следует забывать о важном моменте: ТЗ никак не может (да и не должно) свести diff к нулю. И вот почему.

Дело в том, что и техзадание, и diff имеют свою стоимость. И понятие это шире, чем просто фиксированная сумма денежных средств. Это не только деньги и потраченное время, но и испорченные отношения, нервотрепка и так далее.

Стоимость diff’а — это стоимость всех доработок, всего того, что понадобится внести, хотя об этом изначально не было и речи. Стоимость ТЗ — это стоимость ТЗ, не больше и не меньше. Все просто: чем подробней и детальней было составлено техзадание, тем существенней его стоимость и тем меньше стоимость и величина diff’а. И наоборот.

Конечно, есть две крайности. Первая — это ситуация, когда ТЗ нет, совсем нет. И вот мы сделали фотохостинг клиенту, а он, как потом выяснилось, хотел полноценный интернет-магазин. Тут, конечно, diff окажется равным всему проекту, а его стоимость — соответственно, стоимости проекта: фотохостинг мы выкинем, а магазин сделаем. А стоимость технического задания тут нулевая.

Другая крайность — излишне детализированное ТЗ, по сути и являющееся самим проектом. Это когда в ТЗ есть абсолютно все вплоть до переменных, стилей CSS и кода. Тут, конечно, diff нулевой, а стоимость техзадания (считайте, реализации) равна стоимости всего проекта. Между этими крайностями, собственно, находится реальность. Она отражена вот на этом графике:

Синяя линия — отображение стоимости ТЗ, увеличивающейся с усилением детализации.

Линия красного цвета — отображение стоимости diff’а, снижающейся с ростом детализации.

Голубая линия отображает общую стоимость техзадания и переделок, которые предстоит выполнить. По графику видно, что у этой общей стоимости есть некое минимальное значение. Объяснение здесь достаточно простое: с определенной точки дешевле окажется что-то исправить и добавить «хотелки» клиента, чем пытаться составить идеальное ТЗ.

Отсюда делаем знаменательный вывод: задача ТЗ — хорошо описывать проект. Не больше.

 

В любом случае ТЗ — это документ или часть договора. Не так важно, оформлялся ли этот договор с подписями и мокрыми печатями или был устным. Техническое задание оговаривает, какие именно работы должны быть выполнены. Очень важный нюанс: все, что описано в ТЗ, должно непременно допускать возможность оценить это объективно. То есть в техзадании должны быть объективные критерии, по которым можно будет судить о том, выполнен определенный пункт или нет.

Еще один вывод: в ТЗ не нужно обговаривать дизайн. Его невозможно оценить беспристрастно и объективно, ведь одному он понравится, а второму — нет. А общепринятых критериев, по которым можно отличить хороший дизайн от плохого, не существует.

Задача, к примеру, могла быть сформулирована так: «в голубых тонах и чтобы с облачком». Реализовать дизайн могли как откровенно ужасно, так и шедеврально. Как ни грустно, клиенту вполне может не понравиться даже самый интересный вариант. В общем, как ни выполняются объективные критерии, от негативного результата никто не застрахован.

Составляйте ТЗ так, словно знаете, что спор с клиентом будете решать в суде, причем на основе одного только текста задания. Судья, прочитав «сделать классный дизайн, который понравится заказчику», спросит у последнего, нравится ли ему получившийся дизайн. Клиент ответит, что не нравится, и все: вы как исполнитель продолжите свою деятельность через пару лет, не раньше. Очередной вывод: используйте «закрытые» формулировки, четко ограничивающие пределы вашей работы. Никаких «все должно быть удобно», ведь удобство — фактор не объективный, а субъективный.

Ценная фраза, которую непременно следует вписать в ТЗ, звучит, возможно, сурово: «Все, что не было оговорено, исполнитель выполняет на свое усмотрение». Она довольно логична. Да, клиенту нужен определенный продукт. Но заказчик не должен (да и не может) указывать разработчику, каким образом последнему следует все делать. Такой пункт, с одной стороны, уберегает от вмешательства клиента во все детали (исполнитель и так знает, какие пакеты ему использовать), с другой стороны, лишает заказчика возможности заговорить о «хотелках».

Нам видится, что идти навстречу пожеланиям заказчика можно (а порой и нужно), пока количество «хотелок» и объем переделок не критичны. А когда грань между приличием и наглостью пересечена, самое время указать клиенту на ценную фразу. К слову, ее лучше использовать в конце техзадания. А то заказчик, прочитав ее в самом начале, наверняка воспримет все в штыки. А вот если ТЗ грамотное и в меру подробное, а в конце стоит та самая фраза, то протеста против нее почти наверняка не будет.

За источник вдохновения данной статьи стал текст товарища stg34 на хабре 

Что входит в функциональную спецификацию?

Если вы окажетесь в роли бизнес-аналитика в ИТ-проекте, вполне вероятно, что в какой-то момент вам потребуется создать функциональную спецификацию, и они могут принимать различные формы в зависимости от методологии, используемой в вашей организации. Но что такое функциональная спецификация? Зачем вы создаете функциональную спецификацию? И, возможно, что более важно, что входит в такой документ?

Целью функциональной спецификации является определение требований, которые должны быть реализованы программным решением . Теперь, как бизнес-аналитики, не все аспекты наших решений основаны на программном обеспечении. Совершенно законное решение бизнес-проблемы может включать изменение бизнес-процесса, организационное изменение или даже корректировку конфигурации.

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

Функциональные спецификации принимают различные формы

В зависимости от вашей методологии и практики бизнес-анализа, функциональные спецификации могут иметь различные форматы. Вот несколько наиболее распространенных форматов:

• Документ с функциональными требованиями
• Спецификация системных требований
• Документ бизнес-требований (вопреки названию, они обычно включают не только бизнес-требования, но и функциональные требования к программному обеспечению)
• Use Cases and User Stories — это то, чему мы учим в Bridging the Gap.

Какой бы шаблон  ни использовался в вашей организации, цель функциональной спецификации – указать, что должно делать программное обеспечение для поддержки бизнес-пользователя. Часто он рассматривается и утверждается как деловыми, так и техническими заинтересованными сторонами. Бизнес-пользователи подтверждают, что да, это то, что они действительно хотят, чтобы система делала. Технические пользователи подтверждают, что да, эти требования выполнимы, реализуемы и проверяемы.

Функциональная спецификация — это место, где бизнес встречается с ИТ

Функциональная спецификация — это момент истинного согласования бизнеса и ИТ. Другие документы, такие как модели бизнес-процессов и оценки бизнес-потребностей, могут в первую очередь просматриваться заинтересованными сторонами бизнеса. Дополнительные технические документы, такие как спецификации технического проекта, часто в первую очередь рассматриваются BA, QA и техническими заинтересованными сторонами.

Это функциональная спецификация, которая находится посередине и скрепляет все вместе.

В начале своей карьеры я, как правило, создавал более 50 страниц спецификаций требований к программному обеспечению, которые включали информацию о проекте, команде проекта, открытых проблемах, среде, предположениях, зависимостях, ограничениях, ключевых датах, бизнес-модели, требованиях к данным и, наконец, , функциональные требования. (Функциональные требования обычно занимали все, кроме 10-15 страниц этих длинных документов.) Эти документы были тщательными, но тяжелыми, и на их написание и утверждение уходило слишком много времени.

По мере того, как я становился бизнес-аналитиком, я тяготел к более короткому документу, в котором были объединены многие обзорные разделы из моих предыдущих документов, а также набор вариантов использования для детального изучения функциональных деталей. Я также участвовал в нескольких agile-проектах, где пользовательские истории были предпочтительным форматом.

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

Что на самом деле входит в эту спецификацию?

Поделюсь примерами использования и пользовательскими историями. Но сначала давайте обсудим более длинные документы — FRD, SRS или BRD.

• В FRD, SRS или BRD функциональные требования обычно представлены в виде утверждений «система должна». Обычно у вас есть список «системных требований», часто организованный в виде таблиц по функциям с установленным приоритетом. Например, «Система должна позволять участникам курса задавать вопросы». или «Система должна позволять инструктору курса просматривать все вопросы участников курса».
• В сценарии использования функциональные требования обычно представлены в виде последовательности шагов. Вариант использования помещает набор функциональных требований в контекст действий пользователя, что обычно устраняет много двусмысленности, которая попадает в вырванный из контекста список «системных требований». Например, «Участник курса решил отправить вопрос. Участник курса указывает свое имя, выбирает категорию вопроса и задает текстовый вопрос. Система отправляет электронное письмо преподавателю курса, содержащее информацию, предоставленную участником курса».
  • Вы можете скачать мой шаблон варианта использования по ссылке ниже — это абсолютно бесплатно.
• В пользовательской истории функциональные требования обычно фиксируются в следующем синтаксисе: «Как {пользователь}, я могу {делать что-то}, чтобы {я получил некоторую выгоду}. При правильном использовании синтаксис пользовательской истории прекрасно отражает цели пользователя, функциональные требования и бизнес-преимущества в одном кратком утверждении. Например, «Как участник курса, я могу отправить вопрос, чтобы узнать о своих опасениях по поводу материалов курса» и «Как инструктор курса, я могу просмотреть все вопросы участников курса, чтобы своевременно ответить».

Каждый из этих способов регистрации функциональных требований имеет свои плюсы и минусы.

• Утверждения «система должна» легко отслеживать в системах управления требованиями, но их трудно реализовать и протестировать, поскольку они часто представлены без контекста.
Варианты использования
• обеспечивают отличный контекст, который помогает утвердить и внедрить правильные функциональные требования, но также легко расширить объем внутри варианта использования при достижении целей пользователя (которые могут не соответствовать бизнес-целям) или потерять отдельные требования. в более крупных документах прецедентов.
• Пользовательские истории связывают воедино бизнес-преимущества, функциональность и цели пользователей и часто имеют нужный уровень детализации, чтобы облегчить планирование, но легко упустить из виду общую картину, если сосредоточиться только на пользовательских историях.

Выбранный вами подход часто определяется организационными стандартами. При отсутствии стандартов вы можете определить свои собственные. Рекомендуется начать с того, что спросить представителей бизнеса и технических специалистов, что они хотели бы видеть в спецификации, так как это может помочь вам избежать многих проблем в будущем. Поверьте мне, я знаю это из личного болезненного опыта.

Важность обдумывания вариантов использования для создания хороших спецификаций функциональных требований

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

Когда вы думаете об обмене взаимодействием пользователя и системы, вы достигаете нужного уровня детализации своих требований к программному обеспечению и часто обнаруживаете требования, которые в противном случае часто упускаются из виду.

Вот почему мы обучаем примерам использования как основному базовому навыку в Bridging the Gap.

И если вы хотите узнать больше об этом и сразу же приступить к работе, вы снова можете загрузить мой абсолютно бесплатный шаблон варианта использования ниже.

Мы строим нашу профессию по одному бизнес-аналитику за раз, и успех начинается с вас.

Загрузите наш бесплатный шаблон вариантов использования

И если вы хотите узнать больше об этом и сразу же приступить к работе, вы снова можете загрузить мой абсолютно бесплатный шаблон вариантов использования.

>> Щелкните здесь, чтобы загрузить шаблон варианта использования <<

Функциональные и нефункциональные требования: спецификация и типы

Время чтения: 11 минут

Четко сформулированные требования являются важными знаками на пути к успешному проекту. Они устанавливают официальное соглашение между клиентом и поставщиком, что они оба работают для достижения одной и той же цели. Качественные и подробные требования также помогают снизить финансовые риски и уложиться в график проекта. Согласно определению Свода знаний по бизнес-анализу (BABOK), требования — это полезное представление потребности.

Создание требований — сложная задача, поскольку она включает в себя набор процессов, таких как выявление, анализ, спецификация, проверка и управление. В этой статье мы обсудим основные виды требований к программным продуктам и дадим ряд рекомендаций по их использованию.

Типы требований

BABOK, признанный набор отраслевых стандартов бизнес-анализа, предлагает следующую классификацию требований.

Бизнес-требования

Сюда входят заявления высокого уровня о целях, задачах и потребностях. Бизнес-требования не включают никаких подробностей или конкретных функций. Они просто формулируют проблему и бизнес-цель, которую необходимо достичь, например,

• увеличение доходов/пропускной способности/охвата клиентов,
• сокращение расходов/ошибок,
• улучшение обслуживания клиентов и т. д.

Требования пользователей (заинтересованных сторон)

Потребности отдельных групп заинтересованных сторон (руководители высшего уровня, неуправленческий персонал, клиенты и т. д.) указываются для определения того, что они ожидают от конкретного решения. Эта группа служит связующим звеном между обобщенными бизнес-требованиями и конкретными требованиями к решениям. Они изложены в Спецификации требований пользователя и могут включать, например, возможность создавать различные отчеты, просматривать историю и статус заказов, управлять базами данных клиентов и т. д.

Требования к решению

Требования к решению описывают конкретные характеристики, которыми должен обладать продукт для удовлетворения потребностей заинтересованных сторон и самого бизнеса. Они делятся на две большие группы.

• Функциональные требования определяют, что должен делать продукт, каковы его особенности и функции.
• Нефункциональные требования описывают общие свойства системы. Они также известны как атрибуты качества .

Требования к переходу

Дополнительная группа требований определяет, что требуется от организации для успешного перехода от ее текущего состояния к желаемому состоянию с новым продуктом. Они необходимы только в течение короткого периода времени, пока происходит переход. Например, « пользователя должны быть обучены работе с системой» или «предыдущие данные должны быть перенесены в облачное хранилище».

Чтобы узнать больше о документации по программному обеспечению и планировании, просмотрите наше пояснительное видео.

Документирование программного обеспечения и планирование за 11 минут или меньше

Эта статья посвящена функциональным и нефункциональным типам требований. Прежде чем погрузиться в подробное описание, давайте сравним их бок о бок.

Функциональные и нефункциональные требования

Функциональные требования — это характеристики продукта или функции, которые разработчики должны реализовать, чтобы пользователи могли выполнять свои задачи. Поэтому важно сделать их понятными как для команды разработчиков, так и для заинтересованных сторон. Как правило, функциональные требования описывают поведение системы в определенных условиях. Например:

Система отправляет запрос на подтверждение после того, как пользователь вводит личную информацию.

Функция поиска позволяет пользователю искать среди различных счетов, если они хотят кредитовать выставленный счет.

Система отправляет электронное письмо с подтверждением при создании новой учетной записи пользователя.

Нефункциональные требования, не связанные с функциональностью системы, скорее определяют как должна работать система. Некоторые примеры:

Страницы сайта должны загружаться за 3 секунды при общем количестве одновременных пользователей <5 тысяч.

Система должна обслуживать 20 миллионов пользователей без ухудшения производительности.

Вот краткое сравнение, а затем мы перейдем к более подробному объяснению каждой группы.

Функциональные и нефункциональные требования

Типы функциональных требований и их спецификации

Функциональные требования можно классифицировать по разным критериям. Например, мы можем сгруппировать их на основе функций , которые данная функция должна выполнять в конечном продукте. Конечно, они будут различаться в зависимости от разрабатываемого продукта, но для примера типы функциональных требований могут быть такими:

• Аутентификация
• Уровни авторизации
• Соответствие законам или правилам
• Внешние интерфейсы
• Обработка транзакций
• Отчетность
• Бизнес-правила и т. д.

Требования обычно пишутся в виде текста, особенно для Agile-ориентированных проектов. Однако они могут быть и визуальными. Вот наиболее распространенные форматы и документы:

• Документ спецификации требований к программному обеспечению
• Варианты использования
• Пользовательские истории
• Структура разбивки работ (WBS) или функциональная декомпозиция
• Прототипы
• Модели и схемы

Давайте посмотрим, о чем каждый из них.

Документ спецификации требований к программному обеспечению

Как функциональные, так и нефункциональные требования могут быть формализованы в документе спецификации требований к программному обеспечению (SRS) . Чтобы узнать больше о документации программного обеспечения в целом, прочитайте нашу статью на эту тему. SRS содержит описания функций и возможностей, которые должен предоставлять продукт. Документ также определяет ограничения и допущения. SRS может быть отдельным документом, сообщающим функциональные требования, или может сопровождать другую документацию по программному обеспечению, такую ​​как пользовательские истории и варианты использования.

Мы не рекомендуем составлять SRS для всего решения до начала разработки, но вы должны задокументировать требования для каждой отдельной функции, прежде чем создавать ее. Как только вы получите первоначальный отзыв пользователя, вы можете обновить документ.

СГД должна включать следующие разделы:

Назначение . Определения, обзор системы и предыстория.

Общее описание. Предположения, ограничения, бизнес-правила и видение продукта.

Особые требования. Системные атрибуты, функциональные требования и требования к базе данных.

Очень важно сделать SRS удобочитаемым для всех заинтересованных сторон. Вы также должны использовать шаблоны с визуальным акцентом, чтобы структурировать информацию и облегчить ее понимание. Если у вас есть требования, хранящиеся в других форматах документов, предоставьте ссылку на них, чтобы читатели могли найти необходимую информацию.

Пример: Если вы хотите увидеть фактический документ, загрузите этот пример SRS, созданный в Мичиганском государственном университете, который включает в себя все пункты, упомянутые выше, в дополнение к примерам использования для иллюстрации частей продукта. Ниже приведен краткий список содержимого SRS.

Шаблон спецификации требований к программному обеспечению, источник: Требования к программному обеспечению. Автор Karl Wiegers Joy Beatty

Варианты использования

Варианты использования описывают взаимодействие между системой и внешними пользователями, которое приводит к достижению определенных целей.

Каждый вариант использования включает три основных элемента:

Действующие лица. Это внешние пользователи, взаимодействующие с системой.

Система . Система описывается функциональными требованиями, которые определяют предполагаемое поведение продукта.

Цели . Цели взаимодействия между пользователями и системой обозначены как цели.

Существует два формата представления вариантов использования:

• Спецификация вариантов использования, структурированная в текстовом формате
• Диаграмма вариантов использования

Спецификация варианта использования представляет последовательность событий вместе с другой информацией, относящейся к этому варианту использования. Типичный шаблон спецификации варианта использования включает следующую информацию:

• Описание
• Состояние до и после взаимодействия
• Основной путь взаимодействия
• Альтернативный путь
• Путь исключения

Пример:

Шаблон спецификации варианта использования

Диаграмма варианта использования не содержит большого количества деталей. Он показывает общий обзор отношений между субъектами, различными вариантами использования и системой.

Диаграмма вариантов использования включает следующие основные элементы:

• Варианты использования. Варианты использования, обычно нарисованные овалами, представляют различные сценарии взаимодействия, которые субъекты могут иметь с системой ( вход в систему, совершение покупки, просмотр товаров, и т. д. . ).
• Границы системы. Границы очерчены прямоугольником, который группирует различные варианты использования в системе.
• Актеры. Это рисунки, изображающие внешних пользователей (людей или системы), которые взаимодействуют с системой.
• Ассоциации. Ассоциации нарисованы линиями, показывающими различные типы отношений между субъектами и вариантами использования.

Пример:

Пример диаграммы вариантов использования

Пользовательские истории

Пользовательская история — это документированное описание функции программного обеспечения, рассматриваемое с точки зрения конечного пользователя. Пользовательская история описывает, что именно пользователь хочет, чтобы система делала. В Agile-проектах пользовательские истории организованы в виде отставание — упорядоченный список функций продукта. В настоящее время пользовательские истории считаются лучшим форматом для элементов невыполненной работы.

Типичная история пользователя записывается следующим образом:

Как <тип пользователя> я хочу <некоторую цель>, чтобы <по какой-то причине>.

Пример :

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

Истории пользователей должны сопровождаться критериями приемлемости . Это условия, которым должен удовлетворять продукт, чтобы быть принятым пользователем, заинтересованными сторонами или владельцем продукта. Каждая пользовательская история должна иметь хотя бы один критерий приемлемости. Эффективные критерии приемки должны быть проверяемыми, краткими и полностью понятными всем членам команды и заинтересованным сторонам. Они могут быть записаны в виде контрольных списков, обычного текста или в формате «Дано/Когда/Тогда».

Пример:

Вот пример контрольного списка критериев приемлемости для пользовательской истории, описывающей функцию поиска:

• Поле поиска доступно на верхней панели.
• Поиск начинается, когда пользователь нажимает Отправить .
• Заполнитель по умолчанию — серый текст Введите имя .
• Заполнитель исчезает, когда пользователь начинает печатать.
• Язык поиска английский.
• Пользователь может ввести не более 200 символов.
• Не поддерживает специальные символы. Если пользователь ввел в поисковый запрос специальный символ, выводится предупреждающее сообщение: Поисковый ввод не может содержать спецсимволы .

Наконец, все пользовательские истории должны соответствовать модели качества INVEST :

•          I – Независимая
•          N – возможен торг
•          В – Ценный
•          E – Оценка
•          S – Маленький
•          T – Тестируемый

Независимый. Это означает, что вы можете планировать и реализовывать каждую пользовательскую историю отдельно. Это очень полезно, если вы внедряете процессы непрерывной интеграции.

Возможен торг. Это означает, что все стороны соглашаются отдавать приоритет переговорам, а не спецификации. Это также означает, что детали будут создаваться постоянно во время разработки.

Ценный. История должна быть ценной для покупателя. Вы должны спросить себя с точки зрения клиента, «почему» вам нужно реализовать данную функцию.

Оценивается. Качественная пользовательская история может быть оценена. Это поможет команде составить график и расставить приоритеты при реализации. Чем больше история, тем сложнее ее оценить.

Маленький. Хорошие пользовательские истории, как правило, достаточно малы, чтобы их можно было планировать для коротких производственных выпусков. Небольшие истории позволяют делать более конкретные оценки.

Тестируемый. Если историю можно проверить, она достаточно ясна и хороша. Протестированные истории означают, что требования выполнены и готовы к использованию.

Функциональная декомпозиция или структурная декомпозиция работ (WBS)

Функциональная декомпозиция или WBS — это визуальный документ, иллюстрирующий, как сложные процессы разбиваются на более простые компоненты. WBS — это эффективный подход, позволяющий проводить независимый анализ каждой части. WBS также помогает получить полную картину проекта.

Предлагаем следующую логику функциональной декомпозиции:

1. Найдите наиболее общую функцию.
2. Найти ближайшую подфункцию.
3. Найти следующий уровень подфункции.
4. Проверьте свою схему.

Или процесс декомпозиции может выглядеть следующим образом:

Функция высокого уровня -> Подфункция -> Процесс -> Действие

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

Пример:

Пример функционального разложения

Программные прототипы программного обеспечения

Прототип программного обеспечения является термином Umbrella реализовано. Прототипы помогают преодолеть пробелы в видении и позволяют заинтересованным сторонам и командам прояснить сложные области разрабатываемых продуктов. Традиционно прототипы показывают, как будет работать решение, и дают примеры того, как пользователи будут взаимодействовать с ним для выполнения своих задач.

Прототипы могут быть дешевыми и быстрыми визуальными представлениями требований ( одноразовые прототипы ) или более сложными ( эволюционные прототипы ). Последними могут стать даже ранние версии продукта, в которых уже есть какие-то куски финального кода. По сути, эволюционные прототипы могут даже превратиться в минимально жизнеспособные продукты или MVP, которые мы описали в отдельной статье.

Конструкторская документация и прототипы

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

Каркасы. Вайрфреймы — это низкоточные графические структуры веб-сайта или приложения. Они помогают отображать различные страницы продуктов с разделами и интерактивными элементами.

Пример каркаса

Мокапы. После того, как каркасы готовы, они превращаются в макеты, визуальные проекты, которые передают внешний вид конечного продукта. В конце концов, мокапы могут стать окончательным дизайном продукта.

Дизайн-прототипы. Эти документы содержат визуальные элементы и допускают некоторые взаимодействия с интерфейсом, такие как прокрутка, переход по ссылкам или заполнение форм. Прототипы дизайна можно создавать с нуля с помощью HTML и CSS, но большинство UX-команд используют сервисы прототипирования, такие как InVision.

Пример:

Чтобы узнать больше о том, как обрабатываются процессы проектирования UX, ознакомьтесь с нашим примером создания решения для управления поездками для Cornerstone, корпоративного поставщика SaaS, в котором мы использовали все три типа требований к дизайну.

Дизайн интерфейса Flight Status платформы 4site

Примеры нефункциональных требований

Как мы уже упоминали, нефункциональные требования описывают, как должна вести себя система, и устанавливают ограничения ее функциональности. Этот тип требований также известен как атрибуты качества системы . Если вам нужна подробная информация о типах нефункциональных требований и о том, как подходить к ним и документировать их, ознакомьтесь с нашей специальной статьей или посмотрите наше видео.

Объяснение нефункциональных требований

Здесь мы кратко опишем наиболее типичные нефункциональные требования.

Удобство использования

Удобство использования определяет, насколько сложно пользователю будет изучить систему и работать с ней. Юзабилити можно оценивать с разных точек зрения:

Эффективность использования: среднее время, которое требуется пользователю для достижения целей, сколько задач пользователь может выполнить без посторонней помощи, количество транзакций, выполненных без ошибок и т.д.

Интуитивность: насколько просто разобраться в интерфейсе, кнопках, заголовках и т.д.

Низкая воспринимаемая нагрузка: сколько попыток требуется пользователям для выполнения конкретной задачи.

Пример: Требования удобства использования могут учитывать языковые барьеры и задачи локализации: Люди, не понимающие французский язык, должны иметь возможность использовать продукт . Или вы можете установить требования доступности: Пользователи клавиатуры, которые перемещаются по веб-сайту с помощью , должны иметь возможность нажать кнопку «Добавить в корзину» со страницы продукта в течение 15 кликов .

Безопасность

Требования безопасности обеспечивают защиту программного обеспечения от несанкционированного доступа к системе и хранимым в ней данным. Он рассматривает разные уровни авторизации и аутентификации для разных ролей пользователей. Например, конфиденциальность данных — это характеристика безопасности, описывающая, кто может создавать, просматривать, копировать, изменять или удалять информацию. Безопасность также включает защиту от вирусов и вредоносных программ.

Пример: A Права доступа к конкретной системной информации могут быть изменены только системным администратором данных.

Надежность

Надежность определяет вероятность безотказной работы программного обеспечения в течение заданного периода времени. Надежность снижается из-за ошибок в коде, аппаратных сбоев или проблем с другими компонентами системы. Чтобы измерить надежность программного обеспечения, вы можете подсчитать процент правильно выполненных операций или отследить средний период времени, в течение которого система работает до сбоя.

Пример: Процесс обновления базы данных должен выполнить откат всех связанных обновлений в случае сбоя любого обновления.

Производительность

Производительность — это атрибут качества, который описывает реакцию системы на различные действия пользователя с ней. Низкая производительность приводит к негативному пользовательскому опыту. Это также ставит под угрозу безопасность системы, когда она перегружена.

Пример: Время загрузки главной страницы должно быть не более 2 секунд для пользователей, которые заходят на веб-сайт через мобильное соединение LTE.

Доступность

Доступность определяется периодом времени, в течение которого функции и услуги системы доступны для использования во всех операциях. Таким образом, сроки планового обслуживания напрямую влияют на этот параметр. И важно определить, как можно свести к минимуму влияние технического обслуживания. При написании требований к доступности команда должна определить наиболее важные компоненты системы, которые должны быть доступны в любое время. Также следует подготовить уведомления пользователей на случай недоступности системы или одной из ее частей.

Пример: Развертывание нового модуля не должно влиять на главную страницу, страницы продуктов и доступность страниц проверки и не должно занимать более одного часа. На остальных страницах, на которых могут возникнуть проблемы, должно отображаться уведомление с таймером, показывающим, когда система снова заработает.

Масштабируемость

Требования к масштабируемости описывают, как система должна расти без негативного влияния на ее производительность. Это означает обслуживание большего количества пользователей, обработку большего количества данных и выполнение большего количества транзакций. Масштабируемость имеет как аппаратное, так и программное значение. Например, вы можете увеличить масштабируемость, добавив память, серверы или дисковое пространство. С другой стороны, вы можете сжимать данные, использовать оптимизирующие алгоритмы и т. д.

Пример: Лимит посещаемости веб-сайта должен быть достаточно масштабируемым, чтобы поддерживать 200 000 пользователей одновременно.

Передовой опыт документирования требований

Создание документации является неотъемлемой частью любого проекта разработки программного обеспечения. Хорошо задокументированные требования гарантируют, что заинтересованные стороны и разработчики находятся на одной странице, а также помогают определить объем и бюджет проекта. Вот несколько полезных советов о том, как сделать отличную документацию.

Требования должны быть четкими и понятными . Убедитесь, что ваши требования изложены в краткой форме, которая не содержит двусмысленности и не допускает различных интерпретаций. Кроме того, старайтесь избегать технологического жаргона. Помните, что каждая аудитория уникальна, и заинтересованные стороны могут быть не знакомы со специализированной технической терминологией.