Разработка спецификаций

Понятная спецификация - хорошая спецификация. Мы в Evergreen знаем, как сложное изложить просто. Закажите написание спецификации в Evergreen Документация к ПО. Разработка спецификации 7

“Спецификация” — сокращенное название документа “Спецификация требований программного обеспечения” (Software Requirements Specification, SRS). На практике этот документ может называться “техническое задание” (ТЗ), Terms of Reference (TOR), Functional Requirements и т. п.

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

Разработка спецификации — обязательная часть процесса проектирования в нашей компании. Подробнее о проектировании от Evergreen читайте тут.  Мы успешно разрабатываем спецификации как для коммерческих организаций и НГО, так и для международных доноров. Первые в большинстве случаев планируют проведения тендера на разработку собственных систем, вторые же выбирают подрядчика для разработки проектов для государственных служб. 

Что входит в спецификацию на разработку?

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

  • общий блок информации о проекте: цели, задачи, используемые термины, аудитория пользователей;
  • общее описание продукта: функциональность, детализация пользователей (персоны), операционная среда, в которой будет эксплуатироваться продукт, рамки, ограничения, правила и стандарты;
  • большую часть спецификации занимают описания алгоритмов и процессов, flow-диаграммы, функциональные требования, требования к интерфейсам (UX, API, оборудование, если есть);
  • нефункциональные требования являют собой требования к сохранности данных, безопасности, скорости, интеллектуальной собственности и лицензионной политике. 

Это неполный перечень; список разделов может меняться в зависимости от конкретного вида документа (RFP, TOR, SRS). 

Техническое задание на разработку: что такое хорошая и плохая спецификация

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

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

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

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

Как создается спецификация

В общем и целом есть 4 основных этапа работы с требованиями:

Создание спецификации

  1. Предварительные исследования. Под этим пунктом подразумевается анализ конкурентов/заменителей, UX исследование: анализ аудитории, персон пользователей, их основных проблем и задач, а также понимание бизнес-модели продукта и рентабельной суммы на его разработку.

  2. Формирование и анализ требований. На этом этапе разрабатывается UX-прототип системы или 0-прототип (минимально работающая программа для иллюстрации алгоритма и/или основной идеи). На основании этого описываются функциональные требования.

  3. Специфицирование требований.  Тут появляется собственно спецификация. В один документ собираются описания прототипа, функциональные, пользовательские и системные требования. Зачастую сформировать специфицированные требования нельзя без проектирования архитектуры ПО, поэтому мы делаем проектирование архитектуры.

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

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

  1. Утверждение требований. На этом этапе мы проверяем, выполнимость, согласованность и достаточность требований (полнота требований).

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

Также вы можете заказать разработку спецификации у нас, и получить результат, гарантированный специалистами Evergreen!

Написать

Остались вопросы?

Чувствуйте себя свободно - мы рады проконсультировать по любому профессиональному вопросу и сделаем это абсолютно бесплатно, просто позвоните нам или заполните форму.

Цей сайт є українською мовою. Ви можете переключити мову у меню, або зробити це зараз.