Представим, что вы планируете разработать большой проект: сайт, блог или приложение. Чего вы боитесь как заказчик? Что подрядчик пообещает золотые горы, возьмёт деньги, но не сделает, что вы хотели. А как подрядчик? Что в начале работы вас попросят сделать одно, а в процессе — всё переделать (причём раз десять), в итоге вы потратите кучу времени и уйдёте в минус.
Проект большой, поэтому надо принять меры. И поможет в этом спецификация (в простонародье — спека). В этой статье я расскажу, как готовить спецификацию к масштабному проекту, на примере нашей недавней работы с крупным клиентом.
Что такое спецификация?
Спецификация — это документ с набором требований, которым должен соответствовать разрабатываемый продукт. Весомый плюс этого документа в том, что он сэкономит вам время разработки и гарантирует спокойствие при согласовании.
Спека похожа на список продуктов перед походом в магазин. Запишите и структурируйте всё, чтобы не забыть «купить». Это по сути договор между вами и заказчиком, который регулирует объём будущих выполненных работ.
Подготовку спецификации можно разделить на пять шагов.
1. Закрытая или открытая?
Открытая спецификация описывает требования к исполнению, но не указывает, как эти требования должны быть достигнуты. Такой формат удобен исполнителю: он получает свободу выбора рабочих инструментов в течение всего процесса и не скован непреложными истинами, от которых не сделать потом шаг в сторону.
Закрытая спецификация описывает не только способы достижения требований, но и инструменты или технологии, которые нужно использовать при создании продукта. У закрытой спецификации больше плюсов для заказчика: он заранее согласовывает путь разработки, поэтому для него такой подход более прозрачный.
Есть и средний вариант: полузакрытая спека (обычно заказчики и исполнители договариваются именно на такой компромисс). Вы описываете инструменты разработки только там, где их можно определить заранее, до начала работ.
2. Содержание
По структуре спецификация похожа на дипломную работу: элементы вроде содержания, введения или списка источников точно напомнят о студенческих временах.
Ну и какая дипломная работа спецификация без титульного листа! Добавьте на него заголовок и дату публикации.
3. Разделы
Спецификация должна быть такой, чтобы любой открывший её сразу понял, что и как нужно делать. Вот обязательные разделы: они понадобятся при описании любого проекта. Их можно пополнить подразделами, если нужно.
- Введение
- Обзор : цель спецификации.
- Объём проекта : краткое описание проекта.
- Глоссарий : расшифровка терминов.
- Ссылки : список источников.
- Обзор продукта : краткое описание каждого раздела
- Системная среда : общее описание, при помощи каких инструментов будет реализован функционал продукта.
- Спецификация функциональных требований : подробное описание, из чего состоит продукт. Если вы создаёте сайт, здесь будет подробное описание всех его страниц, хедера, футера и так далее.
- Требования к интерфейсу : общее описание требований к возможностям интерфейса проекта. Если продолжать пример с сайтом, то в этом разделе можно указать домен, на котором он будет размещаться, место хранения базы данных и используемые API.
- Функциональные требования : описание того, как должна работать система со стороны пользователя. Здесь, например, можно описать карту сайта, работу пагинации, RSS и счётчики аналитики.
- Нефункциональные требования : описание того, что нужно сделать, чтобы реализовать функциональные требования. Так сказать, начинка продукта. К примеру, описание страниц ошибок, навигации по сайту, требования к производительности и безопасности данных.
О последних двух подпунктах расскажу подробнее.
4. Функциональные и нефункциональные требования
Это основная и самая подробная часть спецификации. Ей нужно уделить особое внимание, но сначала давайте разберёмся, в чём разница между этими требованиями.
Функциональные требования — то, как должна вести себя система, чтобы удовлетворить ожидания пользователя. В нашем проекте одной из функций была строка поиска. В её поведение закладывалось ранжирование результатов в хронологическом порядке. А если ничего не найдено, то пользователь получает рекомендацию изменить запрос.
Ещё один пример: описание работы комментариев на сайте
В то время как функциональные требования определяют, что делает система, нефункциональные требования описывают, как она это делает. Это свойства, которые система должна демонстрировать, или ограничения, которые она должна соблюдать. Например, веб-сайт не должен загружаться более 3 секунд.
Другой пример нефункционального требования — безопасности
Если продукт не соответствует нефункциональным требованиям, он продолжает выполнять основные функции, но не обеспечивает пользователю удобство.
5. Согласование
Для начала представьте себя заказчиком и прочитайте спецификацию его глазами. Скорректируйте текст, если в нём чего-то не хватает или есть слабые места.
Далее отдайте спеку заказчику на первую оценку. Возможно, согласование займёт несколько итераций, но это неотъемлемая часть работы.
Как только спека согласована, остаётся подписать её вместе с заказчиком и приступать к работе.
В сухом остатке
Информации было много, давайте закрепим:
Спецификация может показаться сложным документом, но без неё будет намного сложнее в самой разработке. А чтобы вам было полегче, скачайте через форму ниже готовый шаблон
Источник: emailmatrix.ru
Документ бизнес-требований: определение и советы
По мере роста бизнеса или изменения направления его требования к документации также будут меняться. В этой статье мы исследуем, что такое документ с бизнес-требованиями, чем он отличается от документа с функциональными требованиями (FRD) и советы по его написанию.
Что такое документ бизнес-требований?
Документ бизнес-требований (BRD) — это формальный отчет, в котором подробно описаны все цели или «требования» для нового проекта, программы или бизнес-решения. Он описывает бизнес-потребность или цель, а также то, что ожидается в ходе реализации проекта. После утверждения BRD компания или команда могут приступить к поиску наилучшего подхода к созданию решения. Таким образом, BRD обеспечивает ясность, сохраняет фокус и устраняет двусмысленность в отношении потребностей проекта.
Каковы преимущества BRD?
У хорошо разработанного BRD есть несколько преимуществ, в том числе то, что он может:
Программы для Windows, мобильные приложения, игры — ВСЁ БЕСПЛАТНО, в нашем закрытом телеграмм канале — Подписывайтесь:)
- Сокращает количество неудач проекта из-за несогласованных или искаженных требований
- Подключается к более широким бизнес-целям и помогает отслеживать общее состояние проекта.
- Создает консенсус и сотрудничество между заинтересованными сторонами и членами команды
- Сокращает расходы, связанные с запросами на изменение, обучением, инфраструктурой и т. д.
Кто создает BRD?
BRD — один из первых документов, созданных в жизненном цикле проекта. Хотя документ обычно составляется бизнес-аналитик, в его создании должны участвовать несколько человек, в том числе команда проекта, деловые партнеры и ключевые заинтересованные стороны. Их основной аудиторией будут спонсоры проектов, высшее руководство, руководство среднего звена и аналитики.
Разница между BRD и FRD
Документ бизнес-требований часто путают с документом функциональных требований (FRD), еще одним термином в управлении компанией. Хотя оба документа работают совместно для создания и достижения бизнес-целей компании, они очень разные по своей природе. В то время как BRD обсуждает, что нужно делать бизнесу, FRD описывает, как это сделать. Каждый из них имеет свою ценность в бизнес-стратегии, и ни одним из них нельзя пренебрегать как частью процесса.
Семь шагов для создания BRD
Перед созданием документа бизнес-требований необходимо выполнить предварительные условия и выполнить задачи. Эти шаги включают в себя:
1. Определите потребности компании
Шаг заключается в разработке четкого и подтвержденного определения проблем, стоящих перед бизнесом. Документ должен четко и кратко объяснять проблему или ситуацию, которую бизнес пытается решить, чтобы гарантировать, что все участники понимают и согласны.
2. Определите цели BRD
Как только вы узнаете проблему, следующим шагом будет четкое определение целей документа бизнес-требований. Это может дать несколько преимуществ, в том числе:
- Внесение вклада в следующую фазу проекта
- Создание основы для определения подходящих решений для потребностей и требований бизнеса и клиентов
- Достижение консенсуса среди участников
- Описание того, что и как достичь поставленных целей
Также важно установить объем требований для всех этапов проекта. Объем включает в себя то, что требуется и ожидается на каждом этапе проекта.
3. Вовлекайте других
Чтобы убедиться, что все необходимые детали включены в документ, вы должны получить информацию от всех вовлеченных сторон. Затем команда может увидеть проект с разных точек зрения, что может способствовать более продуктивному мозговому штурму и поиску новых решений.
4. Определите этапы проекта
Если в проекте задействованы разные фазы, каждая фаза должна иметь заявленные требования или входные данные и ожидаемые результаты или результаты. Например, сколько работы требуется и что она даст? BRD должен продемонстрировать четкие и ожидаемые функции для завершения проекта.
5. Установите стандарты для всех требований
Поскольку в проекте могут быть разные этапы и другие участники, важно установить стандарты ожидаемого. Стандарты помогут регулировать качество и количество работы, выполняемой для выполнения бизнес-требований, и обеспечивать выполнение проекта в соответствии с графиком.
6. Разработайте процесс планирования и измерения
Перед созданием BRD необходимо установить критические вехи с критическим рабочим графиком, в котором подробно описывается путь выполнения каждой из них. Это гарантирует своевременное и успешное завершение проекта. В документ с бизнес-требованиями также должен быть включен надежный метод мониторинга и измерения прогресса.
7. Используйте подходящий шаблон
Когда вся необходимая информация будет собрана, используйте соответствующий шаблон для представления требований. Шаблон упрощает создание документа и обеспечивает четкое представление информации в привлекательном и понятном формате.
10 элементов BRD
Десять важнейших элементов составляют эффективный BRD, в том числе:
1. Резюме
В исполнительном резюме излагаются требования проекта. Обычно он пишется после завершения BRD, чтобы можно было включить все основные моменты.
2. Цель
С использованием СМАРТ-формат Это эффективный метод создания конкретной, измеримой, достижимой, реалистичной и зависящей от времени цели. Это позволяет легко заключить всеобъемлющее соглашение, сохраняя при этом целенаправленность проекта и его соблюдение. Часто упускаемым из виду компонентом является процесс измерения, который идентифицирует и позволяет вносить изменения, если и когда это необходимо.
3. Заявление о потребностях
Заявление о потребностях, или «справочное заявление», объясняет, почему проект необходим и как завершение проекта будет соответствовать требованиям.
4. Масштаб проекта
Объем проекта очерчивает границы проекта и является одним из наиболее важных компонентов. Масштаб отвечает на три важных вопроса:
- Какие проблемы решает проект?
- Каковы границы реализации проекта?
- Каков ожидаемый ROI от завершения проекта?
5. Финансовая отчетность
Финансовые отчеты важны для общего представления о влиянии проекта на баланс компании и ожидаемые доходы. Этот раздел также должен содержать подробную информацию о том, как будет финансироваться проект.
6. Функциональные требования
В разделе функциональных требований подробно описано, кто за что отвечает, как, когда и где проект будет завершен, и что необходимо для этого. Это должно включать временные рамки, диаграммы и диаграммы, чтобы помочь в планировании и регистрации прогресса.
7. Требования к персоналу
Требования к персоналу иллюстрируют ожидаемые человеческие ресурсы, необходимые для проекта, включая тех, кто должен быть нанят и когда. В этот раздел также будет включена стоимость этих ресурсов.
8. График, сроки и сроки
Составьте тщательно спланированный и подробный график, включающий сроки, контрольные точки и систему мониторинга. Это поможет вам держать ключевые заинтересованные стороны в курсе проекта на определенных этапах. Можно внести коррективы, чтобы добавить или вычесть ресурсы, чтобы сохранить определенные компоненты проекта, такие как стоимость и ресурсы, в соответствии с графиком.
9. Анализ затрат и результатов
А анализ выгоды и затрат детализирует все сопутствующие расходы, связанные с проектом, а также ожидаемые выгоды.
10. Ожидания и предположения
В зависимости от продолжительности проекта потребуются допущения. Включите ожидания и предположения, которые могут повлиять на результат проекта, поскольку они могут иметь существенное влияние. Ожидания, которые часто учитываются, включают изменение делового климата, предпочтений клиентов, процентных ставок или обстоятельств, не зависящих от контроля. Четко формулируйте предположения, чтобы избежать проблем в дальнейшем.
Советы по написанию документа с бизнес-требованиями
Следуйте этим советам, чтобы написать эффективный документ с бизнес-требованиями:
- Используйте слова, побуждающие к действию: есть несколько способов побудить к действию с помощью слов, включая использование простого и несложного жаргона, который легко понять.
- Вовлекайте других: поощряйте других участвовать в таких мероприятиях, как мозговой штурм, фокус-группы, интервью, опросы и идеи для прототипирования.
- Проведите небольшое исследование: изучите прошлые проекты, чтобы определить осуществимость вашего BRD. Оцените свой проект, чтобы определить, выдерживает ли он проверку.
- Включите наглядные материалы. При необходимости используйте наглядные материалы, такие как диаграммы и диаграммы, так как они могут помочь вам донести свою точку зрения.
- Проверьте содержимое: после написания документа с бизнес-требованиями проверьте его перед распространением. Получите подтверждение информации и содержимого, включая предположения, и убедитесь, что все ошибки или упущения исправлены.
Источник: buom.ru
Как написать функциональное техническое задание?
Всё просто: нормальным русским языком описывайте нужные функции в формате сценария использования.
Сценарий проще всего описывать в по схеме: [роль пользователя] может [действие], [описание целей пользователя, а также необходимых шагов и вариантов развития событий]. Оптимально — разбивать описание больших компонентов на маленькие составляющие.
В конечном итоге, пункты ТЗ должны быть объективными, просто изложенными и элементарным способом проверяемыми требованиями.
Например, вполне адекватные функциональные требования в формате сценария:
Гость должен иметь возможность зарегистрироваться на сайте, путем заполнения формы регистрации (обязательно указав своё имя, адрес электронной почты и желаемый пароль). Также гость, при наличии у него учётной записи, должен иметь возможность войти на сайт, указав в соответствующей форме свой адрес электронной почты и пароль. Это нужно для того, чтобы у него была возможность выполнять действия, требующие наличия учетной записи (например, покупать товары в интернет-магазине или оставлять комментарии).
Каждый аутентифицированный (вошедший на сайт) пользователь должен иметь возможность выйти из системы, например, чтобы исключить осуществление дальнейших действий на сайте от своего имени другими пользователями компьютера.
Примеры некорректных требований ТЗ
Субъективные требования — это все требования с оценочными прилагательными типа удобный, красивый, простой и тому подобными. Они некорректны для ТЗ, так как их никак нельзя проверить, а значит принять работу, основываясь на таких критериях просто не получится:
Форма входа в систему должна быть удобной и понятной для пользователя.
Непонятно изложенные требования — это еще один пример того, что не должно попадать в ТЗ. Такие требования формулируются так, что нельзя без должной подготовки понять о чём вообще идёт речь, например:
Пользователь должен иметь возможность реструктуризировать компоненты своего аккаунта путём декомпозиции отдельных сущностей на произвольно задаваемое число взаимно зависимых компонентов.
Субъективные требования чаще всего формулирует бизнес и маркетинг, а непонятно изложенные — ИТ и другие технические специалисты. И с тем, и с другим надо бороться, так как ТЗ должно быть руководством к действию и чек-листом, по которому можно проверить выполненную работу. А некорректные требования приводят к тому, что ТЗ для этого не может быть использовано, и не очень понятно зачем его было вообще писать, если никто им не пользуется.
Примеры корректных требований ТЗ
Еще примеры нормальных функциональных требований:
Гость на каждой странице может войти на сайт. По нажатию кнопки «войти» открывается форма для ввода логина и пароля. При корректном вводе логина и пароля пользователь входит на сайт и ему выводится уведомление об этом, дальше он работает с сайтом как аутентифицированный пользователь и ему становятся доступны дополнительные возможности. При некорректном вводе логина и/или пароля отображается уведомление о произошедшем и пользователю предлагается повторно заполнить форму
Зарегистрированный пользователь при посещении сайта должен видеть персональное приветствие «Здравствуйте, [Имя] [Отчество]!» и ссылку для выхода с сайта. При нажатии на своё имя пользователь попадает в личный кабинет, при нажатии на ссылку «выход» — выходит из системы и дальше работает с сайтом как гость.
Администратор может удалить страницу сайта. В списке страниц напротив каждой страницы есть кнопка для удалени, по нажатию на эту кнопку выводится диалог подтверждения удаления. При подтверждении страница удаляется, а при отказе — удаления не происходит.
Как правило, функциональные требования развиваются: уточняются и конкретизируются как в процессе согласования, так и в процессе разработки.
Например, описание процедуры регистрации в конечном итоге может выглядеть так:
Гость должен иметь возможность зарегистрироваться на сайте. Для этого он может с любой страницы сайта по ссылке «зарегистрироваться» перейти на страницу с формой регистрации.
Форма регистрации содержит поля: Фамилия, Имя, Адрес электронной почты, Пароль и его Подтверждение, а также флаг согласия с публичной офертой. Все поля являются обязательными для заполнения. Адрес электронной почты должен быть корректным адресом e-mail, Пароль должен быть не короче 6 символов и содержать буквы и цифры, Пароль и Подтверждение должны совпадать, флаг согласия с публичной офертой должен быть установлен. При некорректном заполнении формы выводится список ошибок при заполнении формы, а поля с ошибками подсвечиваются.
Корректно заполнив и отправив форму регистрации гость создаёт новую учётную запись, а ему на указанный адрес электронной почты отправляется письмо с уведомлением о регистрации и со ссылкой для активаци аккаунта. Для активации аккаункта пользователь должен перейти по полученной ссылке, после чего он будет автоматически аутентифицирован (войдёт на сайт).
Если пользователь не получил ссылку для активации, то он может запросить её повторную отправку, просто указав свой адрес электронной почты, в этом случае ему должно быть также выведено сообщение с рекомендацией поискать письмо в спаме.
Вход при помощи формы входа до активации учётной записи невозможен, в случае попытки входа или регистрации с реквизитами доступа неактивной учетной записи пользователю должно быть выведено уведомление о том, что учетная запись неактивна, а также предложение повторно отправить письмо со ссылкой для активации аккаунта.
Если пользователь не активирует свою учётную запись в течение одной недели, то она будет удалена из базы данных.
В случае перехода по ссылке «зарегистрироваться» уже зарегистрированным и аутентифицированным пользователем форма регистрации не должна показываться, а должна быть осуществлена переадресация на страницу профиля текущего пользователя с уведомлением: «Вы уже зарегистрированы и уже вошли на сайт».
Такая подробная спецификация пусть и не очень проста в написании, но зато достаточно точно описывает требования к итоговой логике работы компонента, что позволяет без проблем провести сдачу-приёмку выполненных работ.
Разумеется, что в написании любой спецификации рационально соблюдать баланс между полнотой / детализированностью требований и простотой понимания / написания самого ТЗ.
Избыточная детализация времязатратна и делает ТЗ перегруженным очевидными деталями, но недостаточная детализация приводит к тому, что какие-то важные требования не будут описаны и могут не быть реализованы. Задача бизнес-аналитика, составляющего ТЗ, как раз и заключается в том, чтобы найти баланс между полнотой изложения и лаконичностью.
Уровень необходимой детализации ТЗ обычно зависит от компетентности специалистов и от корпоративной культуры. Профессионалам можно ставить высокоуровневые задачи и они их решат адекватным способом, а начинающим специалистам лучше более полно детализировать задачи, декомпозировать их и формулировать критерии приёмки. С корпоративной культурой всё несколько сложнее, например: чёткое следование регламентам и формализация — это отличный фактор для процессной деятельности, но в проектной / продуктовой разработке это несколько замедляет работу, так как требует более формальной и детализированной постановки задач.
Функциональное техническое задание — более простой и понятный способ описания требований, нежели классическое ТЗ.
Источник: web-creator.ru