что есть

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

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

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

с помощью

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Цели ТЗ:

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

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

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

Для ТЗ:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Title

Выводы

Спасибо за внимание!