|
Система управления требованиями
5
мая
2012
|
|
|
Требование — это формулировка ожидаемого свойства, поведения или характеристик продукта. Обычно требования формулируются заказчиком и являются основанием для производства работ. В течение жизненного цикла продукта могут добавляться новые требования, изменяться существующие.
Пример требования: расход бензина а/м должен быть не выше 10 л/100км.
Таким образом Техническое Задание (ТЗ) — есть ни что иное, как изначальный набор требований, предоставленный заказчиком и достаточный для производства продукта. Правильность и четкость постановки требований является крайне важным моментом, поскольку ошибки на данном этапе могут привести к тому, что конечный продукт не будет удовлетворять заказчика. На этапе постановки требований они должны постоянно уточняться и утверждаться заказчиком.
Управление требованиями к системе — это руководство процессами формирования требований на всех этапах жизненного цикла.

Рис.1: Управление требованиями к системе
Система управления требованиями — это информационная система, отвечающая за процесс управления требованиями. Чаще всего такие системы являются частью систем управления проектами, позволяя создавать и изменять требования к проектам или его составляющим. Наиболее удобным представляется способ иерархическогопредставления требований (в виде дерева требований), в котором требования делятся на категории, подкатегории и пр. Организация "дерева требований" способствует также "самодокументированию" системы.

Рис.2: Иерархическое представление требований
Необходимость сохранения всех требований к проекту в единой базе хорошо иллюстрируется на примере разработки программного обеспечения. Требования нужны всем участникам процесса разработки:
- Заказчику, чтобы корректно сформулировать задачу и отслеживать ее выполнение;
- Разработчикам, чтобы внедрять функциональность отталкиваясь от требований заказчика;
- Тестировщикам, чтобы написать тесты, основыванные на требованиях, то есть проверить что программа правильно делает именно то, что требуется;
- Техническим писателям, чтобы отталкиваясь от требований написать руководства по использованию программы;
По мере развития проекта количество требований растет, и в случае отсутствия правильно организованного полного набора требований, рано или поздно возникают следующие проблемы:
- сложность восприятия состояния проекта и его отдельных подсистем, особенно для новых членов команды;
- невозможность отследить причину появления того или иного свойства, поведения продукта;
- продукт может утратить функциональность, которая уже была внедрена, но не была отражена в требовании;
Таким образом, можно сформулировать ожидаемые характеристики современнойсистемы управления требованиями:
- Программа должна предоставлять возможности по созданию и структурированию (группировке) требований;
- Требования должны включать в себя ряд свойств, такие как статус, исполнитель, ответственный, бюджет, сроки исполнения, приоритет и этап разработки;
- Текстовое описание должно быть основной частью требования. Желательна возможность форматирования текста (таблицы, эффекты, списки);
- Должна быть предоставлена возможность обсуждения требования участниками проекта и сохранения истории обсуждения как неотъемлемой части требования;
- Желательно иметь возможность прикреплять файлы к требованиям;
- Необходимо иметь возможность отслеживать взаимосвязи требований друг с другом;
- Желательно иметь возможность отслеживать связи требований с другими задачами. Данный пункт имеет связь с понятием системы управления задачами: например, задача на исправление дефекта продукта, заявленная в разделе отслеживания ошибок, может повлечь создание нового требования к продукту.
Программа для управления проектами Project Kaiser включает в себя все вышеописанные возможности и является, таким образом, полноценной системой управления требованиями. Требования могут быть включены в структуру проекта или его частей в виде иерархического дерева.
Project Kaiser позволяет также осуществлять декомпозицию требований: требование может быть разделено на ряд подзадач или связанных требований, и реализовано разными людьми или даже отделами. В последствии можно проследить какая задача послужила причиной создания того или иного требования, и наоборот - изменения в каких подсистемах были сделаны в результате реализации требования, какие задачи и кем были сделаны для реализации требования.
Вы можете ознакомиться с демонстрационными материалами на домашней странице программы. Также вы сможете найти там ссылки на документацию, форумы поддержки и прочее. Программу можно скачать на сайте и пользоваться бесплатно, пока количество пользователей не превышает пяти.