l3 requirements

52
3 T E K A M A 3-1 Software Engineering Professional Program © 2007. Документирование требований Документирование и организация требований

Upload: natalia-zhelnova

Post on 15-Jun-2015

445 views

Category:

Documents


1 download

TRANSCRIPT

Page 1: L3 requirements

3T E K A M A

3-1Software Engineering Professional Program © 2007.

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

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

Page 2: L3 requirements

T E K A M A3-2Software Engineering Professional Program © 2007.

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

• Документирование требований c помощью

общепринятых шаблонов и форматов

• Рассмотрение различных способов

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

• Обеспечение качества требований

Цели и задачи

Page 3: L3 requirements

T E K A M A3-3Software Engineering Professional Program © 2007.

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

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

Если этого нет на бумаге,

значит этого не существует

Любимая аксиома Алана Купера

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

Page 4: L3 requirements

T E K A M A3-4Software Engineering Professional Program © 2007.

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

• Какие существуют стандартные шаблоны для

документирования требований и зачем их

использовать?

• Какие существуют способы описания требований

помимо текстового?

• Как выполняется проверка правильности

требований?

Вопросы для размышления

Page 5: L3 requirements

T E K A M A3-5Software Engineering Professional Program © 2007.

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

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

Бизнес потребности

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

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

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

варианты использования

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

Page 6: L3 requirements

T E K A M A3-6Software Engineering Professional Program © 2007.

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

Организация требований – 1

• Следующий шаг после сбора требований – их документирование

– Родственные группы – наборы сходных элементов• Элементы, связанные концептуально

• Элементы, связанные общей тематикой (функция, средство, и т.п.)

– Иерархии – упорядоченные зависимости• Нижестоящие элементы подчиняются вышестоящим

элементам

• Нижестоящие элементы развивают или дополнительно уточняют вышестоящие элементы

Page 7: L3 requirements

T E K A M A3-7Software Engineering Professional Program © 2007.

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

Организация требований– 2

• Последовательность организации требований состоит из

трех шагов

– Поделить требования на родственные группы

– Иерархически структурировать каждую группу

– Распознать пробелы

• Пробелы и несогласованность могут потребовать

дополнительного анализа и/или выявления

дополнительных требований

Page 8: L3 requirements

T E K A M A3-8Software Engineering Professional Program © 2007.

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

Группирование требований• Чтобы сгруппировать требования

– Просмотрите потребности или идеи

– Идентифицируйте независимые темы – каждая тема

определяет группу

– Дайте каждой группе обычное словесное описание• Объясните потребность высшего уровня

• Объясните специфические требования

Page 9: L3 requirements

T E K A M A3-9Software Engineering Professional Program © 2007.

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

Иерархия требований

• Организуйте каждую группу иерархически– приоритет

– схема именования

– высший/низший уровни абстракции

– определите ограничения

– разработайте древовидную структуру

– добавьте новую информацию, если необходимо

Page 10: L3 requirements

T E K A M A3-10Software Engineering Professional Program © 2007.

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

Методы документирования требований

• Хорошо структурированные документы на

обычном языке

• Графические модели, поясняющие

трансформационные процессы, системные и

переходные состояния, взаимосвязи данных,

логические выводы, классы объектов и т.п.

• Формальные спецификации, определяющие

требования с помощью математической логики

Page 11: L3 requirements

T E K A M A3-11Software Engineering Professional Program © 2007.

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

Документы на основе требований – 1

• При разработке требований могут создаваться все

или только некоторые из следующих документов

– Состав и распределение работ

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

– Концепция эксплуатации

– Начальный план разработки ПО

– Критерии принятия работ

Page 12: L3 requirements

T E K A M A3-12Software Engineering Professional Program © 2007.

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

Документы на основе требований – 2

• Всегда ли надо создавать все эти документы?

– Слишком много правил означает, что правил нет

– Названия не важны – важна информация

• Необходимо ответить на следующие вопросы:

Что должна делать система? Какими качественными

характеристиками должна она

обладать? Какие существуют ограничения? Кто и за что несет ответственность?

Как система работает в операционной

среде? Как вы будете создавать систему? Что значит успешно выполнить работу?

Page 13: L3 requirements

T E K A M A3-13Software Engineering Professional Program © 2007.

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

Состав и распределение работ

• Распределяет ответственности между

заинтересованными сторонами проекта

– Кто создает, что и когда

– Кто тестирует, что, как и когда

– Кто платит, за что и когда

– Кто докладывает кому

– Кто принимает/утверждает завершение работ

– Кто, как и когда санкционирует изменения

– И т.п.

