Ввод в разработку ТЗ

Привет!• Ремизов Никита• Руководитель Отдела ИТ компании Retail-Navigator• Основная деятельность до недавнего времени: веб-разработка

Зачем тебе ТЗ?

Осознание проблемы

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

Как исправить ситуацию?- Может попробуем поработать с ТЗ?

Мысли и сомнения• ТЗ не нужно, его ведь долго делать .

• ТЗ нужно только для заключения договора (223-ФЗ).

• Ну ладно, с ТЗ мы сможем защититься от клиента.

Воплощение или "Первый блин комом"

- Нашли пример ТЗ- Попробовали заполнить

С ТЗ лучше, чем без него, но клиент не понимает ТЗ. (ТЗ , ТП - не одно и тоже)

Что такое ТЗ?Глазами клиента:

Техническое Задание - это описание того, что я хочу.

РазработчикКлиенты

ТЗ

Глазами разработчика:Техническое Задание - это набор функций, которые я должен реализовать.

ТЗ глазами ВикипедииТехническое задание — исходный документ на проектирование технического объекта (изделия). ТЗ устанавливает основное назначение разрабатываемого объекта, его технические характеристики, показатели качества и технико-экономические требования, предписание по выполнению необходимых стадий создания документации (конструкторской, технологической, программной и т. д.) и её состав, а также специальные требования.

Техническое задание — это набор требований к изделию (ПО).

Какие бывают требования?

• Бизнес-требование – высокоуровневая бизнес-цель организации или заказчиков системы.

• Пользовательское требование – Задача, которую определенные классы пользователей должны иметь возможность выполнять в системе, или требуемый атрибут продукта.

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

Нефункциональные требования

• Бизнес правило – Политика, предписание, стандарт или правило, определяющее или ограничивающее некоторые стороны бизнес-процессов. По своей сути это не требование к ПО, но оно служит источником нескольких типов требований к ПО.

• Атрибут качества – описывающего характеристику сервиса или производительности продукта

• Системное требование – требование верхнего уровня к продукту, состоящему из многих подсистем, которые могут представлять собой ПО ил совокупность ПО и оборудования

• Внешние интерфейсы – описывает взаимодействие между пользователем и ПО, другой программной системой или устройством

• Ограничения – Ограничение на выбор вариантов, доступных разработчику при проектировании и разработке продукта

Как связаны требования?

Карл Вигерс, Microsoft Press - Разработка Требований к ПО – 2013г.

Кто занимается разработкой требований

Илья Корнипаев - www.reqs.ru

Выявлениям требований• Создаем атмосферу (права и обязанности клиента)• Используем методы выявления: анкетирование, семинары,

интервью и др.

Разработка требований

Выявление требований – Классификация предоставляемой информации• Виды требований (Рис 1-1)• Требования к данным• Приоритеты• Открытые проблемы • Идеи решения

Анализ требований

• Модели анализа• Сущность-связь• Диаграмма перехода состояний• Диаграмма потоков данных• Др.

• Прототипы• http://ninjamock.com/ • https://gomockingbird.com/

Использование шаблонов для ТЗ• Шаблоны обеспечивают единообразие• Увеличивают скорость разработки требований

Документирование требований

Документ концепции и границ (шаблон)1. Бизнес-требования

1.1 Исходные данные

1.2 Возможности бизнеса

1.3 Бизнес-цели

1.4 Критерии успеха

1.5 Положение о концепции проекта

2. Рамки и ограничения проекта 2.1 Основные функции 2.2 Объем первоначально запланированной версии 2.3 Объем последующих версий 2.4 Ограничения и исключения3. Бизнес-контекст 3.1 Профили заинтересованных лиц 3.2 Приоритеты проекта 3.3 Особенности развертывания

Помечаем источник• Всегда можно найти инициатора требования

Нумеруем требования• Связь между требованиями• Удобство тестирования и разработки• Пример: DE-ERP-F-1

Документирование требований

Инструменты для работы с требованиямиСУТ - система управления требованиями, должна позволить:

• Дать возможность переиспользовать требования• Хранить историю изменений требований• Выводить все требования в один документ• Связывать требования и задачи в трекере задач• Простая в использовании

Список СУТ и багтрекеров

Платные решения• IBM Rational DOORS• IBM Rational Requisite Pro• Caliber• Devprom - Онлайн Сервис• Confluence + JIRA

Opensource• RequirementsWin (Нету поддержки git)• Open Source Requirements Management T

ool (Нету поддержки git)

• InfoQube Information Management System (Нету поддержки git)

• Mantis (Нету поддержки git)• Task Manager (Нету поддержки git)Наш выбор• BitBucket

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

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

требования полными и корректными;• найти подходящие вспомогательные технологии и приемы,

которые позволят получить единое представление для всех заинтересованных лиц и обеспечить целостность требований;

• контролировать внесение изменений в требования.

Где искать информацию

• Карл Вигерс и Джой Битти – Разработка требований к программному обеспечению

• http://www.reqs.ru/ - Управление требованиями• http://infostart.ru/ - Сообщество по автоматизации

бухгалтерского учета и управления• https://msdn.microsoft.com – Сеть разработчиков Microsoft

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

@NiremizovNiremizov@yandex.ru

http://golbin.ru/

С чего начать?• Возьмите небольшой проект• Попробуйте использовать указанную классификацию требований и

советы по документированию• При возникновении вопросов пользуйтесь указанными источниками

информации