L3 requirements

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

3
Документирование и
организация требований

TEKAMA
Software Engineering Professional Program © 2007. 3-1


Цели и задачи
• Документирование требований c помощью
общепринятых шаблонов и форматов
• Рассмотрение различных способов
документирования требований
• Обеспечение качества требований

TEKAMA


Фиксация требований

Если этого нет на бумаге,
значит этого не существует

Любимая аксиома Алана Купера
(из книги «Психбольница в руках пациентов»)

TEKAMA


Вопросы для размышления
• Какие существуют стандартные шаблоны для
документирования требований и зачем их
использовать?
• Какие существуют способы описания требований
помимо текстового?
• Как выполняется проверка правильности
требований?

TEKAMA


Требования и соответствующие
документы

Требования пользователей варианты использования

Бизнес потребности документ о представлении/рамках проекта

Функциональные требования спецификация требований к ПО

TEKAMA


Организация требований – 1
• Следующий шаг после сбора требований – их
документирование
– Родственные группы – наборы сходных элементов
• Элементы, связанные концептуально
• Элементы, связанные общей тематикой (функция, средство, и
т.п.)
– Иерархии – упорядоченные зависимости
• Нижестоящие элементы подчиняются вышестоящим
элементам
• Нижестоящие элементы развивают или дополнительно
уточняют вышестоящие элементы

TEKAMA


Организация требований– 2
• Последовательность организации требований состоит из
трех шагов
– Поделить требования на родственные группы
– Иерархически структурировать каждую группу
– Распознать пробелы
• Пробелы и несогласованность могут потребовать
дополнительного анализа и/или выявления
дополнительных требований

TEKAMA


Группирование требований
• Чтобы сгруппировать требования
– Просмотрите потребности или идеи
– Идентифицируйте независимые темы – каждая тема
определяет группу
– Дайте каждой группе обычное словесное описание
• Объясните потребность высшего уровня
• Объясните специфические требования

TEKAMA


Иерархия требований
• Организуйте каждую группу иерархически
– приоритет
– схема именования
– высший/низший уровни абстракции
– определите ограничения
– разработайте древовидную структуру
– добавьте новую информацию, если необходимо

TEKAMA


Методы документирования требований
• Хорошо структурированные документы на
обычном языке
• Графические модели, поясняющие
трансформационные процессы, системные и
переходные состояния, взаимосвязи данных,
логические выводы, классы объектов и т.п.
• Формальные спецификации, определяющие
требования с помощью математической логики

TEKAMA


Документы на основе требований – 1
• При разработке требований могут создаваться все
или только некоторые из следующих документов
– Состав и распределение работ
– Спецификация требований
– Концепция эксплуатации
– Начальный план разработки ПО
– Критерии принятия работ

TEKAMA


Документы на основе требований – 2
• Всегда ли надо создавать все эти документы?
– Слишком много правил означает, что правил нет
– Названия не важны – важна информация
• Необходимо ответить на следующие вопросы:

 Что должна делать система?  Как система работает в операционной
 Какими качественными среде?
характеристиками должна она  Как вы будете создавать систему?
обладать?  Что значит успешно выполнить работу?
 Какие существуют ограничения?
 Кто и за что несет ответственность?

TEKAMA


Состав и распределение работ
• Распределяет ответственности между
заинтересованными сторонами проекта
– Кто создает, что и когда
– Кто тестирует, что, как и когда
– Кто платит, за что и когда
– Кто докладывает кому
– Кто принимает/утверждает завершение работ
– Кто, как и когда санкционирует изменения
– И т.п.
TEKAMA


Спецификация требований
• Спецификация требований создается после анализа
требований
– Границы системы
• Определите, что является внутренним и внешним для системы

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

– Характеристики качества
– Распределение приоритетов

TEKAMA


Концепция эксплуатации
• Концепция эксплуатации - описание того, как система
должна работать или будет использоваться в контексте
организации
– какие функции будут использоваться и кем
– как эти функции будут использоваться
– в каких условиях эти функции будут использоваться
– как будет происходить ввод/вывод данных
– как система взаимодействует с другими системами
• Задает основу для разработки вариантов использования

