Уровень 4. Трассировка требований

Реализация предыдущих трех уровней модели зрелости для управления требованиями не дает вам возможности определять и прослеживать взаимосвязь между требованиями. Система любой сложности должна иметь иерархичность требований. Например, в RUP (Rational Unified Process) иерархия требований прослеживается между бизнес-потребностями, характеристиками ПО, вариантами использования и системными требованиями. Возможность отслеживать данную взаимосвязь обычно называется трассировкой. Трассировка дает возможность проследить влияние требований друг на друга и провести анализ покрытия требований.

При изменении одного требования аналитику важно знать, какие еще требования должны при этом измениться – это и называется прослеживанием влияния требований друг на друга. А после того как мы описали набор требований, нам необходимо знать, все ли требования верхнего уровня были детализированы и описаны на более низком уровне. Последнее называется «анализ покрытия требований».

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

На данном этапе становится очевидно, что управлять требованиями в полном объеме очень трудно без специализированных средств. Здесь нам на помощь приходят системы управления требованиями, такие как: IBM Rational RequisitePro, IBM Rational Composer, IBM Telelogic Doors, или IBM Telelogic Focal Point.

Уровень 5. Интеграция требований

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

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

Интеграция требований в процесс управления изменениями даст уверенность, что требования не добавляются без тестирования и утверждения. И что любое изменение не будет добавлено в ПО, не пройдя стадию анализа.

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

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

Безусловно, такая плотная интеграция нужна в больших проектах и требует немалых затрат на закупку специальных средств по разработке ПО на всех ее стадиях. И, безусловно, пальму первенства в инструментарии полного жизненного цикла ПО (Application Lifecircle Management – ALM) держат линейки IBM Rational и IBM Telelogic.

Преимущества качественного процесса управления требованиями

Улучшение процесса сбора, анализа, документирования, проверки и управления требованиями дает следующие ощутимые преимущества:

• уменьшение ошибок и издержек при выпуске ПО;

• повышение удовлетворенности заказчика и качества ПО;

• уменьшение времени разработки ПО;

• ужесточение контроля над изменениями;

• повышение точности планирования;

• повышение точности стратегического развития комплекса ПО на предприятии;

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

• повышение производительности аналитиков и других членов команды;

• улучшение обмена информацией по проектам;

• повышение заинтересованности заказчика;

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

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