1. Анализ требований к
программному обеспечению

2. Литература
• Карл И. Вигерс. Разработка требований к
программному обеспечению. — Русская
редакция, 2004.
• Леффингуелл Д., Уидриг Д. Принципы
работы с требованиями к программному
обеспечению. — М.: Вильямс, 2002.
• Кобёрн А. Современные методы описания
функциональных требований к системам. —
М.: Лори, 2002.
• Пер Кролл, Филипп Крачтен. Rational Unified
Process - это легко. Руководство по RUP для
практиков

3. Анализ требований к ПО
Анализ требований к ПО – это процесс
• сбора требований к программному обеспечению,
• систематизации требований,
• документирования требований,
• анализа, выявления противоречий, неполноты
требований,
• разрешения конфликтов в процессе разработки
программного обеспечения.
В англоязычной среде также говорят о дисциплине
«инженерия требований» (англ. Requirements
Engineering).

4. Типы деятельности при анализе
требований к ПО
• Сбор требований: общение с клиентами и
пользователями, чтобы определить, каковы их
требования.
• Анализ требований: определение, являются ли
собранные требования неясными, неполными,
неоднозначными, или противоречащими, и затем
решение этих проблем.
• Документирование требований: Требования могут
быть задокументированы в различных формах, таких
как простое описание, сценарии использования,
пользовательские истории, или спецификации
процессов.
• Управление требованиями.

5. Понятие «требование к ПО»
•
SWEBOK (Software Engineering Body of Knowledge) Программные требования (Software
Requirements) – свойства программного обеспечения, которые должны быть надлежащим
образом представлены в нем для решения конкретных практических задач.
•
RUP (Rational Unified Process) Требование – это условие или возможность, которой должна
соответствовать система
•
IEEE (I triple E, Institute of Electrical and Electronics Engineers, Институт инженеров по
электротехнике и электронике) Standard Glossary of Software Engineering Terminology
(1990)
1.
2.
3.
•
Дорфман (Dorfman), Тэйер (Thayer) (Леффингуэлл. Принципы работы с требованиями
ПО)
1.
2.
•
условия или возможности, необходимые пользователю для решения проблем или достижения
целей;
условия или возможности, которыми должна обладать система или системные компоненты, чтобы
выполнить контракт или удовлетворять стандартам, спецификациям или другим формальным
документам;
документированное представление условий или возможностей для пунктов 1 и 2.
Некое свойство программного обеспечения, необходимое пользователю для решения проблемы
при достижении поставленной цели.
Некое свойство программного обеспечения, которым должна обладать система или ее компонент,
чтобы удовлетворять условиям контракта, стандарта, спецификации или другой формальной
документации.
Ian Sommerwille &Pete Sawyer Требования – это спецификация того, что должно быть
получено. Требования описывают поведение системы или атрибуты и свойства системы.
Требования могут являться и ограничениями на процесс разработки системы.

6. Классификация требований
SWEBOK - не описывает подходы к классификации
требований, а описывает возможности группировки
требований в соответствии с их характеристиками.
•
•
•
•
•
Требования к продукту и процессу
Функциональные и нефункциональные требования
Независимые свойства
Требования с количественной оценкой
Системные требования и программные требования.

7. Классификация требований
К.ВИГЕРС
Функциональные требования
требования
Бизнестребования
Нефункциональные
Документ об образе и границах проекта
Бизнесправила
Требования
пользовател
ей
Атрибуты
качества
Документ о вариантах использования
Системные
требования
Внешний
интерфейс
Функциональны
е требования
Ограничения
Спецификация требований к ПО

8. Каких требований
не должно быть!
• Деталей дизайна или реализации
• Данных о планировании проекта
• Сведений о тестировании

9. Классификация требований
Д. Леффингуэлл. Пирамида требований
Бизнес-цели
Требования пользователей
Функциональные требования

10. Заинтересованные в продукте лица
•
•
•
•
•
•
•
•
•
•
Заказчики, которые финансируют проект или приобретают продукт
для решения некоторых бизнес-задач;
Пользователи, которые взаимодействуют напрямую или не напрямую
с приложением (подкласс заказчиков);
Аналитики требований, которые пишу требования и передают их
разработчикам;
Разработчики, которые создают, разворачивают и поддерживают
продукт;
Тестеры, которые определяют соответствие поведения ПО
желаемому;
Технические писатели, которые отвечают за создание руководства
пользователей, тренировочные материалы и справочную систему.
Менеджер по проекту, который планирует процесс и руководит
командой разработчиков вплоть до успешного выпуска продукта;
Сотрудники правового отдела, которые следят, чтобы продукт не
противоречил действующим законам и постановлениям;
Производственники, которые должны построить продукт,
содержащий дано ПО;
Сотрудники отдела продажи, маркетинга, выездной службы
поддержки и другие, кому придется работать с продуктом и его
пользователями.

11. Идентификация
заинтересованного лица
•
•
•
•
•
•
•
любой, кто пользуется системой (пользователи и
обслуживающий персонал)
любой, кто извлекает выгоду из системы (функциональную,
политическую, финансовую и социальную)
любой вовлечённый в покупку или обеспечение системы
организации, которые регулируют аспекты системы
(финансовые, безопасность, и другие)
люди или организации, настроенные против системы
(отрицательные заинтересованные лица),
организации, ответственные за системы, которые
взаимодействуют с системой согласно проекту
те организации, которые объединяются горизонтально с
организацией, для которой аналитик проектирует систему

12. Особенности сбора
и анализа бизнес-требований
Продукт под заказ
Характеристики процесса:
•заказчик определен с самого начала;
•заказчику известны начальные предпосылки (стимулы) для
инициации проекта и проблемы, которые продукт должен
решить
Особенности сбора и анализа бизнес-требований:
•сбор требований начинается с определения исходных
предпосылок, целей продукта и описания сценариев работы
пользователей с будущим продуктом;
•анализ конкурентных продуктов, которые могут
удовлетворять похожие сценарии, делается в самом конце.

13. Особенности сбора
и анализа бизнес-требований
Продукт для открытого рынка
Характеристики процесса:
•сектор рынка с самого начала может быть не определен;
•цели продукта основываются на конкурентном анализе.
Особенности сбора и анализа бизнес-требований:
•сразу за определением исходных предпосылок (стимулов)
идет обзор конкурентов;
•далее идет определение целевого сегмента рынка и
потребностей его заказчиков;
•в конце определяются цели продукта и критерии его успеха.

