что есть

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

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

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

с помощью

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Минусы:

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

Плюсы:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

что же такое ТЗ и ТП?
что в них должно быть?
что означает “хорошее ТЗ”?

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

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

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

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

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

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

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

КЕМ пишется тЗ?

Бизнес-аналитиком

Не программистом

Бизнес-аналитиком

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

Однако чем больше проект, тем и больше людей работает над Техническим заданием.

А нужно ли техническое задание?

В Scrum, Agile и прочих технологиях говорится: «минимум бумаг, ближе к Заказчику, больше конкретики и быстрее к результату». Но формализацию требований никто не отменял и там это явно сказано.

Цели ТЗ:

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

Хорошее техническое задание — важнейшая составляющая успеха в проекте, оно является основой порядка, грамотное ТЗ — это 50 % успеха в решении задачи, однако это не панацея.

Стандарты написания и оформления ТЗ и ТП

Для ТЗ:

ГОСТ 19.201-78. ЕСКД. ТЗ. Требования к содержанию и оформлению;
ГОСТ 34.602-89. Техническое задание на создание автоматиз. системы;
ГОСТ 2.114-95. ЕСКД. Технические условия.

Для ТП:

ГОСТ 34 серии;
ГОСТ 2.120-73. Требования к выполнению технического проекта;
ГОСТ 2.102-68. Номенклатура конструкторских документов технического проекта.

ГОСТы не являются универсальной хорошей практикой. Используя ГОСТы нужно искать "золотую середину" . Также требований ГОСТа явно недостаточно , чтобы разработать эффективное Техническое задание.

Понятие «Хорошего ТЗ»

Для менеджера ТЗ хорошее тогда, когда по нему удается сделать проект с первого захода. Когда время, ресурсы и результат оправдали ожидания.

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

В отличном ТЗ определен порядок тестирования и приемки результата, причем не скопирован из ГОСТа, а действительно продуман и принят сторонами.

дл я кого пишется ТЗ?

У ТЗ два основных читателя:

разработчик;
клиент;

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

Типичные реакции типичного клиента на ТЗ в 50-70 страниц:

попытка раздать его всем коллегам «почитать»;
подписывание без чтения.

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

требования В ТЗ?

При написании ТЗ необходимо :

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

какие требования писать в тз?

Здесь нам поможет ГОСТ. Например:

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

Требования к функциональности – это 90% сложности работ по разработке ТЗ.

Свойства требований:

требование должно быть понятным;
требование должно быть конкретным;
требование должно быть тестируемым.

Если результат выполнения требования невозможно протестировать, значит, оно либо не понятное, либо не конкретное.

Структура ТЗ и обязательные пункты

ГОСТ рекомендует следующие разделы:

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

Картинки или текст?

Все что можно нарисовать — нужно рисовать.

Макеты, схемы страниц, направления движения денег, структуру данных.

Однако разработчику нужно кроме картинок написать довольно много текста:

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

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

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

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

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

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

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

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

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

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

Живые макеты в Axure и Balsamiq

Преимущества:

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

Недостатки:

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

Title

Выводы

Главное — не верьте в них слепо, адаптируйтесь под проект, команду, заказчика.

Сам проект автоматизации не решает проблем бизнеса – помните об этом.