Что есть формализация требований к программному обеспечению и как ее добиться с помощью технического задания? V.2

2

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

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

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

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

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

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

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

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

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

5

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

8

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

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

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

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

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

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

11

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

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

12

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

15

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

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

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

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

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

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

16

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

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

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

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

20

Методика MOSCOW

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

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

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

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

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

21

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

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

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

22

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

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

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

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

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

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

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

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

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

23

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

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

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

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

24

что есть

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

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

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

с помощью

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

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

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