14. Особенности сбора
и анализа бизнес-требований
Встроенные приложения
Характеристики процесса:
•зависят от того, является ли это продуктом под заказ
(например, ПО для микроволновой печи) или продуктом для
открытого рынка (например, ПО мобильных телефонов).

15. Определение стимулов
•потребность рынка;
•производственная необходимость;
•потребность заказчика;
•технический прогресс;
•юридические ограничения или нормы.

16. Определение целей продукта и
критериев успеха
•финансовые:
•Достигнуть объема продаж X единиц или дохода, равного $Y, за Z
месяцев.
•Получить Х% прибыли или дохода по инвестициям в течение Y
месяцев.
•Сэкономить Х$ в год, которые в настоящий момент расходуются на
обслуживание системы.
•Уменьшить затраты на поддержку на Х% за Z месяцев.
•Получить не более X звонков в службу обслуживания по каждой
единице товара и Y звонков по гарантии каждой единицы товара в
течение Z месяцев после выпуска товара.
•нефинансовые:
•Достигнуть показателя удовлетворения покупателей, равного, по
крайней мере, X, в течение Y месяцев со времени выпуска товара.
•Увеличить производительность обработки транзакций на Х% и
снизить уровень ошибок данных до величины не более Y%.
•Разработать надежную платформу для семьи связанных продуктов.

17. Техники выявления требований
•Мозговой штурм
•Совещания
•Интервью
•Наблюдение
•Кабинетные исследования
•Анкетирование

18. Метод мозгового штурма
1. Четкая формулировка цели и/или задач и
ограничений
2. Обеспечение максимальной свободы участникам
3. Тщательное формирование состава участников
4. Иерархическое ведение обсуждений
5. Огромная роль "ведущего" и демократический
стиль руководства

19. Метод мозгового штурма.
Основные этапы
1. Разминка
Зачем мы здесь собрались?
2. Генерирование идей
Любые идеи важны, даже самые безумные!
3. Обсуждение
Насколько эта идея поможет решить нашу
задачу?
4. Подведение итогов

20. Метод мозгового штурма.
Распределение ролей
1. Ведущий
управляет процессом;
поощряет предложение и обсуждение;
вовлекает всех участников;
поддерживает энергичность.
2. Помощник ведущего (может отсутствовать)
записывает предложения;
следит за временем;
3. Эксперт
разъясняет проблему;
отвечает на вопросы;
дает дополнительную информацию.
4. Участник
выдает предложения;
задает вопросы.

21. Метод мозгового штурма.
Метод 635
6 человек
3 идеи
5 минут

22. Метод мозгового штурма.
Метод модераций
3 карточки
Соотнесение карточки с кластером
Ранжирование кластеров

23. Совещание
1. Подготовка к совещанию
2. Проведение совещания
3. Итоги совещания

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

25. Совещание.
Проведение
• Каждый участник совещания должен иметь
возможность высказаться
• Суммирование промежуточных результатов
совещания
• Равноправие участников совещания
• Регламент выступлений и соответствие
выступлений повестке дня
• Принятие решений по каждому пункту, в случае
достижения консенсуса

26. Совещание.
Итоги
• Определение результатов совещания (задания,
ответственные за выполнение, сроки выполнения)
• Документирование результатов совещания
• Организация встречи с участниками, мнение
которых не было учтено
• Рассылка уведомлений, посвященных
дальнейшим действиям

27. Совещание. Методы проведения
1. Доклад
2. Обмен мнениями
3. Мозговой штурм
4. Обсуждение
Формат совещания по решению
проблем
•Сбор данных
•Определение проблемы и
идентификация причин
•Критерии для принятия решений
•Разработка альтернатив
.
Формат совещания по принятию
решений
•Оценка альтернатив
•Принятие решения, выбор
альтернативы
•Планирование действий по
реализации решения

28. Интервью
Формат:
•
Беседа интервьюера с
составленному плану-гайду
•
Аудио-запись беседы с последующей расшифровкой для детального
анализа либо конспектирование ответов в заранее заготовленных
шаблонах интервью
респондентом
по
предварительно
Структура вопросов интервью:
•Контекстно-свободные – помогают достичь понимания реальной
проблемы, не оказывая влияния на ответы пользователя.
Примеры:
Кто является пользователем системы?
Кто является клиентом?
Отличаются ли из потребности?
Где еще можно найти решение данной проблемы?
•Контекстно-зависимые – смещены в область исследования решений,
позволяют не только понять проблему, но и предложить подходящие
решения.

29. Пример структуры интервью(1)
Часть 1. Определение профиля заказчика или пользователя
•
•
•
•
•
•
•
•
•
•
•
Имя
Компания
Отрасль
Должность
(указанная информация, как правило, может быть внесена
заранее)
Каковы ваши основные обязанности?
Что вы в основном производите?
Для кого?
Как измеряется успех вашей деятельности?
Какие проблемы влияют на успешность вашей деятельности?
Какие тенденции, если такие существуют, делают вашу работу
проще или сложнее?

30. Пример структуры интервью(2)
Часть 2. Оценка проблемы
• Для каких проблем (прикладного типа) вы
ощущаете нехватку хороших решений?
• Назовите их. (Замечание: не забывайте
спрашивать «А еще?»)
• Для каждой проблемы выясняйте
следующее:
– Почему существует эта проблема?
– Как она решается в настоящее время?
– Как заказчик (пользователь) хотел бы ее решать?

31. Пример структуры интервью(3)
Часть 3. Понимание пользовательской среды
• Кто такие пользователи?
• Какое у них образование?
• Каковы их навыки в компьютерной области?
• Имеют ли опыт работы с данным типом приложений?
• Какая платформа используется?
• Каковы ваши планы относительно будущих платформ?
• Используются ли дополнительные приложения, которые имеют
отношение к данному приложению? Если да, то пусть о них
немного расскажут
• Каковы ожидания заказчика относительно практичности
продукта?
• Сколько времени необходимо на обучение?
• В каком виде должна быть представлена справочная
информация для пользователя

32. Пример структуры интервью(4)
Часть 4. Резюме (перечисляются основные пункты,
чтобы проверить, всё ли правильно вы поняли)
• Итак, вы сказали мне
(перечислите описанные заказчиком проблемы
своими словами)
-
• Адекватно ли этот список представляет проблемы,
которые имеются при существующем решении?
• Какие еще проблемы (если такие существуют) вы
испытываете?

33. Пример структуры интервью(5)
Часть 5. Предположения аналитика относительно проблемы
заказчика
(проверенные и непроверенные предположения)
(те проблемы, которые не были упомянуты)
• Какие проблемы, если они есть, связаны с (перечислите все
потребности или дополнительные проблемы, которые, повашему, может испытывать заказчик или пользователь)
Для каждой из указанных проблем выясните следующее:
• Является ли она реальной?
• Каковы ее причины?
• Как она решается в настоящее время?
• Как бы заказчик (пользователь) хотел ее решать?
• Насколько важно для заказчика (пользователя) решение этой
проблемы в сравнении с другими, упомянутыми им?

34. Пример структуры интервью(6)
Часть 6. Оценка предполагаемого вами решения
(если это уместно)
(Охарактеризуйте основные возможности
предлагаемого вами решения. А потом задайте
пользователю следующие вопросы.)
• Что, если вы сможете…
• Как вы расцениваете важность этого?

35. Пример структуры интервью(7)
Часть 7. Оценка возможности
• Кто нуждается в приложении?
• Сколько пользователей будут использовать
приложение?
• Насколько значимо успешное решение?

36. Пример структуры интервью(8)
Часть 8. Оценка необходимого уровня надежности и
производительности, а также потребности
сопровождения
• Каковы ваши ожидания относительно надежности?
• Какой, по-вашему, должна быть производительность?
• Будете ли вы заниматься поддержкой продукта или этим
будут заниматься другие?
• Испытываете ли вы потребности в поддержке?
• Что вы думаете о доступе для сопровождения и
обслуживания?
• Каковы требования относительно установки и
конфигурации?
• Существуют ли специальные требования по
лицензированию?
• Как будет распределено программное обеспечение?
• Есть ли требования на маркировку и упаковку?

37. Пример структуры интервью(9)
Часть 9. Другие требования
• Уточнить наличие законодательных актов,
инструкций, стандартов и других стандартов, которых
нужно придерживаться.
Часть 10. Окончание интервью
• Какие еще вопросы стоило задать?
• Как можно связаться для обсуждения требований?
Часть 11. Заключение аналитика
• Фиксация потребностей и/или проблем с
наивысшими приоритетами.

38. Фокус-группа
• Групповое интервью в форме дискуссии по
заранее составленному плану-гайду
• Численность 6-12 человек
• Участники - типичные представители целевой
аудитории
• Продолжительность беседы – 1-3 часа
• Дискуссия записывается на видео с последующей
расшифровкой для детального анализа
• В рамках одного исследования – 3-4 фокус-группы

39. Наблюдение
Наблюдение - непосредственное целенаправленное
восприятие и регистрация явлений и процессов
Типы наблюдений:
• Включенное - наблюдатель является непосредственным
участником процесса (обыгрывание ролей пользователей)
• Невключенное - наблюдатель только регистрирует
процессы, факты и явления не являясь участником

40. Кабинетные исследования
(Desk Research)
Кабинетные исследования - сбор и анализ вторичной
информации из различных источников
Источники информации:
•
Интернет-источники
•
печатные СМИ
•
базы данных
•
законодательные акты
•
правительственные публикации и материалы
•
отчеты исследовательских агентств о результатах исследований,
данные о поведении потребителей, данные синдикативных
исследований
•
данные статистических органов

41. Анкетирование
Анкетирование – самозаполнение анкеты
Предпосылки:
• удаленность респондента и интервьюера
• анонимность получаемых данных
Формат:
• анкета передается лично в руки и после
заполнения изымается
• используются технические средства связи:
почтовые рассылки, рассылки по e-mail,
факсимильная связь

42. Техники диаграмм
• Ментальные карты
• Контекстная диаграмма (диаграмма потоков
данных)
• Диаграмма последовательностей
• Диаграммы состояний и действий
• Диаграмма бизнес-процессов

43. Ментальные карты
(Mind map , интеллект-карты, диаграммы связей)
Реализуется в виде древовидной схемы,
на которой изображены слова, идеи, задачи или другие
понятия, связанные ветвями,
отходящими от центрального понятия или идеи.

44. Ментальные карты. Рекомендации
1. Вместо линейной записи использовать
радиальную.
2. Записывать не всё подряд, а только ключевые
слова.
3. Ключевые слова помещаются на ветвях,
расходящихся от центральной темы.
4. Связи (ветки) должны быть скорее
ассоциативными, чем иерархическими.
5. Ассоциации могут подкрепляться символическими
рисунками.

45. Ментальные карты, пример 1

46. Ментальные карты, пример 2

47. Контекстная диаграмма
Контекстная диаграмма – модель, представляющая
систему как набор иерархических действий, в которой
каждое действие преобразует некоторый объект или
набор объектов
Порядок построения контекстной диаграммы :
• определение системных ограничений и
интерфейсов с внешним миром
• формирование списка событий из внешней среды,
на которые система должна реагировать
Используемые технологии:
• IDEF0
• DFD Data Flow Diagramming (диаграммы потоков
данных)

48. Пример построения контекстных
диаграмм
Процесс – экскурсии молодых людей по
достопримечательностям города Уфы.
Постановка задачи.
Молодой, холостой, свободный искатель
приключений желает хорошо провести время с
приятной (ему) девушкой, для чего он приглашает ее
на экскурсию по памятным местам и
достопримечательностям родного города.

49. Пример построения контекстных
диаграмм(продолжение)
Построение модели
Цель моделирования: хорошо провести время с
девушкой на экскурсии
Точка зрения: искателя приключений
Область применения: потенциальные искатели
приключений, которые хотели бы хорошо провести
время с девушкой на экскурсии, но пока еще не
знают, как этого добиться
Вопросы:
•Где взять саму девушку?
•Как ее убедить в неизбежности мероприятия?
•Куда ее отвести?
•Что с ней делать после мероприятия? И т.д.

50. Пример построения контекстных
диаграмм(продолжение)
Входы (inputs):
•Девушки г. Уфы и окрестностей
•Карта Уфы и окрестностей
Управление (controls):
•Что люди скажут?
•Резервы свободного времени
Материальные возможности
•Выходы (outputs):
•Успешно проведенное мероприятие
•Благодарная девушка
Механизмы (mechanisms):
•Искатель приключений
•Транспорт

