что есть

формализация требований

к программному обеспечению

и как ее добиться

с помощью

технического задания

и других способов ?

Назначение формализации требований

Требования появляются после этапа их выделения в виде некоторой абстракции.

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

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

Следовательно, требования должны быть по-разному формализованы.

Что есть формализация требований?

Представление их в рамках математического формализма

Обеспечивает за счет выбранной формы представления или контролирует , затратив на это приемлемые усилия, следующие требования:

адекватность;
однозначность;
непротиворечивость;
полнота.

Варианты формализации требований

Неформальная постановка требований. Спецификация требований в виде документов.

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

Требования в виде диаграмм (UML Use-Case).
Формальная модель требований.

Неформальная постановка требований

Данный метод хорош в следующих случаях:

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

Важно вовремя понять, когда такой способ перестает работать и необходимы формальные подходы.

Формализация требований с помощью use-case диаграмм UML

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

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

ФОРМАЛИЗАЦИЯ ТРЕБОВАНИЙ С ПОМОЩЬЮ USE-CASE ДИАГРАММ UML

Минусы:

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

Плюсы:

простота, наглядность и
читабельность неспециалистами.

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

Формальная модель требований

В данном случае строится модель, описывающая некоторые аспекты (чаще функциональные) системы.

Существует процесс построения формального описания требований к программной системе FOREST (FOrmal REquirements Specification and Testing), в который включено использование формальной модели требований в качестве основы для построения тестов.

ФОРМАЛЬНАЯ МОДЕЛЬ ТРЕБОВАНИЙ

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

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

ФОРМАЛИЗАЦИЯ требований в виде документов

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

Определение системы (system definition)

Спецификация системных требований (system requirements)

Спецификация программных требований (software requirements)

Техническое задание
Технической проект

Формализация требований с помощью технического задания (ТЗ) и технического проекта (ТП)

что же такое ТЗ и ТП?
что писать в ТЗ и как писать ТЗ?
что означает “хорошее ТЗ”?

что есть Техническое задание?

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

основное назначение разрабатываемого объекта;
его технические характеристики;
показатели качества;
требования;
стадии создания документации и её состав;
а также специальные требования.

В ТЗ описывается, ЧТО нужно заказчику, в отличие от последующей проектной документации, в которой говорится, КАК этого достичь.

что есть технический проект?

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

Разрабатывается архитектором системы или группой программистов во главе с ним.

Что писать в ТЗ и КАК писать тз?

Хорошее ТЗ — конкретное ТЗ

не следует использовать слова, имеющие множество синонимов;

следует стараться не использовать длинные предложения;

если какое-то требование кажется слишком общим, его необходимо детализировать до более мелких, но конкретных требований;

следует использовать больше схем, графиков, таблиц, рисунков, так информация воспринимается гораздо легче;

следует избегать таких слов: «эффективный», «адекватный», «простой», «удобный», «красивый», «оптимальный» и др.

Хорошее ТЗ — не всегда подробное ТЗ

Что значит получить подробное ТЗ до начала работ?

Заказчик рассказывает про проект и просит его оценить.

Разработчики просят описание проекта, чтобы понять объем работы.

Разработчики получают техническое задание по проекту (оно не будет исчерпывающим, особенно в больших проектах).

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

Заказчик соглашается и просит подписаться под сроком и ценой.

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

Чтобы не идти на пересогласования, Заказчик пытается заранее учесть в ТЗ всё что только можно и нельзя.

Ситуация проиграл-проиграл

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

Если заранее согласовать архитектуру с техническими специалистами Заказчика, то сразу после начала работы Разработчики начнут вносить в нее изменения.

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

С помощью ТЗ Разработчики хотели ограничить «хотелки» Заказчика, а получили их с избытком.

Хуже всего в этой ситуации пользователям, т.к. сроки реализации растягиваются.

Случай из практики

Разработчик:

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

Заказчик видит продукт, проводит демо для клиентов, получает обратную связь и хочет сделать продукт лучше. Разработчик получает наброски дизайна и примерное описание. Реализует, показывает, получает более подробные User Story, доделывает задачу.

В результате есть документ, который содержит все User Story и подробные описания частей системы. Это и есть ТЗ, только сделанное итеративным путем и готовое к изменению, а не навязанное с начала работы над проектом.

Хорошее ТЗ — не слишком общее ТЗ

Техническое задание должно быть достаточно детализированным!

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

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

Методика MOSCOW

MoSCoW классифицирует приоритеты следующим образом:

Обязательные (Must have). Важные (пользователям нужны эти функции) и срочные (они необходимы уже в следующем выпуске).

Должны быть (Should have). Важные (пользователям нужны эти функции), но не срочные (они могут ждать следующего выпуска).

Могут быть (Could have). Не важные (пользователи при необходимости могут обойтись без этих функций) и несрочные (пользователи могут ждать).

Не нужны (Won’t have). Функции кажутся срочными, но в действительности — они не важны. Они не сделают продукт более ценным.

Изображения или текст

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

Вот такой прототип экрана редактирования рекламной кампании был включен в ТЗ на систему баннерной рекламы.

Макеты или текст?

Макеты предоставляют:

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

Макеты НЕ предоставляют:

информации о функционировании элементов;
формализации.

Текстовые описания предоставляют:

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

Текстовые описания НЕ предоставляют:

наглядность.

Формат и стиль ТЗ

Разработайте стиль для документа, простой и удобный. С читаемым шрифтом нормального размера, чтобы он читался на среднем разрешении.

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

Продумайте формат и структуру документа так, чтобы по нему было удобно ориентироваться.