Page 14: L3 requirements

T E K A M A3-14Software Engineering Professional Program © 2007.

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

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

• Спецификация требований создается после анализа

требований

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

– Функции, которые система должна выполнять

– Ограничения• Технические, временные, бюджетные

– Характеристики качества

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

Page 15: L3 requirements

T E K A M A3-15Software Engineering Professional Program © 2007.

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

Концепция эксплуатации

• Концепция эксплуатации - описание того, как система

должна работать или будет использоваться в контексте

организации

– какие функции будут использоваться и кем

– как эти функции будут использоваться

– в каких условиях эти функции будут использоваться

– как будет происходить ввод/вывод данных

– как система взаимодействует с другими системами

• Задает основу для разработки вариантов использования

Page 16: L3 requirements

T E K A M A3-16Software Engineering Professional Program © 2007.

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

Начальный план разработки ПО

• Это первая попытка распределить предполагаемые

работы по времени

– Основные обзоры

– Основные документы

– Точки принятия решений

– Поставляемые продукты

– Этапы работ и контрольные точки

– Графики платежей

• Это высокоуровневый и приблизительный план

Page 17: L3 requirements

T E K A M A3-17Software Engineering Professional Program © 2007.

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

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

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

Аристотель

Page 18: L3 requirements

T E K A M A3-18Software Engineering Professional Program © 2007.

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

Основы• Фундамент всего последующего планирования, проектирования и

написания кода проекта

• Основание для тестирования системы и документации пользователя

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

• Не должна содержать деталей проектирования, реализации, тестирования или управления проектом, за исключением ограничений

• Должна быть максимально всесторонней и полной

• Не должна быть написана сразу для всего продукта до начала разработки… но должна как минимум определять требования на ближайшую итерацию

• Является исходным соглашением между заказчиком и разработчиком (должна быть утверждена заказчиком)

Page 19: L3 requirements

T E K A M A3-19Software Engineering Professional Program © 2007.

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

Риски отсутствия спецификации

• Риск разного понимания требований разными

участниками разработки;

• Опасность сделать ПО, не отвечающее

потребностям заказчика или покупателя;

• Риск неоплаты усилий разработчиков;

• Неправильная оценка трудоемкости и сроков;

• Незащищенность проекта от смены

разработчиков.

Page 20: L3 requirements

T E K A M A3-20Software Engineering Professional Program © 2007.

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

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

• Описывает решения (дизайн), а не требования

• Может задержать создание основной спецификации требований к ПО

• Компоновка экранов не заменяет функциональных требований

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

• Рассмотрение интерфейса пользователя (UI) вместе с прототипами делает требования реальными для разработчиков и пользователей

• Может помочь при планировании проекта и оценке

• Может улучшить коммуникацию

Компромисс – включайте дизайн, но не требуйте, чтобы реализация точно ему следовала

Page 21: L3 requirements

T E K A M A3-21Software Engineering Professional Program © 2007.

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

Шаблоны спецификации требований ПО

• Существуют различные шаблонов

• Наиболее распространенные

– IEEE 830-1998 “Рекомендованный IEEE метод создания

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

– ГОСТ 34.602-89

– Применимы для большинства проектов, но имеет свои

ограничения

– Громоздкий

– Нечеткие элементы

• Шаблон – не догма

– Изменяйте при желании в соответствии с природой и

потребностями своего проекта

Page 22: L3 requirements

T E K A M A3-22Software Engineering Professional Program © 2007.

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

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

1. Введение1.1 Назначение1.2 Соглашения по документам1.3 Предполагаемая аудитория1.4 Границы проекта1.5 Ссылки

2. Общее описание2.1 Обзор продукта2.2 Свойства продукта2.3 Классы и характеристики пользователей2.4 Операционная среда2.5 Ограничения дизайна и реализация2.6 Документация для пользователей2.7 Предложения и зависимости

3. Свойства системы3.x Свойство системы Х3.x.1 Описание и приоритет3.x.2 Последовательность «воздействие-реакция»3.x.3 Функциональные требования

4. Требования к внешнему интерфейсу4.1 Интерфейсы пользователя4.2 Интерфейсы оборудования4.3 Интерфейсы ПО4.4 Интерфейсы передачи информации

5. Другие нефункциональные требования5.1 Требования к производительности5.2 Требования к безопасности5.3 Требования к защищенности 5.4 Атрибуты качества

6. Остальные требования

Приложение А: Словарь терминовПриложение Б: Аналитические модели Приложение В: Список вопросов

Page 23: L3 requirements

T E K A M A3-23Software Engineering Professional Program © 2007.

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

