Никита Ремизов - Введение в разработку ТЗ Событие: Drupal Meetup #6 Дата: 23.05.2015 Анонс: http://drupalspb.org/session/vvedenie-v-razrabotku-tz

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

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

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

4. Мысли и сомнения
• ТЗ не нужно, его ведь долго делать .
• ТЗ нужно только для заключения договора (223-ФЗ).
• Ну ладно, с ТЗ мы сможем защититься от клиента.
Воплощение или "Первый блин комом"
- Нашли пример ТЗ
- Попробовали заполнить
С ТЗ лучше, чем без него, но клиент не понимает ТЗ.
(ТЗ , ТП - не одно и тоже)

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

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

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

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

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

10. Кто занимается разработкой требований
Илья Корнипаев - www.reqs.ru

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

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

13. Анализ требований
• Модели анализа
• Сущность-связь
• Диаграмма перехода состояний
• Диаграмма потоков данных
• Др.
• Прототипы
• http://ninjamock.com/
• https://gomockingbird.com/

14. Использование шаблонов для ТЗ
• Шаблоны обеспечивают единообразие
• Увеличивают скорость разработки требований
Документирование требований
Документ концепции и границ (шаблон)
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 Особенности развертывания

15. Помечаем источник
• Всегда можно найти инициатора требования
Нумеруем требования
• Связь между требованиями
• Удобство тестирования и разработки
• Пример: DE-ERP-F-1
Документирование требований

16. Инструменты для работы с требованиями
СУТ - система управления требованиями, должна позволить:
• Дать возможность переиспользовать требования
• Хранить историю изменений требований
• Выводить все требования в один документ
• Связывать требования и задачи в трекере задач
• Простая в использовании

17. Список СУТ и багтрекеров
Платные решения
• IBM Rational DOORS
• IBM Rational Requisite Pro
• Caliber
• Devprom - Онлайн Сервис
• Confluence + JIRA
Opensource
• RequirementsWin (Нету поддержки git)
• Open Source Requirements
Management Tool (Нету поддержки git)
• InfoQube Information Management
System (Нету поддержки git)
• Mantis (Нету поддержки git)
• Task Manager (Нету поддержки git)
Наш выбор
• BitBucket

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

19. Где искать информацию
• Карл Вигерс и Джой Битти – Разработка требований к
программному обеспечению
• http://www.reqs.ru/ - Управление требованиями
• http://infostart.ru/ - Сообщество по автоматизации
бухгалтерского учета и управления
• https://msdn.microsoft.com – Сеть разработчиков Microsoft

20. Спасибо за внимание
@Niremizov
Niremizov@yandex.ru
http://golbin.ru/

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