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

Затем за работу принимается аналитик. Ему необходимо из этой кучи хлама создать документ, в котором четко сформулированы все требования, предъявляемые к разрабатываемой программной системе. Результатом этой работы является ТЗ, один из основных документов, которыми руководствуется разработчик ПП.

Требование – это условие или характеристика, которым должна удовлетворять система. Каждое требование может быть описано любым удобным набором атрибутов. Компоновать требования можно по любому удобному критерию.

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

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

Нефункциональные требования описывают атрибуты разрабатываемого ПП или атрибуты системного окружения. Существует несколько типов нефункциональных требований:

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

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

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

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

-требования к интерфейсу, определяющие внешние сущности и регламент взаимодействия с ними.

Управление требованиями представляет собой:

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

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

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

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

-необходимо выполнить,

-желательно выполнить,

-можно выполнить.

Требования, предъявляемые к разработке, могут быть смоделированы при помощи различного рода диаграмм, но они, как правило, служат для понимания требований, а не для управления ими в динамике. Именно динамическая составляющая управления требованиями вызывает наибольшие трудности, т.к. в процессе разработки могут измениться не только требования к ПП, но и их приоритеты. В настоящее время появились специальные программные системы управления требованиями (Requirements Management Systems, RequisitePro, DOORS). Кроме того, полезно для каждого требования хранить его историю, которая помогает отследить: какие изменения были внесены в требования, кем, когда и почему.

Еще раз про управление требованиями и системы управления требованиями, или мифы про Agile


Читать еще…

Понравилась статья? Поделиться с друзьями: