Управление требованиями. Требования в программных проектах. Проблемы определения требований

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

Проблемы определения требования:

- требования пользователей меняются;

- неясны, двусмысленны и противоречивы;

- пользователи недостаточно представительны;

- недостаточная определённость спецификации.

Отсюда свойства: корректность, однозначность, полнота, непротиворечивость, приоретизация, проверяемость, модифицируемость, отслеживаемость.

Требования бывают функциональные и нефункциональные.

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

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

- используемость-эстетичный вид, наличие справки, пользовательская документация, учебные материалы и т.д.;

- надёжность - восстановление функциональности, предсказуемость поведения, точность, обработка отказов, время между отказами и т.д.;

- исполнимость - скорость работы, эффективность, время отклика, использование ресурсов и т.д.;

- приемлемость- расширяемость, адаптируемость под конкретные задачи, поддерживаемость, совместимость, мультиплатформенность, локализируемость и т.д.;

Атрибуты требований:

- критерий важности -обязан иметь, должен иметь, мог бы иметь, хотел бы иметь;

- статус -предложенные, одобренные, отклонённые, включённые;

- трудоёмкость -человеко-часы, функциональные точки;

- риск;

- стабильность -высокая, средняя, низкая;

- целевая версия.

1. Понятие: «Условие или возможность, необходимая пользователю для решения его задач» обозначает:

2. К нефункциональным требованиям исполнимости ПО относятся:

Разработка требований. Выявление и анализ требований

Разработка требований включает выявление и анализ требований, на основе которых составляется спецификация требований.

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

Способы выявления: исследования, интервью, семинары, создание прототипов, создание вариантов использования.

Выявление требований путём интервью несёт в себе 3 фильтра, относимые к естественному языку:

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

- искажение - информация изменяется взаимосвязанными механизмами вымысла и представления;

- обобщение - информация обобщается в правила, убеждения об истинности и ложности.

Анализ требований- сходящийся процесс, который уточняет данные, структурирует информацию, устанавливает приоритеты.

На этапе уточнения требования описываются количественно, они должны быть максимально полными. Уточнение достигается путём повторных встреч с заинтересованными лицами, при этом не должно появляться много новых требований, иначе придётся вернуться на этап выявления.

Расстановка приоритетов служит для сортировки требований по важности и срочности:

- срочно и важно - высший приоритет;

- не срочно, но важно - средний приоритет;

- срочно, но не важно- минимальный приоритет;

- не срочно и не важно- не стоит делать.

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

1. Этап выявления требований предполагает:

2. На основе выявления и анализа требований:

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

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

Организация требованийосуществляется либо посредством группировки в родственные группы, либо иерархическим структурированием.

Способы документирования:

- документы на естественном языке;

- графические модели (диаграммы, графы, схемы, потоки);

- формальные спецификации.

1. Как документируются требования пользователей?

Документирование требований. Виды документов

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

Распределяет ответственность между заинтересованными сторонами проекта, иначе говоря, задаёт правила игры. Например: кто, что и когда создаёт; кто, что и когда тестирует; кто, за что и когда платит; кто и кому докладывает; кто принимает завершение работ или этапов; кто, как и когда санкционирует изменения; и др..

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

Описание того, как система должна работать или как она будет использоваться. Например: как и какие функции будут использоваться, кем и в каких условиях; как будет происходить ввод-вывод данных; как система взаимодействует с другими системами; и др.. Данный документ задаёт основу для разработки вариантов использования.

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

Высокоуровневый и приблизительный план разработки. Задаёт основные документы, точки принятия решений, поставляемые артефакты, этапы работ и контрольные точки, графики платежей.

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

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

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

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

1. Какой тип документа содержит описание того, как система должна работать или как она будет использоваться?

Вопросы

2. Тип документа «Состав и распределение работ» отражает:

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

Причина изменений

- со стороны заказчика: не понравился результат; передумал; забыл;

- со стороны рынка: неактуален (нельзя продать); нужно выйти на рынок прямо сейчас, иначе потом не продать;

- со стороны разработки: границы проекта определены неточно; требования были неправильно поняты или совсем не поняты, неправильно определены.

Условия возможности изменений

- при водопадных стратегиях - нет возможности;

- при инкрементных- возможно с ограничениями;

- при эволюционных - возможно.

Политика управления изменениями

- должен быть принят процесс контроля изменений;

- все изменения должны следовать процессу или не рассматриваться

- если требования не утверждены, то они игнорируются, кроме исследования осуществимости;

- все запросы на изменение должны быть утверждены советом по управлению изменений;

- содержание запроса на изменение должно быть доступно всем заинтересованным лицам;

- начальный текст запроса должен быть неизменен;

- анализ воздействия должен проводиться для каждого изменения;

- обоснование каждого изменения должно быть задокументировано.

Анализ влияния изменений

- выявление последствий изменений;

- определение всех сущностей, которые нуждаются в модификации (в случае принятия изменения);

- определение задач для реализации изменений;

- оценка влияния на график работ;

- оценка влияния на стоимость;

- оценка приоритета изменений, учитывая достоинства, недостатки, затраты и риски.

Принятие/непринятие изменений

Реакции на запрос об изменении

- отложить низкоприоритетные требования;

- привлечь дополнительных сотрудников;

- краткосрочная сверхурочная работа;

- изменение графика работ;

- пожертвование качеством;

- отказ.

1. Есть ли возможность внесения изменений при использовании эволюционной стратегии?

2. Невозможность продажи продукта - это причина внесения изменения изменений со стороны:

Планирование и управление требованиями. Прослеживание требований

Цели планирования и управления:

- контроль версий требований-определение схемы идентификации версий, определение версий спецификаций требований и версий отдельный требований, контроль, определение и регистрация состояния требований;

- прослеживание требований-определение связей с другими требованиями, элементами системами;

- управление изменениями требований-предложение и анализ изменений, принятие решений, обновление требований и планов;

- совершенствование процессов управления.

Управление версиями требований-нужно по причине возможности устаревания требований, а так же их противоречивости. Позволяет производить контроль версий документов (с помощью любой системы контроля версий) и контроль версий самих требований (создание начальных версий требований, ведение истории изменений, авторизованный доступ к изменениям требований).

Управление состояниями- предложено, одобрено, реализовано, проверено, удалено, отклонено.

Отслеживание состояний требований- используется при анализе изменений, обосновывает некоторые решения, принятые во время разработки.

Цели прослеживания требований:

- получить подтверждение, что цели были реализованы;

- убедиться, что требования были оттестированы;

- иметь трассы всех требований от заказчика до тестовых случаев.

Необходимо прослеживать 4 типа связей:

- потребности заказчика с разработанными требованиями;

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

- требования с определёнными элементами продукта;

- определённые элементы продукта с соответствующими требованиями.

1. Определение связей с другими требованиями и элементами системами является целью:

2. Отслеживание состояний требований: