что есть
формализация требований
к программному обеспечению
и как ее добиться
с помощью
технического задания
и других способов ?
2
Назначение формализации требований
разные представления. Каждое представление требований выполняет определенную задачу.
Что есть формализация требований?
Представление их в рамках математического формализма
Обеспечивает за счет выбранной формы представления или
контролирует
, затратив на это приемлемые усилия,
следующие требования:
-
адекватность;
-
однозначность;
-
непротиворечивость;
-
полнота.
3
Варианты формализации требований
Неформальная постановка требований. Спецификация требований в виде документов.Формализации требований в проекте могут быть разными, существовать параллельно, решать различные задачи.
Требования в виде диаграмм
(UML Use-Case).
Формальная модель требований.
4
Неформальная постановка требований
Данный метод хорош в следующих случаях:
- в небольших проектах;
-
при вовлеченности заказчика
в разработку; - когда есть взаимопонимание между заказчиком и командой;
- когда лишние формальности не требуются;
- документами в такой ситуации, например, оказываются электронные письма.
Важно вовремя понять, когда такой способ перестает работать и необходимы формальные подходы.
5
Формализация требований с помощью use-case диаграмм UML
Функциональные требования являются основными, для них строятся диаграммы вариантов использования.
Требуемое поведение системы специфицируется одним или несколькими вариантами использования, которые определятся в соответствии с потребностями акторов.
6
ФОРМАЛИЗАЦИЯ ТРЕБОВАНИЙ С ПОМОЩЬЮ USE-CASE ДИАГРАММ UML
Минусы:
- не позволяет проанализировать существующую модель бизнес-процессов, выявить ее недостатки;
- недостаточная степень регламентации описания функции;
- невозможно проследить механизмы и управление процессом и их логику взаимодействия.
Плюсы:
-
простота, наглядность и
читабельность неспециалистами.
7
текстовые варианты использования
8
Формальная модель требований
В данном случае строится модель, описывающая некоторые аспекты (чаще функциональные) системы.
Существует процесс построения формального описания требований к программной системе FOREST (FOrmal REquirements Specification and Testing), в который включено использование формальной модели требований в качестве основы для построения тестов.
9
ФОРМАЛЬНАЯ МОДЕЛЬ ТРЕБОВАНИЙ
FOREST предоставляет возможность автоматизации выполнения ряда сложных и трудоемких задач ра зработки, таких как:
-
автоматизированная проверка полноты и непротиворечивости набора требований;
-
автоматизированное построение набора тестов, проверяющих работу системы в большом количестве разнообразных ситуаций;
-
генерация первых вариантов исходного кода системы из формальных спецификаций;
-
генерация прототипов, симуляция работы системы для более быстрого получения отзывов пользователей о ней.
10
ФОРМАЛИЗАЦИЯ требований в виде документов
По SWEBOK для описания комплексных проектов в части требований используется три основных документа:
-
Техническое задание
-
Технической проект
11
Формализация требований с помощью технического задания (ТЗ) и технического проекта (ТП)
- что же такое ТЗ и ТП?
- что писать в ТЗ и как писать ТЗ?
-
что означает “хорошее ТЗ”?
12
что есть Техническое задание?
Техническое задание — исходный документ на проектирование технического объекта, устанавливающий:
- основное назначение разрабатываемого объекта;
- его технические характеристики;
- показатели качества;
- требования;
- стадии создания документации и её состав;
-
а также специальные требования.
В ТЗ описывается, ЧТО нужно заказчику, в отличие от последующей проектной документации, в которой говорится, КАК этого достичь.
13
что есть технический проект?
Технический проект – это документ (или их совокупность), который предназначен для технической реализации требований, сформулированных в Техническом задании, содержит окончательные проектные решения по изделию (автоматизированной системе).
Разрабатывается архитектором системы или группой программистов во главе с ним.
14
Что писать в ТЗ и КАК писать тз?
15
Хорошее ТЗ — конкретное ТЗ
-
не следует использовать слова, имеющие множество синонимов;
-
следует стараться не использовать длинные предложения;
-
если какое-то требование кажется слишком общим, его необходимо детализировать до более мелких, но конкретных требований;
-
следует использовать больше схем, графиков, таблиц, рисунков, так информация воспринимается гораздо легче;
-
следует избегать таких слов: «эффективный», «адекватный», «простой», «удобный», «красивый», «оптимальный» и др.
16
Хорошее ТЗ — не всегда подробное ТЗ
Что значит получить подробное ТЗ до начала работ?
-
Заказчик рассказывает про проект и просит его оценить.
-
Разработчики просят описание проекта, чтобы понять объем работы.
-
Разработчики получают техническое задание по проекту (оно не будет исчерпывающим, особенно в больших проектах).
-
Разработчики читают, анализируют, дают оценку. Их просят подписаться под сроком, поэтому оценка сразу включает риски, т.е. увеличивается время и деньги на проект.
-
Заказчик соглашается и просит подписаться под сроком и ценой.
-
На что Разработчики, защищая свои интересы, поясняют, что после подписывания ТЗ изменения в него будет сложно внести. Придется пересогласовать и цену и срок.
-
Чтобы не идти на пересогласования, Заказчик пытается заранее учесть в ТЗ всё что только можно и нельзя.
17
Ситуация проиграл-проиграл
-
Заказчик все равно будет вносить изменения в ТЗ, можно принять это за факт. Чем больше проект, чем чаще делаются релизы, тем больше изменений будет внесено.
-
Если заранее согласовать архитектуру с техническими специалистами Заказчика, то сразу после начала работы Разработчики начнут вносить в нее изменения.
-
В ТЗ оказалось много задач, которые никогда не понадобятся Заказчику, но раз они в ТЗ, значит Разработчикам надо будет их сделать.
-
С помощью ТЗ Разработчики хотели ограничить «хотелки» Заказчика, а получили их с избытком.
-
Хуже всего в этой ситуации пользователям, т.к. сроки реализации растягиваются.
18
Случай из практики
Разработчик:
-
планирует задачи в понедельник;
-
каждый день делает релизы;
-
раз в неделю проводит демо;
-
ведет документ, который описывает всю функциональность системы.
Заказчик видит продукт, проводит демо для клиентов, получает обратную связь и хочет сделать продукт лучше. Разработчик получает наброски дизайна и примерное описание. Реализует, показывает, получает более подробные User Story, доделывает задачу.
В результате есть документ, который содержит все User Story и подробные описания частей системы. Это и есть ТЗ, только сделанное итеративным путем и готовое к изменению, а не навязанное с начала работы над проектом.
19
Хорошее ТЗ — не слишком общее ТЗ
Техническое задание должно быть достаточно детализированным!
Многие подходят к разработке программного обеспечения как к строительству жилого помещения. Они ожидают, что только после завершения строительства в доме можно жить, следовательно, только после завершения разработки программным обеспечением можно пользоваться. Однако, это часто не так.
Работы не только можно, но и нужно делить на этапы. В ТЗ цели проекта необходимо структурировать, чтобы в первую очередь достигать цели с наивысшим приоритетом, которые возможно уже позволят извлекать прибыль из проекта, а значит рефинансировать остаток разработки.
20
Методика MOSCOW
MoSCoW классифицирует приоритеты следующим образом:
-
Обязательные (Must have). Важные (пользователям нужны эти функции) и срочные (они необходимы уже в следующем выпуске).
-
Должны быть (Should have). Важные (пользователям нужны эти функции), но не срочные (они могут ждать следующего выпуска).
-
Могут быть (Could have). Не важные (пользователи при необходимости могут обойтись без этих функций) и несрочные (пользователи могут ждать).
-
Не нужны (Won’t have). Функции кажутся срочными, но в действительности — они не важны. Они не сделают продукт более ценным.
21
Изображения или текст
У руководителей предприятий обычно нет времени на изучение многостраничных ТЗ. Просмотр изображений даёт наглядное представление об основных характеристиках разрабатываемой системы. Как следствие, улучшается коммуникация между бизнес-пользователем и разработчиками и растет качество самих требований.
Вот такой прототип экрана редактирования рекламной кампании был включен в ТЗ на систему баннерной рекламы.
22
Макеты или текст?
Макеты предоставляют:
-
наглядность;
-
однозначность расположения элементов;
-
лаконичность.
Макеты НЕ предоставляют:
-
информации о функционировании элементов;
-
формализации.
Текстовые описания предоставляют:
-
полную информацию о функционировании;
-
полное описание свойств блоков, элементов и т.д.;
-
формальность описания.
Текстовые описания НЕ предоставляют:
-
наглядность.
23
Формат и стиль ТЗ
Разработайте стиль для документа, простой и удобный. С читаемым шрифтом нормального размера, чтобы он читался на среднем разрешении.
Требования должны быть написаны «живым человеческим» языком, понятным бизнес-пользователю в т.ч. руководителю высшего звена, не обладающему техническими навыками; в них должен содержаться минимум технической терминологии.
Продумайте формат и структуру документа так, чтобы по нему было удобно ориентироваться.
24
Спасибо за внимание!
Что есть формализация требований к программному обеспечению и как ее добиться с помощью технического задания? V.2
By Alexander
