Требования. ТЗ. ФС.

СОВРЕМЕННЫЕ
ТЕХНОЛОГИИ
РАЗРАБОТКИ ПО
Лекция 3.1:
Сбор и анализ требований.
Функциональные спецификации.
Техническое задание
Техническое задание
• ТЗ – базовый документ
•
•
•
•
•
общее назначение продукта
технические характеристики
требования
показатели качества
процесс выполнения проекта и приёмки
• Главная цель
• максимально полно отразить требования
• сформулировать задачу
• обосновать потребность в её решении
3
Стандарты
• ГОСТ 19.201-78 Техническое задание.
Требования к содержанию и
оформлению.
• ГОСТ 34.602-89 Техническое задание на
создание автоматизированной системы.
4
Основные разделы ТЗ
• Общие сведения о системе (программе)
• Назначение, цели и задачи системы
(программы)
• Требования к системе
• функциональные требования
• пользовательские требования
• требования к системе в целом и тд.
•
•
•
•
Требования к видам обеспечения
Требования к документированию
Стадии и этапы разработки
Порядок контроля и приемки системы
(программы)
5
Общие сведения
• Полное и сокращённое наименование
системы
• Реквизиты сторон
• Ссылки на документы, на основании
которых ведётся разработка (в т.ч.,
правовая основа)
• Сроки и финансирование
• Словарь терминов и сокращений
6
Назначение, цели и
задачи системы
Мотивация создания системы:
• какую потребность закрываем
• какие подзадачи возникают
• возможности, предоставляемые
пользователям
-
сервисы
оптимизация бизнес-процессов
безопасность
централизация обработки и хранения данных
7
Требования к системе
• Основные функциональные требования
• Декомпозиция задач:
• действующие лица
• сценарии использования
• результаты
• В составе этого раздела или в
приложении – примеры
пользовательского интерфейса
8
Требования к системе
• требования к функциональным
характеристикам
• требования к надежности
• условия эксплуатации
• требования к составу и параметрам
технических средств
• требования к информационной и
программной совместимости
• требования к маркировке и упаковке
• требования к транспортированию и хранению
• специальные требования
9
Требования к видам
обеспечения
Требования к:
• математическому
• информационному
• лингвистическому
• программному
• техническому
• и другим видам обеспечения
10
Требования к документации
• Перечень предоставляемых заказчику
документов.
• Может включать следующие документы:
•
•
•
•
•
•
•
•
•
Техническое задание
Ведомость эскизного (технического) проекта
Пояснительная записка к Техническому проекту
Описание организации информационной базы
Руководство пользователя
Руководство администратора
Программа и методика испытаний
Протокол приемочных испытаний
Акт выполненных работ
11
Стадии и этапы разработки
• Перечисляются этапы работ
• сроки
• описание
• результаты этапа
12
Порядок контроля и приёмки
• Указывается документ, на основании
которого проводятся приёмо-сдаточные
испытания.
13
Общее содержание ТЗ
• ТЗ может по необходимости
дополняться другими разделами:
• внедрение
• наполнение контентом (в случае сайта)
• и прочие работы, не подпадающие под
основные разделы
• а также может быть сокращено.
14
Функциональные
спецификации
Зачем?
• Итак, ТЗ – это:
• декларируемый набор функций
- описывает, что система должна делать
• если нужно – юридический документ
• требования ТЗ – для планирования работы
• Функциональная спецификация – это:
• надо больше программистам
• хотя и не только
• описывает, как система работает
- сценарии работы пользователей с системой
- модули и их взаимодействие
• помогает понимать систему:
- а значит, разрабатывать её и поддерживать
16
Зачем описывать поведение?
• При создании продукта
• лучше представлять замысел
- прежде чем строить здание, хорошо бы продумать, где
будут окна-двери, и понадобится ли второй лифт;
- ведь чем позже вносятся изменения – тем они дороже,
- если вообще возможны.
• стремление к одинаковому видению проекта у
команды
• С прицелом на поддержку/развитие
• Проще смотреть картинки и читать линейный
текст, чем изучать код
17
Содержимое ФС
• Множество стандартов и нестандартов
• (в чём несколько отличается от ТЗ)
• крупные методологии предписывают
определённую структуру ФС
• но структура вовсе не обязательно строгая
• Выбор (очень) зависит от контекста
• главная цель – описать систему
18
Общая схема
• Примерное содержимое ФС:
• Варианты использования
- ключевые сценарии
• Описание процессов и процедур
- детализация сценариев, компоненты
• Сложное поведение компонент
• Внутренняя структура
- детализация структуры компонент
- отношения между компонентами
- схемы БД и размещения компонент
19
Вариации
• Детали внутреннего устройства могут
выноситься в отдельный документ
• Детальная архитектура
• Также ФС может содержать:
• Чёткое разграничение целей и «антицелей»
проекта
• Списки открытых вопросов
• Специальные примечания
- маркетинговый контекст, комментарии экспертов в
предметной области
• И другое, полезное в конкретной ситуации
20
Варианты использования
• Первый шаг – отразить
пользовательские сценарии
• выделить и перечислить ключевые
взаимодействия с системой, дающие
значимый результат
• для описания подойдут
- чтобы проникнуться: пользовательские истории,
диаграммы связей (mind maps)
- чтобы быстро понять круг задач: диаграммы
прецедентов (вариантов использования) UML
21
Пользовательские истории
• User stories – рассказы о том, как
пользователи работают с программой
• Лучше писать живо и с юмором, чем сухо
© Dilbert.com
22
Mind maps
23
Mind maps
24
Диаграммы прецедентов
25
Описание процессов и
процедур
• Расписываются сценарии:
• какие элементы взаимодействуют
• что друг у друга запрашивают
• Инструменты:
• псевдокод
• диаграммы UML: робастности,
сотрудничества, последовательности
действий, деятельности
• диаграммы Data Flow
26
Диаграмма робастности
Actors – действующие лица
Boundary objects – элементы интерфейса
Control elements – управляющие процессы
Entity objects – элементы модели предметной области
Use cases (опционально) – варианты использования
© http://iconixprocess.com/iconix-process/analysis-and-preliminary-design/robustness-analysis/
27
Диаграмма робастности
28
© http://iconixprocess.com/iconix-process/analysis-and-preliminary-design/robustness-analysis/
Диаграмма сотрудничества
29
Диаграмма
последовательности действий
30
Диаграмма деятельности
31
Диаграмма потоков данных
(Data Flow)
32
Сложное поведение компонент
• Сложные алгоритмы и процедуры
• диаграммы деятельности, блок-схемы и
псевдокод
• Автоматы: смена состояний
• диаграммы состояний (UML)
33
Диаграмма состояний
34
Внутренняя структура
• Детальное описание элементов
системы:
•
•
•
•
классы (ООП) – диаграмма классов
диаграммы отношений
таблицы баз данных
схемы размещения компонент: диаграмма
развертывания (UML)
35
Диаграмма классов
36
Отношения на диаграмме
классов
37
Таблицы баз данных
38
Диаграмма развёртывания
39
Итоги
• Инструментов для создания
спецификаций много
• лекция покрыла только несколько
• Критерии выбора инструментов:
• стандартные (предписаны процессом)
• удобные (хорошо описывают)
• «компактные» (небольшое подмножество)
40
Ссылки
• ГОСТ 19.201-78, Техническое задание.
Требования к содержанию и оформлению
• ГОСТ 34.602-89 Техническое задание на
создание автоматизированной системы
• Сравнение обоих ГОСТов: общее содержание
ТЗ
• Неплохие материалы с разбором процесса
написания ТЗ на сайт:
• http://habrahabr.ru/post/140574/ и
• http://habrahabr.ru/post/138749/
41
Ссылки
• Инструменты для UML
• Visual Paradigm (community edition –
некоммерческая) http://www.visualparadigm.com/download/vpuml.jsp?edition=ce
• StarUML http://staruml.sourceforge.net/en/
• ArgoUML http://argouml.tigris.org/
• Подробный курс по UML на INTUIT:
• http://www.intuit.ru/studies/courses/32/32/info
• Дополнение по Robustness Diagram (англ.):
• http://www.agilemodeling.com/artifacts/robustnessDia
gram.htm
• Mind Maps:
• XMind http://www.xmind.net/
42