51. Пример построения контекстных
диаграмм(продолжение)
(стандарт IDEF0)

52. Пример построения контекстных
диаграмм(продолжение)
Дерево модели

53. Пример построения контекстных
диаграмм(продолжение)
Выбор субъекта (стандарт DFD)

54. Пример построения контекстных
диаграмм(продолжение)
Выбор места и времени экскурсии (стандарт DFD)

55. Пример построения контекстных
диаграмм(продолжение)
Процесс убеждения девушки (стандарт DFD)

56. Пример построения контекстных
диаграмм(продолжение)
Организация мероприятия (стандарт DFD)

57. Пример построения контекстных
диаграмм(продолжение)
Заключительные операции (стандарт DFD)

58. Пример построения контекстных
диаграмм(продолжение)
Смена модели!!!
Цель моделирования: хорошо провести время на
экскурсии вместе со спутником
Точка зрения: девушки
Область применения: девушки, которые хотели бы
хорошо провести время на экскурсии, но (как и
искатели приключений) пока еще не знают, как этого
добиться
Вопросы:
•Где найти подходящего спутника?
•Как убедить его в неизбежности мероприятия?
•Как обеспечить личную безопасность?
•Куда сходить?
•Что с ним делать после мероприятия?

59. Пример построения контекстных
диаграмм(продолжение)
(стандарт IDEF0)

60. Пример построения контекстных
диаграмм(продолжение)
Основные этапы (стандарт DFD)

61. Пример построения контекстных
диаграмм(продолжение)
Дерево модели (стандарт DFD)

62. Пример построения контекстных
диаграмм(продолжение)
Подготовка (стандарт DFD)

63. Пример построения контекстных
диаграмм(продолжение)
Выбор спутника (стандарт DFD)

64. Пример построения контекстных
диаграмм(продолжение)
Проведение мероприятия (стандарт DFD)

65. Пример построения контекстных
диаграмм(продолжение)
Оценка претендента (стандарт DFD)

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

67. Диаграмма состояний
Ориентированный граф для конечного автомата, в
котором вершины обозначают состояния, дуги
показывают переходы между двумя состояниями

68. Диаграмма бизнес-процессов
(Business Process Model and Notation,
нотация и модель бизнес-процессов)

69. Формальные техники
•
Диаграмма Ишекавы (Исикавы)
•
SWOT (Strengths, Weaknesses, Opportunities, and Threats,
сильные и слабые стороны, возможности и угрозы)
•
MoSCoW (Must, Should, Could, Would)
•
CATWOE (Customers, Actors, Transformation Process, World
View, Owner, Environmental Constraints, клиенты, акторы,
процесс трансформации, мировоззрение, владелец,
ограничения среды)
•
PESTLE (Political, Economic, Sociological, Technological, Legal
, Environmental, политические, экономические,
социологические, технологические, правовые,
экологические факторы)
•
MOST (Mission, Objectives, Strategies, Tactics, миссия, цели,
стратегия, тактика)

70. Диаграмма Ишекавы(«рыбный скелет»)
Причинно-следственная диаграмма или диаграмма Ишекавы является
графическим изображением, которое в сжатой форме и логической
последовательности распределяет причины
Цель диаграммы – выявить
технологического процесса.
влияние
причин
на
всех
уровнях
Достоинство – дает наглядное представление не только о тех факторах,
которые влияют на изучаемый объект, но и о причинно-следственных
связях этих факторов

71. Диаграмма Ишекавы. 6М (5М)
1. Man (Человек) − причины,
связанные с человеческим
фактором
2. Machines (Машины,
оборудование) − причины,
связанные с оборудованием
3. Materials (Материалы) −
причины, связанные с
материалами
4. Methods (Методы,
технология) − причины,
связанные с технологией
работы, с организацией
процессов
5. Measurements (Измерения) −
причины, связанные с
методами измерения
6. Менеджмент (management) –
причины, связанные с
организацией управления
предприятием

72. Диаграмма Парето
Авторы метода: В. Парето (Италия), 1897 г., М. Лоренц (США), 1979 г.
Цель метода: выявление проблем, подлежащих первоочередному решению
Диаграмма Парето - разновидность столбиковой диаграммы применяемой
для наглядного отображения рассматриваемых факторов в порядке
уменьшения их значимости
Особенности метода: принцип Парето (принцип 20/80) означает, что 20%
усилий дают 80% результата, а остальные 80% усилий - лишь 20%
результат
Достоинства метода:
• Простота и наглядность делают возможным использование
диаграммы Парето специалистами, не имеющими особой подготовки
• Сравнение диаграмм Парето, описывающих ситуацию до и после
проведения улучшающих мероприятий, позволяют получить
количественную оценку выигрыша от этих мероприятий.
Недостатки метода: при построении сложной, не всегда четко
структурированной диаграммы, возможны неправильные выводы

73. Виды диаграмм Парето
1. Диаграмма Парето по результатам деятельности.
Предназначена для выявления главной проблемы и отражает
нежелательные результаты деятельности, связанные:
• с качеством (дефекты, поломки, ошибки, отказы,
рекламации, ремонты, возвраты продукции)
• с себестоимостью (объем потерь; затраты)
• со сроками поставок (нехватка запасов, ошибки в
составлении счетов, срыв сроков поставок)
• с безопасностью (несчастные случаи, трагические
ошибки, аварии)
2. Диаграмма Парето по причинам. Отражает причины
проблем, возникающих в ходе производства, и используется
для выявления главной из них (подход 5М).

74. Построение диаграммы Парето
1. Решить, какие проблемы (причины проблем) надлежит
исследовать, какие данные собирать и как их классифицировать
2. Разработать формы для регистрации исходных данных (например,
контрольный листок)
3. Собрать данные, заполнив формы, и подсчитать итоги по каждому
исследуемому фактору (показателю, признаку)
4. Подготовить таблицу для проверок данных.
Графы таблицы:
•
признак (фактор, причина и т.п.)
•
итог по каждому проверяемому признаку в отдельности
•
накопленная сумма
•
процент к общему итогу
•
накопленный процент
5. Заполнить таблицу, расположив данные, полученные по
проверяемому фактору, в порядке убывания значимости
Примечание: Группу «прочие» следует размещать в последней строке
независимо от ее числовых значений, поскольку ее составляет
совокупность признаков, числовой результат по каждому из
которых меньше, чем самое маленькое значение, полученное для
признака, выделенного в отдельную строку.