Техническое задание (ГОСТ 19.201-78. ЕСПД)Введение

Основания для разработки

Назначение

Требования к программе или программному изделию:

- требования к функциональным характеристикам

- требования к надежности и устойчивому функционированию.

- условия эксплуатации.

- требования к составу и параметрам технических средств

- требования к информационной и программной совместимости

- требования к маркировке и упаковке

- требования к транспортированию и хранению.

Требования к программной документации

Технико-экономические показатели

Стадии и этапы разработки

Порядок контроля и приемки

Page 24: L3 requirements

T E K A M A3-24Software Engineering Professional Program © 2007.

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

ГОСТ 19.201 vs. IEEE Std. 830

В техническом задании, в отличии от

спецификации требований:– программа – это материальный объект

– упор на структуру документа

– дается один вариант структуры документа

– нет критериев качества требований

– предлагается включать требования к проекту

Page 25: L3 requirements

T E K A M A3-25Software Engineering Professional Program © 2007.

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

ГОСТ 34.602-89 Техническое задание на создание автоматизированной системыОбщие положения

• ТЗ на АС является основным документом, определяющим требования

и порядок создания автоматизированной системы, в соответствии с

которым проводится разработка АС и ее приемка при вводе в

действие.

• Изменения к ТЗ на АС оформляют дополнением или подписанным

заказчиком и разработчиком протоколом. Дополнение или указанный

протокол являются неотъемлемой частью ТЗ на АС. На титульном

листе ТЗ на АС должна быть запись “Действует с ... ”.

Page 26: L3 requirements

T E K A M A3-26Software Engineering Professional Program © 2007.

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

ГОСТ 34.602-89• Общие сведения

• Назначение и цели создания (развития) системы

• Характеристика объектов автоматизации

• Требования к системе

– требования к системе в целом

– требования к функциям (задачам), выполняемым системой

– требования к видам обеспечения

• Состав и содержание работ по созданию системы

• Порядок контроля и приемки системы

• Требования к составу и содержанию работ по подготовке объекта

автоматизации к вводу системы в действие

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

• Источники разработки

Page 27: L3 requirements

T E K A M A3-27Software Engineering Professional Program © 2007.

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

ГОСТ 34.602-89Раздел “Требования к системе” состоит из следующих подразделов:

• требования к системе в целом;

• требования к функциям (задачам), выполняемым системой;

• требования к видам обеспечения.

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

• перечень документов, по ГОСТ 34.201, предъявляемых по окончании соответствующих стадий и этапов работ;

