Система управления требованиями

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

Пример требования: расход бензина а/м должен быть не выше 10 л/100км.

Таким образом Техническое Задание (ТЗ) — есть ни что иное, как изначальный набор требований, предоставленный заказчиком и достаточный для производства продукта. Правильность и четкость постановки требований является крайне важным моментом, поскольку ошибки на данном этапе могут привести к тому, что конечный продукт не будет удовлетворять заказчика. На этапе постановки требований они должны постоянно уточняться и утверждаться заказчиком.

Управление требованиями к системе — это руководство процессами формирования требований на всех этапах жизненного цикла.

Рис.1: Управление требованиями к системе

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

Рис.2: Иерархическое представление требований

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

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

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

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

Таким образом, можно сформулировать ожидаемые характеристики современной системы управления требованиями:

1. Программа должна предоставлять возможности по созданию и структурированию (группировке) требований;
2. Требования должны включать в себя ряд свойств, такие как статус, исполнитель, ответственный, бюджет, сроки исполнения, приоритет и этап разработки;
3. Текстовое описание должно быть основной частью требования. Желательна возможность форматирования текста (таблицы, эффекты, списки);
4. Должна быть предоставлена возможность обсуждения требования участниками проекта и сохранения истории обсуждения как неотъемлемой части требования;
5. Желательно иметь возможность прикреплять файлы к требованиям;
6. Необходимо иметь возможность отслеживать взаимосвязи требований друг с другом;
7. Желательно иметь возможность отслеживать связи требований с другими задачами. Данный пункт имеет связь с понятием системы управления задачами: например, задача на исправление дефекта продукта, заявленная в разделе отслеживания ошибок, может повлечь создание нового требования к продукту.

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

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

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

Tweet

Вернуться в раздел "Ресурсы"

См. также:

• Декомпозиция задач - управление требованиями в Project Kaiser (статья из документации к программе);
• Статья о cистемах управления задачами: основные сведения и примеры управления задачами;
• Преимущества и недостатки онлайн управления проектами.