75. Построение диаграммы Парето
(продолжение)
6. Подготовить оси для построения диаграммы
• Горизонтальная ось - интервалы в соответствии с числом
контролируемых признаков.
• Левая вертикальная ось - шкала с интервалами от 0 до общей
суммы числа выявленных факторов
• Правая вертикальная ось - шкала с интервалами от 0 до 100,
отражающую процентную меру фактора.
7. Построить столбиковую диаграмму
• Высота столбца (откладывается по левой шкале) равна числу
появлений соответствующего фактора
• Столбцы располагают в порядке убывания (уменьшения
значимости фактора)
• Последний столбец характеризует "прочие", т. е. малозначимые
факторы, и может быть выше соседних
7. Начертить кумулятивную кривую (кривую Парето) - ломаную,
соединяющую точки накопленных сумм (количественной меры
факторов или процентов). Каждую точку ставят над соответствующим
столбцом столбиковой диаграммы, ориентируясь на его правую
сторону
8. Нанести на диаграмму все обозначения и надписи

76. Анализ диаграммы Парето.
Метод АВС-анализа
1. Группа А — наиболее важные, существенные проблемы,
причины, дефекты.
Относительный процент группы А в общем количестве
дефектов (причин) обычно составляет от 60 до 80%.
Устранение причин группы А имеет большой приоритет, а
связанные с этим мероприятия — самую высокую
эффективность
2. Группа В — причины, которые в сумме имеют не более
20%
3. Группа С — самые многочисленные, но при этом наименее
значимые причины и проблемы

77. Пример диаграммы Парето

78. Диаграмма Парето. Рекомендации
1. Желательно использовать разные классификации и
составлять много диаграмм Парето
2. Группа факторов «прочие» не должна составлять
большой процент
3. Если данные можно представить в денежном выражении,
лучше всего показать это на вертикальных осях
диаграммы Парето
4. Если нежелательный фактор можно устранить с помощью
простого решения, это надо сделать незамедлительно,
каким бы незначительным он ни был

79. Техника MoSCoW
(Must, Should, Could, Would)
Must Have
Описывает функциональность, которая
обязательно должна присутствовать в продукте,
без нее продукта просто не будет
Should Have
Требования «Should» столь же важны, как и
требования «Must», но они могут не быть
срочным или для их реализации их можно
использовать обходной путь (workaround)
Could Have
Описывает менее критичные требования,
отсутствие которых не приводит к каким-то
драматическим последствиям. Пользователи
будут довольны даже если этого функционала не
будет в продукте.
Won’t Have but
Would Like in
the Future
Это несущественное требование. Выполнять его
в данный момент не нужно, но оно может
пригодиться когда-то в будущем, например, в
следующих версиях системы.

80. Техника MoSCoW.
Наследование приоритетов
Must
Should
Could
Would
Must
Must
Should
Could
Would
Should
Should
Could
Would
Would
Could
Could
Would
Would
Would
Would
Would
Would
Would
Would

81. Метод Делфи
Разработан в корпорации «Рэнд» в конце 1940-х гг. Первоначально
использовался для прогнозирования будущих событий. Позднее метод
использовался для принятия решений по спорным вопросам.
Суть метода:
• Предварительный этап: участники дискуссии должны без
обсуждения с другими ответить на ряд вопросов, относительно их
мнения по спорному вопросу.
• Первый этап: ответы обобщаются, табулируются и возвращаются
каждому участнику дискуссии для проведения второго этапа.
• Второй этап: участникам снова предстоит дать свою оценку спорного
вопроса, но на этот раз, располагая мнениями других участников,
полученными на первом этапе.
• Второй этап завершается сужением и выделением круга мнений,
отражающих некоторую общую оценку проблемы.
Особенности:
• коллективное обсуждение между этапами не использовалось
• метод эффективен в том случае, если доступная информация
состоит больше из «мнений экспертов», чем из строго определенных
эмпирических данных

82. Методика Wideband Delphi
Практическая реализация проведения оценки по методу
Делфи (Барри Боэм, 1981 г.)
Является методом для повышения качества оценок,
полученных несколькими экспертами
Ориентирована на получение следующих оценок:
• Структурная или функциональная декомпозиция
работ
• Трудозатраты
• Размер проекта
• Критические компьютерные ресурсы
• Стоимость
• Риски

83. Методика Wideband Delphi.
Основные участники процесса оценки
Менеджер проекта – составляет список оцениваемых
элементов
Модератор – управляет процессом оценки,
обеспечивает правильное выполнение процедуры
Wideband Delphi. Эта роль может выполняться
менеджером проекта
Оценщики – изучают задачу и выполняют оценку

84. Применение Wideband Delphi
1. Подготовить список оцениваемых элементов
2. Провести совместную встречу команды оценки для
проведения ревью списка оцениваемых элементов
3. Выполнить индивидуальные оценки
4. Собрать индивидуальные оценки от каждого из
членов команды и создать суммарную таблицу
оценок
5. Провести встречу по обсуждению оценок
6. Завершить заполнение суммарной таблицы оценок

85. Методика Wideband Delphi.
Подготовка списка оцениваемых
элементов
• Выполняется менеджером проекта
• Определяется, что надо оценить (трудозатраты,
стоимость и т.д.)
• Нельзя смешивать различные виды оценок
• Выбирается единица измерения для проведения
оценки
• Создается список и описание оцениваемых
элементов, а также собирается необходимая для
оценки документация

86. Методика Wideband Delphi.
Подготовка списка оцениваемых
элементов
Совместное совещание команды оценки организуется
модератором
Это совещание должно занимать не более 30 минут
Шаги:
• Рассказать про технику Wideband Delphi
• Предоставить список оцениваемых элементов, а
также форм для проведения оценки
• Провести ревью списка, скорректировать его при
необходимости
• Если используется индивидуальная форма оценки,
то она также может быть скорректирована

87. Методика Wideband Delphi.
Выполнение индивидуальных оценок
• Оценщики выполняют индивидуальные оценки
• Они могут выполнять любые исследования, какие
посчитают нужными
• Оценщики не должны общаться между собой
• Индивидуальная оценка должна занимать не
более, чем 2 часа
• Оценка выполняется по PERT(Program Evaluation
and Review Technique)

88. Методика Wideband Delphi.
Оценка PERT
Ожидаемая (PERT)=(О + 4*В + П) / 6
Оценка по трем точкам:
О – оптимистическая (Best Case)
В – наиболее вероятная (Most Probable)
П – пессимистическая (Worst Case)
Пример. Некоторая работа исполнялась 10 раз.
Статистика длительностей:
2 раза за 4 дня – оптимистическая
7 раз за 5 дней – наиболее вероятная
1 раз за 9 дней – пессимистическая
Средняя (арифм.) = (4 * 2 + 5 * 7 + 9 * 1) / 10 = 5,2 дней
Ожидаемая (PERT) = (4 + 4 * 5 + 9) / 6 = 5,5 дней

89. Методика Wideband Delphi.
Обсуждение оценок
1. Всем участникам предоставляется суммарная
таблица оценок
2. Каждый оценщик изучает суммарную таблицу
оценок
3. Проводится несколько совместных обсуждений
оценки
4. Каждый оценщик выполняет еще одну индивидуальную оценку.
5. Результаты этих оценок опять обобщаются в
суммар-ной таблице оценок
6. Проводится новое совместное обсуждение оценок
7. Если оценки сошлись и между ними небольшая
разница, то совещание завершается и итоговая
оценка предоставляется менеджеру проекта
8. Если оценки не сошлись, то шаги 3-6 повторяются

90. Методика Wideband Delphi.
Рекомендации по использованию
1. Для проведения оценки необходимо 3-5 экспертов
2. Полезно использовать экспертов с различным
опытом, проектными ролями, техниками оценки
3. Wideband Delphi это ресурсоемкая методика,
поэтому ее не рекомендуется использовать для
детальных оценок отдельных задач
4. Когда применяется?
•
•
•
Новый бизнес-домен, технология, язык программирования
Грубая оценка на начальных стадиях проекта
Нетривиальный пользовательский интерфейс, высокая
алгоритмическая сложность, высокие требования к
производительности и т.д.

91. Покер планирования
Покер планирования (англ. Planning Poker, а
также англ. Scrum poker) - техника оценки,
основанная на достижении договорённости
Используется для оценки сложности предстоящей
работы или относительного объёма решаемых
задач при разработке программного обеспечения
Разновидность метода Wideband Delphi
Достоинство метода: минимизирует эффект
привязки путём опроса каждого из участников
команды таким образом, что никто не знает чужого
решения до одновременного оглашения выбора
каждого из участников

92. Покер планирования. Подготовка
Материалы:
•
•
список обсуждаемых функций
несколько колод пронумерованных карт
Разновидности колод:
• карты, содержащие числа Фибоначчи, включая ноль: 0, 1,
2, 3, 5, 8, 13, 21, 34, 55, 89
•
0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100 и иногда знак
вопроса («?»), означающий неуверенность, и чашку кофе,
означающую требование перерыва
•
обычные игровые карты, включающие туз, 2, 3, 5, 8
и короля. Король буквально означает: «Данный пункт
слишком большой или его слишком сложно оценить».
Выбрасывание короля завершает обсуждение пункта
в текущем круге
По желанию, может использоваться таймер, чтобы
устанавливать лимит времени одного круга

93. Покер планирования. Проведение
1.
2.
3.
4.
5.
Каждому участнику обсуждения выдаётся по одной колоде карт.
Все колоды идентичны друг другу.
Ведущий, не участвующий в обсуждении, ведёт собрание
Менеджер проекта представляет краткие обзоры каждого из пунктов
Команда может задавать вопросы и вести обсуждение предложений
и рисков
6. Итог обсуждения записывается менеджером проекта
7. Участники выбирают по одной карте и кладут их рубашкой вверх,
показывая таким образом, что выбор сделан
8. Каждый участник называет свою карту и переворачивает её
9. Участникам с высокими и низкими оценками даётся возможность
высказаться и обосновать свою оценку
10. Процесс обсуждения продолжается до тех пор, пока не будет
достигнут консенсус
11. Голос участника, который, скорее всего, будет владеть разработкой,
имеет больший вес в «голосовании на основе консенсуса»
12. Таймер используется для обеспечения структурированности
обсуждения; ведущий или менеджер проекта может в любое время
перезапустить таймер, по истечении времени все обсуждения
должны быть прекращены, затем начинается новый круг покера

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

95. Эффект привязки
в покере планирования
Эффект привязки возникает, когда команда открыто обсуждает оценки
Команда обычно имеет в своём составе как сдержанных, так и
импульсивных участников
Могут быть участники, у которых есть определённые планы:
• разработчики, вероятно, захотят как можно больше времени
заниматься работой над проектом,
• владелец продукта или заказчик, вероятно, захочет, чтобы работа
была закончена как можно скорее
Из-за эффекта привязки участники могут - сознательно или нет отказаться от своей точки зрения, чтобы выразить начальное
единство команды; они могут это сделать, даже чтобы просто
показать, что они думают так же
Покер планирования выявляет
потенциально влиятельного участника команды,
изолируя его мнение от других участников группы

96. Билль о правах клиента ПО при
формировании требований
Клиент имеет право
1. Иметь дело с аналитиком, который разговаривает на вашем языке
2. Иметь дело с аналитиком, хорошо изучившим ваш бизнес и цели, для
которых создается система
3. Потребовать, чтобы аналитик преобразовал требования, предоставленные
вами устно, в письменную спецификацию требований к программному
продукту
4. Получить от аналитика подробный отчет обо всех рабочих продуктах,
созданных в процессе формулирования требований
5. На уважительное и профессиональное отношение к вам со стороны
аналитиков и разработчиков
6. Знать о вариантах и альтернативах требований и их реализации
7. Описать характеристики, упрощающие работу с продуктом
8. Изменить требования или разрешить использование имеющихся
программных компонентов
9. Получить исчерпывающие сведения о сумме затрат, ожидаемом эффекте
и необходимых компромиссах, которые возникают в связи с изменениями
в ПО
10. Потребовать, чтобы система функциональностью и качеством
удовлетворяла требования заказчика

97. Билль об обязанностях клиента ПО
при формировании требований
Клиент обязан
1. Ознакомить аналитиков и разработчиков с особенностями бизнеса
2. Потратить столько времени, сколько необходимо, на объяснение
требований
3. Точно и конкретно описать требования к системе
4. Принимать своевременные решения при формировании
требований
5. Уважать определенную разработчиком оценку стоимости и
возможность реализации ваших требований
6. Определять приоритеты требований
7. Просматривать документы с требованиями и оценивать прототипы
8. Своевременно сообщать об изменениях требований
9. Поддерживать принятый в организации-разработчике порядок
контроля изменений
10. Уважительно относиться к методам, с помощью которых
аналитики создают требования

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

99. Состав спецификации
1. Глоссарий (словарь) основных используемых
терминов
• Оформляется, как текст, состоящий из абзацев,
каждый из которых определяет значение одного из
терминов проблемной области
• Термин обычно выделяют полужирным кеглем
• Иногда проблемную область целесообразно
сегментировать на ряд «подобластей» (subject
areas), тогда каждой из них в глоссарии выделяется
отдельный параграф
2. Реестр требований, оформленный надлежащим
образом

100. Факторы выбора формата
спецификации
• Размеры проекта
• Важность проекта и варианта использования
• Традиции, сложившиеся в коллективе
«Заказчик-Разработчик»
• Критичность проекта в целом и критичности
варианта использования в данном проекте

101. Показатель критичности
Определяется «ценой ошибки»
Проекты, ошибки в которых могут привести к… :
1)опасности для жизни людей
2)невосполнимым финансовым потерям
3)финансовым потерям в ограниченном объёме
4)снижению комфортности конечного
пользователя

102. Формулировка требований
1. Не существует выверенного способа написания
идеальных требований
2. Лучший учитель — это опыт, который
нарабатывается со временем
3. Безупречную документацию по требованиям
отличает технический стиль изложения и
пользовательская терминология, а не
компьютерный сленг

103. Рекомендации по
формулировке требований
1. Используйте полные предложения, с
правильной грамматикой, правописанием и
пунктуацией
2. Предложения и абзацы должны быть краткими
и ясными

104. Рекомендации по
формулировке требований
3. Используйте действительный залог
корректно
Система отобразит
список товаров
некорректно
На экране
отобразится список
товаров

105. Рекомендации по
формулировке требований
4. Используйте термины и именно так, как они
определены в словаре.
Не используйте синонимы и близкие по
значению слова.
Не надо в спецификации требований к ПО пытаться
разнообразить лексику, чтобы заинтересовать
читателя!!!

106. Рекомендации по
формулировке требований
5. Нечеткие требования верхнего уровня следует
детализировать таким образом, чтоб они стали
абсолютно ясны

107. Рекомендации по
формулировке требований
6. Требования следует излагать последовательно
<Субъект> [будет] <активный глагол>
<наблюдаемый результат>
Замечания:
• Укажите, какие условия или действия инициируют
соответствующее поведение субъекта
• Можно использовать «должно» как синоним «будет»
• Не используйте слова «следовало бы», «может»,
«можно было бы» и аналогичные, из которых не ясно,
необходимо ли действие

108. Рекомендации по
формулировке требований
7. Идентифицируйте пользователя
корректно
Покупатель будет...
некорректно
Пользователь будет...

109. Рекомендации по
формулировке требований
8. Применяйте
• списки,
• рисунки,
• графики
• таблицы,
чтобы представить информацию визуально
Читателей утомляет
большой объем сплошного текста!!!

110. Рекомендации по
формулировке требований
9. Выделите наиболее значимые фрагменты
информации.
Рекомендуемые приемы:
• графики,
• последовательности, в которых первый
элемент подчеркивается,
• повторы,
• пустое пространство,
• визуальный контраст.

111. Рекомендации по
формулировке требований
10.Требования, изложенные неясным языком,
не поддаются проверке
Избегайте
• двусмысленных,
• неоднозначных,
• субъективных терминов

112. Рекомендации по
формулировке требований
11.Требования должны быть сформулированы
достаточно подробно, чтобы риск непонимания
был минимальным.
НО! Избегайте ненужных ограничений
разработки!!!

113. Рекомендации по
формулировке требований
12.Менее строгие формулировки дают
разработчикам больше свободы для
интерпретаций.
Точно сформулированные требования
повышают вероятность того, что ожидания
клиентов будут реализованы.

114. Рекомендации по
формулировке требований
13.При написании требований соблюдайте
примерно одинаковый уровень детализации

115. Рекомендации по
формулировке требований
14.Избегайте длинных повествовательных абзацев,
которые содержат несколько требований.
Признаки, по которым можно определить, что в одном
предложении содержится несколько требований:
• слова «и», «или» и «также»
• слова «пока не» и «кроме»
Пример:
«Кредитная карточка покупателя будет считаться
действительной для платежей до тех пор, пока не
истечет ее срок действия».
Решение:
Разделите требование на два (для двух условий) когда
срок действия кредитной карты истек и когда она
действительна

116. Ловушка
Оценка качества требований зависит
от того, кто их оценивает.
Аналитик может верить, что создал
документ абсолютно ясный, безо
всяких неясностей и проблем.
Однако если у читателей возникли
вопросы, значит, требуется
доработка

117. Рекомендации по
формулировке требований
Неоднозначные
термины
Способы их улучшения
1) Приемлемый, Определите, что понимается под
адекватный
приемлемостью и как система это
может оценить
2) Практически
выполнимо
Не
заставляйте
разработчиков
определять,
что
под
этим
понимается. Поставьте пометку
«TBD»(to
be
detected…)
и
определите дату, к которой эту
проблему следует разрешить

118. Рекомендации по
формулировке требований
Неоднозначные
термины
Способы их улучшения
3) По меньшей Укажите
минимальное
и
мере,
как
максимальное
допустимые
минимум, не
значения
более чем, не
должно
превышать
4) Между
Определите, указаны ли конечные
точки

119. Рекомендации по
формулировке требований
Неоднозначн
ые
термины
Способы их улучшения
5) Зависит от Определите природу зависимости.
Обеспечивает ли другая система
ввод данных в вашу систему, надо
ли установить другое ПО до запуска
вашей системы и зависит ли ваша
система от другой при выполнении
определенных расчетов или служб?
6) Эффектив- Определите, насколько эффективно
ный
система
использует
ресурсы,
насколько быстро она выполняет
определенные операции и насколько

120. Рекомендации по
формулировке требований
Неоднозначн
ые
термины
Способы их улучшения
7) Быстрый,
Укажите минимальную приемлемую
моменталь
скорость, при которой система
-ный
выполняет определенное действие
8) Гибкий
Опишите способы изменения системы
в ответ на изменения условий или
бизнес-потребностей