• вид и порядок проведения экспертиза технической документации (стадия, этап, объем проверяемой 'документации, организация-эксперт);

Page 28: L3 requirements

T E K A M A3-28Software Engineering Professional Program © 2007.

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

ГОСТ 34.602-89

В разделе “Требования к документированию” приводят:

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

В состав ТЗ на АС при наличии утвержденных методик включают приложения, содержащие:

• расчет ожидаемой эффективности системы;

• оценку научно-технического уровня системы.

Page 29: L3 requirements

T E K A M A3-29Software Engineering Professional Program © 2007.

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

ГОСТ 34.602-89

Утверждение ТЗ на АС осуществляют руководители предприятий

(организаций) разработчика и заказчика системы.

Замечания по проекту ТЗ на АС должны быть представлены с

техническим обоснованием.

Если при согласовании проекта ТЗ на АС возникли разногласия между

разработчиком и заказчиком (или другими заинтересованными

организациями), то составляется протокол разногласий

Копии утвержденного ТЗ на АС в 10-дневный срок после утверждения

высылаются разработчиком ТЗ на АС участникам создания системы.

Page 30: L3 requirements

T E K A M A3-30Software Engineering Professional Program © 2007.

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

Смутно пишут о том, что смутно себе

представляют.

Михаил Ломоносов

Page 31: L3 requirements

T E K A M A3-31Software Engineering Professional Program © 2007.

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

Рекомендации по созданию хороших спецификаций• Придерживайтесь следующих рекомендаций при создании документа

требований: – Используйте полные предложения, с правильной грамматикой и правописанием – Предложения и абзацы должны быть краткими, ясными и контекстно-

независимыми– Используйте действительный залог («система делает то-то»)– Последовательно используйте термины, как они определены в глоссарии– Нечеткие требования верхнего уровня следует детализировать таким образом,

Чтоб они стали четкими и недвусмысленными– Используйте глаголы «будет» или «должна», но избегайте «следовало бы», «может

быть», «можно было бы». – Определяйте, где возможно, конкретные действующие лица (<администратор...>) – Применяйте списки, таблицы, рисунки, графики для визуального представления

информации– Выделяйте наиболее важные фрагменты информации (графические символы,

цвета, пробелы, затенение, и т.п.)– Избегайте нечетких и субъективных терминов

Page 32: L3 requirements

T E K A M A3-32Software Engineering Professional Program © 2007.

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

Понятно ли написана спецификация

• Спецификация требований к ПО предназначена для

различной аудитории. Следуйте следующим

рекомендациям, чтобы сделать ее понятной:– Помечайте единообразно все разделы, подразделы и отдельные

требования

– Используйте пробелы в достаточном количестве

– Используйте согласованно визуальное выделение (полужирный, курсив,

подчеркивание)

– Создайте оглавление и индекс

– Нумеруйте все таблицы и изображения, используйте заголовки

– По возможности используете гиперссылки между разделами

– Используйте подходящие шаблоны

Page 33: L3 requirements

T E K A M A3-33Software Engineering Professional Program © 2007.

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

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

Неоднозначные термины Способы их улучшения

Приемлемый, адекватныйМежду

Гибкий

НеобязательноНесколько

Эффективный

Удобный для пользователя

Быстрый, моментальный

НадежнаяУлучшенный, лучше, быстрее, превосходящий

• Определите, что понимается под приемлемостью, и как система это может оценить

• Определите, включены ли конечные точки в диапазон• Опишите способы изменения системы в ответ на изменения

условий

• Укажите, кто делает выбор: система, пользователь или разработчик

• Укажите сколько или задайте мин/макс границы диапазона

• Определите, насколько эффективно система использует ресурсы

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

• Укажите минимальную приемлемую скорость системы при выполнении определенного действия

• Определите, как система обрабатывает исключения и непредвиденные операции

•Определите насколько лучше или быстрее стало соответствующее улучшение

Page 34: L3 requirements

T E K A M A3-34Software Engineering Professional Program © 2007.

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

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

Упражнение

Page 35: L3 requirements

T E K A M A3-35Software Engineering Professional Program © 2007.

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

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

Page 36: L3 requirements

T E K A M A3-36Software Engineering Professional Program © 2007.

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

Одно изображение стоит 1024 слова

• Никакое представление требований в одном виде не дает полного

понимания

– Сочетание визуального и текстового способов представления помогает

обнаружить противоречия, неоднозначности и пропуски

– В идеале различные типы преставлений должны создавать разные люди

– Диаграммы передают определенные вещи более эффективно, чем текст

– Изображения помогают преодолеть языковые барьеры и терминологические

разногласия

• Визуальное моделирование будет полезно для исследования и

уточнения требований, а также для проектирования программных

решений

• При моделировании сосредоточьтесь на наиболее сложных и

рискованных частях системы (безопасность, защита, критически

важные компоненты будут хорошими кандидатами)

Page 37: L3 requirements

T E K A M A3-37Software Engineering Professional Program © 2007.

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

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

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

Существительное

Глагол

Люди, организации, программные системы, элементы данных или объекты

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

Действующие лица (диаграммы вариантов использования)

Объекты или их атрибуты (диаграммы «сущность-связь»)

Классы или их атрибуты (диаграммы классов)

Процессы (диаграммы потока данных ) Варианты использования (диаграммы вариантов

использования) Взаимосвязи (диаграммы «сущность-связь») Переходы (диаграммы перехода состояний) Действия (диаграммы действий)

Page 38: L3 requirements

T E K A M A3-38Software Engineering Professional Program © 2007.

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

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

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

Контейнер с

химикатами

Запрос химиката

хранит

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

выполняет

содержит Химикат

M

1

M 1

1

MЧасть диаграммы «сущность-связь»

Контейнер с

химикатами

Запрос химиката

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

Химикат

Page 39: L3 requirements

T E K A M A3-39Software Engineering Professional Program © 2007.

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

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

Принят

Частичная диаграмма перехода состояний

Заказ ожидает выполнения

Выполнен

Система принимает действительный запрос

Покупатель размещаетзаказ у поставщика

Поставщик помещает заказ в невыполненные

Заказ получен от поставщика

Запрос выполняется на

складе

Заказ получен от

поставщика

Размещен

Прямоугольники – возможные состояния

Стрелки – переходы состояния

Текстовые метки – События или условия вызывающие переходы

Page 40: L3 requirements

T E K A M A3-40Software Engineering Professional Program © 2007.

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

Текстовое – визуальное упражнение

Превратите следующий параграф в

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

Page 41: L3 requirements

T E K A M A3-41Software Engineering Professional Program © 2007.

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

Проверка правильности требований

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

Page 42: L3 requirements

T E K A M A3-42Software Engineering Professional Program © 2007.

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

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

Тестирование элементов

Проверка целостности

Тестирование системы

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

Функциональные требования;Планирование тестированиясистемы

Архитектура; планированиепроверки целостности

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

Время

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

Page 43: L3 requirements

T E K A M A3-43Software Engineering Professional Program © 2007.

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

Необходимость проверки правильности требований• Немного статистики (основана на современных

исследованиях):

– Каждый доллар, истраченный на предотвращение

появления дефектов, снизит затраты на исправление на

сумму от 3 до 10 долларов

– Каждый час, затраченный на проверку требований, сохранит

10 часов при последующей доработке

• Проверяйте постоянно, процесс никогда не прекращается

Page 44: L3 requirements

T E K A M A3-44Software Engineering Professional Program © 2007.

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

Польза от проверки правильности требований• На шаге проверки правильности удостоверяются что:

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

характеристики и возможности, которые отвечают потребностям

пользователей

– Требования к ПО правильно отражают бизнес-правила, системные

требования, и др.

– Требования полны и высококачественны

– Все представления требований согласованы друг с другом

– Требования обеспечивают хорошую основу для проектирования и

реализации.

Page 45: L3 requirements

T E K A M A3-45Software Engineering Professional Program © 2007.

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

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

• Две основные категории

– Неформальные рецензии (сбор соответствующих

неструктурированных отзывов)• Проверка коллегой

• Коллективная проверка

• Критическая проверка

– Формальные рецензии (сбор отзывов в соответствии

с хорошо регламентированным процессом)• Экспертиза

Page 46: L3 requirements

T E K A M A3-46Software Engineering Professional Program © 2007.

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

Скорость экспертизы

Маленькая

Умеренно

Большая

Мало

Много

Средняя

Скорость экспертизы (Страниц / Час)

Кол

ичес

тво

недо

стат

ков

на

стра

ницу

Page 47: L3 requirements

T E K A M A3-47Software Engineering Professional Program © 2007.

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

Правила проведения экспертизы• 1-2 страницы в час считается оптимальной скоростью для наиболее

эффективного обнаружения дефектов

• 2-4 страницы в час является практической рекомендацией

• Корректируйте норму экспертизы, основываясь на:

– Объеме текста на каждой странице

– Сложности спецификации

– Рисках, связанных с пропуском ошибок

– Критичность материала экспертизы для успешного завершения проекта

– Квалификации человека, который написал спецификацию требований для ПО

• Начинайте экспертизу когда спецификация требований к ПО будет выполнена

на 10-15%.

• Если не хватает времени, используйте анализ рисков для определения с чего

начать экспертизу

Page 48: L3 requirements

T E K A M A3-48Software Engineering Professional Program © 2007.

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

Проблемы рецензирования требований ...и как их решать• Большой объем документов

– Чтобы избежать этого, рецензируйте постоянного небольшие фрагменты

– Сначала рассматривайте наиболее рискованные элементы

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

– Оцените необходимость полной проверки на основе похожих документов

• Большая команда экспертов

– ориентируйте команду на поиск ошибок, а не политику

– избегайте дублирования групп уже представленных пользователей

– создавайте небольшие команды и сравнивайте результаты

• Географическое разделение экспертов

– используйте доступные технологии (видео, телефон, общий доступ к файлам)

– остерегайтесь 25% сокращения эффективности ... но помните также о сокращении

расходов

Page 49: L3 requirements

T E K A M A3-49Software Engineering Professional Program © 2007.

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

Тестирование требований• Тестирование «черного ящика» (функциональное)

– Как ведет себя система в различных ситуациях

• Можно генерировать варианты тестирования из вариантов использования или требований пользователей

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

• Тестирование должно охватывать– Нормальное выполнение

– Отклоняющееся от нормы, но разумное использование функции

– Отклоняющееся от нормы, и неразумное использование функции

Page 50: L3 requirements

T E K A M A3-50Software Engineering Professional Program © 2007.

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

Заключение

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

для последующего планирования, проектирования и

программирования и должна быть создана в

соответствии с определенными принципами

• Существует множество способов описания

функциональных требований, которые могут

облегчить понимание требований

• По окончании создания требований, они должны

быть проверены на правильность и утверждены

Page 51: L3 requirements

T E K A M A3-51Software Engineering Professional Program © 2007.

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

Рекомендуемая литература

• 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

Page 52: L3 requirements

T E K A M A3-52Software Engineering Professional Program © 2007.

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

Вопросы?