TEKAMA


Начальный план разработки ПО
• Это первая попытка распределить предполагаемые
работы по времени
– Основные обзоры
– Основные документы
– Точки принятия решений
– Поставляемые продукты
– Этапы работ и контрольные точки
– Графики платежей
• Это высокоуровневый и приблизительный план

TEKAMA


Спецификация требований к ПО

Начало есть более чем половина всего.
Аристотель

TEKAMA


Основы
• Фундамент всего последующего планирования, проектирования и
написания кода проекта
• Основание для тестирования системы и документации пользователя
• Должна описывать как можно более полно поведение системы в
различных условиях
• Не должна содержать деталей проектирования, реализации,
тестирования или управления проектом, за исключением ограничений
• Должна быть максимально всесторонней и полной
• Не должна быть написана сразу для всего продукта до начала
разработки… но должна как минимум определять требования на
ближайшую итерацию
• Является исходным соглашением между заказчиком и разработчиком
(должна быть утверждена заказчиком)

TEKAMA


Риски отсутствия спецификации
• Риск разного понимания требований
разными участниками разработки;
• Опасность сделать ПО, не отвечающее
потребностям заказчика или покупателя;
• Риск неоплаты усилий разработчиков;
• Неправильная оценка трудоемкости и
сроков;
• Незащищенность проекта от смены
разработчиков.
TEKAMA

Интерфейс пользователя и спецификация
требований к ПО
Включать или нет?

• Описывает решения (дизайн), а
не требования
• Рассмотрение интерфейса • Может задержать создание
пользователя (UI) вместе с основной спецификации
прототипами делает требования требований к ПО
реальными для разработчиков и • Компоновка экранов не заменяет
пользователей функциональных требований
• Может помочь при • Включение интерфейса
планировании проекта и оценке пользователя в спецификацию
• Может улучшить требований к ПО может вести к
коммуникацию тому, что визуальная модель
будет определять требования,
что ведет к функциональным
пробелам
Компромисс – включайте дизайн, но не требуйте, чтобы реализация точно ему следовала

TEKAMA


Шаблоны спецификации требований ПО
• Существуют различные шаблонов
• Наиболее распространенные
– IEEE 830-1998 “Рекомендованный IEEE метод создания
спецификации требований к ПО”
– ГОСТ 34.602-89
– Применимы для большинства проектов, но имеет свои
ограничения
– Громоздкий
– Нечеткие элементы
• Шаблон – не догма
– Изменяйте при желании в соответствии с природой и
потребностями своего проекта
TEKAMA


Шаблон спецификации требований к ПО
IEEE 830-1998

1. Введение
1.1 Назначение 4. Требования к внешнему интерфейсу
1.2 Соглашения по документам 4.1 Интерфейсы пользователя
1.3 Предполагаемая аудитория 4.2 Интерфейсы оборудования
1.4 Границы проекта 4.3 Интерфейсы ПО
1.5 Ссылки 4.4 Интерфейсы передачи информации

8. Общее описание 5. Другие нефункциональные требования
2.1 Обзор продукта 5.1 Требования к производительности
2.2 Свойства продукта 5.2 Требования к безопасности
2.3 Классы и характеристики пользователей 5.3 Требования к защищенности
2.4 Операционная среда 5.4 Атрибуты качества
2.5 Ограничения дизайна и реализация
2.6 Документация для пользователей 14. Остальные требования
2.7 Предложения и зависимости
Приложение А: Словарь терминов
17. Свойства системы Приложение Б: Аналитические модели
3.x Свойство системы Х Приложение В: Список вопросов
3.x.1 Описание и приоритет
3.x.2 Последовательность «воздействие-реакция»
3.x.3 Функциональные требования

TEKAMA


Техническое задание (ГОСТ 19.201-78.
ЕСПД)
Введение
Основания для разработки
Назначение
Требования к программе или программному изделию:
- требования к функциональным характеристикам
- требования к надежности и устойчивому функционированию.
- условия эксплуатации.
- требования к составу и параметрам технических средств
- требования к информационной и программной совместимости
- требования к маркировке и упаковке
- требования к транспортированию и хранению.
Требования к программной документации
Технико-экономические показатели
Стадии и этапы разработки
Порядок контроля и приемки