121. Рекомендации по
формулировке требований
Неоднозначные
термины
Способы их улучшения
9) Улучшенный,
Определите
количественно,
лучший, более
насколько лучше или быстрее
быстрый,
стали
показатели
в
превосходный
определенной функциональной
области
10) Включает;
включает в
себя, но не
ограничен
этим; и т.д.; и
т.п.; такой как
Список элементов должен
включать все возможности. В
противном случае его нельзя
использовать при разработке
или тестировании

122. Рекомендации по
формулировке требований
Неоднозначные
термины
Способы их улучшения
11) Максимизируйте Укажите минимальное и
,
максимальное допустимые
минимизируйте,
значения определенного
оптимизируйте
параметра
12) Обычно,
Также
опишите
поведение
в
идеальном
системы при нештатных или
неидеальных условиях
варианте
13) Необязательно
Укажите, кто делает выбор:
система, пользователь или
разработчик

123. Рекомендации по
формулировке требований
Неоднозначные
термины
Способы их улучшения
14)Разумный,
при Объясните, как это выполнить
необходимости,
при
соответствующих
условиях
15)Устойчивый
сбоям
к Определите,
как
система
должны
обрабатывать
исключения и реагировать на
неожиданные условия работы

124. Рекомендации по
формулировке требований
Неоднозначные
термины
Способы их улучшения
16)Цельный,
прозрачный,
элегантный
Выразите
ожидания
пользователя,
применяя
характеристики
продукта,
которые можно наблюдать
17)Несколько
Укажите сколько или задайте
минимальную и максимальную
границы диапазона

125. Рекомендации по
формулировке требований
Неоднозначные
термины
Способы их улучшения
18)Не следует
Старайтесь
формулировать
требования
в
позитивной
форме, описывая, что именно
система будет делать
19)Реальный
Поясните этот термин
20)Достаточный
Укажите, какая степень чеголибо
свидетельствует
о
достаточности

126. Рекомендации по
формулировке требований
Неоднозначные
термины
Способы их улучшения
21)Поддерживает,
позволяет
Дайте
точное
определение,
какие действия система будет
выполнять,
поддерживая
конкретную возможность
22)Дружественный,
простой, легкий
Опишите
системные
характеристики, которые будут
отвечать
потребностям
пользователей и его ожиданиям,
касающимся
легкости
и
простоты применения продукта

127. Пример неоднозначности
«У Мэри был
маленький барашек»
Mary had a little lamb
Sarah Hale

128. «У Мэри был
маленький барашек»
Ключевые слова:
• had (have)
• lamb

129. «У Мэри был
маленький барашек»
Have
1а) иметь во владении в качестве собственности
4а) приобретать в качестве собственности
4в) ПРИНИМАТЬ состоять в браке
5а) отметка или отличительная особенность (иметь
рыжие волосы)
10а)удерживать в невыгодном положении или как-то
ущемлять
10б) ОБМАНУТЬ, ОДУРАЧИТЬ
12)ПРОИЗВЕСТИ НА СВЕТ, РОДИТЬ (иметь ребенка)
13)съесть
14) ДАВАТЬ ВЗЯТКУ, ПОДКУПАТЬ
Webster's Seventh New Collegiate Dictionary

130. «У Мэри был
маленький барашек»
Lamb
1а) молодая овца в возрасте до одного года или без
постоянных зубов
1б) молодняк других животных (в частности, небольших
антилоп)
2а) человек слабый и симпатичный, как маленький
барашек
2б) ДОРОГОЙ, ЛЮБИМЫЙ
2в) человек, легко идущий на обман (нечистый на руку),
особенно в сфере торговли
3а) «седло барашка» - кулинарное блюдо
Webster's Seventh New Collegiate Dictionary

131. «У Мэри был
маленький барашек»
Интерпретации (1)
have lamb
Интерпретация
1а
1а
Мэри владела маленькой овечкой
в возрасте до одного года или без
постоянных зубов
4а
1а
Мэри приобрела маленькую
овечку в возрасте до одного года
или без постоянных зубов

132. «У Мэри был
маленький барашек»
Интерпретации (2)
have lamb
Интерпретация
5а
1а
Мэри - владелец маленькой
овечки в возрасте до одного года
или без постоянных зубов
10а
1а
Мэри держала в руках (не давала
порезвиться) маленького ягненка в
возрасте до одного года или без
постоянных зубов

133. «У Мэри был
маленький барашек»
Интерпретации (3)
have lamb
12
12
1б
2а
Интерпретация
Мэри родила маленькую антилопу
Мэри является (или была)
матерью некоего маленького
симпатичного существа

134. «У Мэри был
маленький барашек»
Интерпретации (4)
have lamb
Интерпретация
13
3а
Мэри съела небольшую порцию
седла ягненка
14
2в
Мэри подкупила мелкого торговца
ценными бумагами, который
нечист на руку

135. Методы ухода
от неоднозначности
• Эвристика запоминания – восстановление по
памяти исходного требования
• Метод ключевых слов – выделить ключевые
слова, выписать их определения (из авторитетных
источников!) и составить комбинации
• Метод ударения – прочесть требование вслух,
выделяя с помощью интонации отдельные слова,
пока не будут найдены все возможные
интерпретации
• Другие методы – рисунки, графики или
формальные методы для выявления
неоднозначности и ее устранения

136. «У Мэри был
маленький барашек»
Метод ударения
У Мэри был маленький барашек
У Мэри был маленький барашек
У Мэри был маленький барашек
У Мэри был маленький барашек
У Мэри был маленький барашек (Mary had a little lamb)

137. Характеристики требований
•
•
•
•
•
•
•
Полные
Правильные
Выполнимые
Необходимые
Имеющие приоритет
Точно выраженные
Поддающиеся проверке

138. Ловушка
Старайтесь избегать паралича
аналитического процесса
Нельзя тратить слишком много времени на
попытки сделать требования идеальными
Цель - написать требования, которые хороши
достаточно, чтобы разработчики могли
приступить к конструированию продукта
при приемлемом уровне риска

139. Один из способов оценить требование –
проверить, устраивают ли пользователя
нелепые, но имеющие право на
существование интерпретации этого
требования
Если нет, то над требованием
необходимо еще поработать