TEKAMA


ГОСТ 19.201 vs. IEEE Std. 830
В техническом задании, в отличии от
спецификации требований:
– программа – это материальный объект
– упор на структуру документа
– дается один вариант структуры документа
– нет критериев качества требований
– предлагается включать требования к проекту

TEKAMA


ГОСТ 34.602-89 Техническое задание на
создание автоматизированной системы
Общие положения
• ТЗ на АС является основным документом, определяющим требования
и порядок создания автоматизированной системы, в соответствии с
которым проводится разработка АС и ее приемка при вводе в
действие.
• Изменения к ТЗ на АС оформляют дополнением или подписанным
заказчиком и разработчиком протоколом. Дополнение или указанный
протокол являются неотъемлемой частью ТЗ на АС. На титульном
листе ТЗ на АС должна быть запись “Действует с ... ”.

TEKAMA


ГОСТ 34.602-89
• Общие сведения
• Назначение и цели создания (развития) системы
• Характеристика объектов автоматизации
• Требования к системе
– требования к системе в целом
– требования к функциям (задачам), выполняемым системой
– требования к видам обеспечения
• Состав и содержание работ по созданию системы
• Порядок контроля и приемки системы
• Требования к составу и содержанию работ по подготовке объекта
автоматизации к вводу системы в действие
• Требования к документированию
• Источники разработки
TEKAMA


ГОСТ 34.602-89
Раздел “Требования к системе” состоит из следующих подразделов:
• требования к системе в целом;
• требования к функциям (задачам), выполняемым системой;
• требования к видам обеспечения.
Раздел “Состав и содержание работ по созданию (развитию) системы” должен
содержать перечень стадий и этапов работ по созданию системы в
соответствии с ГОСТ 34.601, сроки их выполнения, перечень организаций —
исполнителей работ, ссылки на документы, подтверждающие согласие этих
организаций на участие в создании системы, или запись, определяющую
ответственного (заказчик или разработчик) за проведение этих работ. В
данном разделе также приводят:
• перечень документов, по ГОСТ 34.201, предъявляемых по окончании
соответствующих стадий и этапов работ;
• вид и порядок проведения экспертиза технической документации (стадия,
этап, объем проверяемой 'документации, организация-эксперт);
TEKAMA


ГОСТ 34.602-89
В разделе “Требования к документированию” приводят:
• согласованный разработчиком и Заказчиком системы перечень
подлежащих разработке комплектов и видов документов,
соответствующих требованиям ГОСТ 34.201;
В состав ТЗ на АС при наличии утвержденных методик включают
приложения, содержащие:
• расчет ожидаемой эффективности системы;
• оценку научно-технического уровня системы.

TEKAMA


ГОСТ 34.602-89
Утверждение ТЗ на АС осуществляют руководители предприятий
(организаций) разработчика и заказчика системы.
Замечания по проекту ТЗ на АС должны быть представлены с
техническим обоснованием.
Если при согласовании проекта ТЗ на АС возникли разногласия между
разработчиком и заказчиком (или другими заинтересованными
организациями), то составляется протокол разногласий
Копии утвержденного ТЗ на АС в 10-дневный срок после утверждения
высылаются разработчиком ТЗ на АС участникам создания системы.

TEKAMA


Смутно пишут о том, что смутно себе
представляют.
Михаил Ломоносов

TEKAMA


Рекомендации по созданию хороших
спецификаций
• Придерживайтесь следующих рекомендаций при создании документа
требований:
– Используйте полные предложения, с правильной грамматикой и правописанием
– Предложения и абзацы должны быть краткими, ясными и контекстно-
независимыми
– Используйте действительный залог («система делает то-то»)
– Последовательно используйте термины, как они определены в глоссарии
– Нечеткие требования верхнего уровня следует детализировать таким образом,
Чтоб они стали четкими и недвусмысленными
– Используйте глаголы «будет» или «должна», но избегайте «следовало бы», «может
быть», «можно было бы».
– Определяйте, где возможно, конкретные действующие лица (<администратор...>)
– Применяйте списки, таблицы, рисунки, графики для визуального представления
информации
– Выделяйте наиболее важные фрагменты информации (графические символы,
цвета, пробелы, затенение, и т.п.)
– Избегайте нечетких и субъективных терминов

TEKAMA


Понятно ли написана спецификация
• Спецификация требований к ПО предназначена для
различной аудитории. Следуйте следующим
рекомендациям, чтобы сделать ее понятной:
– Помечайте единообразно все разделы, подразделы и отдельные
требования
– Используйте пробелы в достаточном количестве
– Используйте согласованно визуальное выделение (полужирный, курсив,
подчеркивание)
– Создайте оглавление и индекс
– Нумеруйте все таблицы и изображения, используйте заголовки
– По возможности используете гиперссылки между разделами
– Используйте подходящие шаблоны

TEKAMA


Избегайте неоднозначных терминов

Неоднозначные термины Способы их улучшения
Приемлемый, адекватный • Определите, что понимается под приемлемостью,
и как система это может оценить
Между • Определите, включены ли конечные точки в диапазон
Гибкий • Опишите способы изменения системы в ответ на изменения
условий
Необязательно • Укажите, кто делает выбор: система, пользователь или разработчик
Несколько • Укажите сколько или задайте мин/макс границы диапазона
Эффективный • Определите, насколько эффективно система использует ресурсы

Удобный для пользователя • Опишите характеристики системы, которые обеспечивают
ожидания пользователя в отношении использования
Быстрый, моментальный • Укажите минимальную приемлемую скорость системы при
выполнении определенного действия
Надежная • Определите, как система обрабатывает исключения и
Улучшенный, лучше, непредвиденные операции
•Определите насколько лучше или быстрее стало
быстрее, превосходящий соответствующее улучшение
TEKAMA


Создание хороших требований

Упражнение

TEKAMA


Визуальное моделирование

TEKAMA


Одно изображение стоит 1024 слова
• Никакое представление требований в одном виде не дает полного
понимания
– Сочетание визуального и текстового способов представления помогает
обнаружить противоречия, неоднозначности и пропуски
– В идеале различные типы преставлений должны создавать разные люди
– Диаграммы передают определенные вещи более эффективно, чем текст
– Изображения помогают преодолеть языковые барьеры и терминологические
разногласия
• Визуальное моделирование будет полезно для исследования и
уточнения требований, а также для проектирования программных
решений
• При моделировании сосредоточьтесь на наиболее сложных и
рискованных частях системы (безопасность, защита, критически
важные компоненты будут хорошими кандидатами)

TEKAMA


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

Тип слова Примеры Возможная аналитическая модель

Люди, организации,  Действующие лица (диаграммы вариантов
Существительное программные системы, использования)
элементы данных или  Объекты или их атрибуты (диаграммы «сущность-
объекты связь»)
 Классы или их атрибуты (диаграммы классов)

Действия, задачи, которые  Процессы (диаграммы потока данных )
Глагол пользователь может  Варианты использования (диаграммы вариантов
выполнить, или события, использования)
которые могут произойти  Взаимосвязи (диаграммы «сущность-связь»)
 Переходы (диаграммы перехода состояний)
 Действия (диаграммы действий)

TEKAMA


Аналитические модели
Пример

• Химик может разместить заказ на химикат. Заказ может быть выполнен
доставкой контейнера с химикатом со склада химикатов или размещением
заказа у внешнего поставщика.

Складское
Складское
помещение
помещение

1 1 Запрос
Запрос
выполняет химиката
химиката

Часть диаграммы хранит M

«сущность-связь»
M

Контейнер
Контейнер M 1
с
с содержит Химикат
Химикат
химикатами
химикатами

TEKAMA


Аналитические модели
Пример
Частичная диаграмма
перехода состояний Система принимает
действительный запрос

Запрос
выполняется на
 Прямоугольники –
складе Принят возможные состояния
 Стрелки – переходы
Покупатель размещает состояния
заказ у поставщика  Текстовые метки – События
Заказ получен от или условия вызывающие
поставщика
Размещен переходы

Поставщик помещает
заказ в невыполненные
Заказ получен
от
поставщика Заказ ожидает
Выполнен выполнения

TEKAMA


Текстовое – визуальное
упражнение
Превратите следующий параграф в
визуальную модель

TEKAMA


Проверка правильности
Посмотрим видеоклип

TEKAMA


‘V’-модель разработки ПО

Пользовательские
Приемочные испытания
требования; планирование
приемочных испытаний
Функциональные требования; Тестирование системы
Планирование тестирования
системы
Архитектура; планирование Проверка целостности
проверки целостности Время

Дизайн; планирование тестирования Тестирование элементов
элементов

Написание кода

TEKAMA


Необходимость проверки правильности
• Немного статистики (основана на современных
исследованиях):
– Каждый доллар, истраченный на предотвращение
появления дефектов, снизит затраты на исправление на
сумму от 3 до 10 долларов
– Каждый час, затраченный на проверку требований, сохранит
10 часов при последующей доработке
• Проверяйте постоянно, процесс никогда не прекращается

TEKAMA


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

TEKAMA


Рецензирование требований
• Две основные категории
– Неформальные рецензии (сбор соответствующих
неструктурированных отзывов)
• Проверка коллегой
• Коллективная проверка
• Критическая проверка
– Формальные рецензии (сбор отзывов в соответствии
с хорошо регламентированным процессом)
• Экспертиза

TEKAMA


Скорость экспертизы
Количество недостатков на

Много

Умеренно
страницу

Мало

Маленькая Средняя Большая
Скорость экспертизы (Страниц / Час)

TEKAMA


Правила проведения экспертизы
• 1-2 страницы в час считается оптимальной скоростью для наиболее
эффективного обнаружения дефектов
• 2-4 страницы в час является практической рекомендацией
• Корректируйте норму экспертизы, основываясь на:
– Объеме текста на каждой странице
– Сложности спецификации
– Рисках, связанных с пропуском ошибок
– Критичность материала экспертизы для успешного завершения проекта
– Квалификации человека, который написал спецификацию требований для ПО
• Начинайте экспертизу когда спецификация требований к ПО будет выполнена
на 10-15%.
• Если не хватает времени, используйте анализ рисков для определения с чего
начать экспертизу

TEKAMA


Проблемы рецензирования требований
...и как их решать
• Большой объем документов
– Чтобы избежать этого, рецензируйте постоянного небольшие фрагменты
– Сначала рассматривайте наиболее рискованные элементы
– Попросите людей рассмотреть различные части документов
– Оцените необходимость полной проверки на основе похожих документов
• Большая команда экспертов
– ориентируйте команду на поиск ошибок, а не политику
– избегайте дублирования групп уже представленных пользователей
– создавайте небольшие команды и сравнивайте результаты
• Географическое разделение экспертов
– используйте доступные технологии (видео, телефон, общий доступ к файлам)
– остерегайтесь 25% сокращения эффективности ... но помните также о сокращении
расходов

TEKAMA


Тестирование требований
• Тестирование «черного ящика» (функциональное)
– Как ведет себя система в различных ситуациях
• Можно генерировать варианты тестирования из вариантов
использования или требований пользователей
• Нужно тестировать все, начиная от текстовых требований, и до
аналитических моделей и прототипов
• Тестирование должно охватывать
– Нормальное выполнение
– Отклоняющееся от нормы, но разумное использование функции
– Отклоняющееся от нормы, и неразумное использование функции

TEKAMA


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

TEKAMA


Рекомендуемая литература
• Practical Software Requirements, Benjamin Kovitz,
1998
• Software Inspections, Tom Gilb and Dorothy Graham
1993
• Handbook of Walkthroughs, Inspections, and
Technical Reviews: Evaluating Programs, Projects,
and Products, by Daniel P. Freedman and Gerald M.
Weinberg, 1990

TEKAMA


Вопросы?

TEKAMA

L3 requirements

More Related Content

What's hot (20)

Viewers also liked (20)

Similar to L3 requirements (20)

More from Natalia Zhelnova (20)

L3 requirements

Editor's Notes