Спецификация требований не содержит деталей проектирования или реализации (кроме известных ограничений), данных о планировании проекта или сведений о тестировании (Letfingwell и Widrig, 2000). Удалите указанные элементы из требований, чтобы из этого документа было абсолютно ясно, что надлежит построить команде разработчиков. Для проекта, как правило, создаются требования других типов: документ, где описана среда разработки, ограничения бюджета, руководство пользователя или требования для выпуска продукта и продвижения его в поддерживаемую среду. Все это относится к требованиям к проекту, но не к продукту, поэтому они не будут рассмотрены в этой книге.
Разработка и управление требованиями
Путаница, которая возникает, как только речь заходит о требованиях затрагивает даже то, что именно называть этим словом. Некоторые авторы называют целую область разработкой технических условий. (requirements engineering) (Sommerville и Kotonya, 1998); другие употребляют термин управление требованиями (requirements management) (Leffingwell и Widrig, 2000). Я считаю полезным разделить область разработки технических условий на разработку требований (requirements development) — подробнее об этом в части II этой книги — и управление требованиями (requirements management) — см. часть III, как показано на рис. 1-2.
Рис. 1-2. Компоненты области разработки технических условий
Разработка требований
Далее мы можем подразделить этот этап на извлечение (elicitation), анализ (analysis), документирование(specification) и утверждение(validation) (Abran и Moore, 2001). В эти подэтапы входят все действия, включающие сбор, оценку и документирование требований для ПО или ПО-содержащих продуктов, в том числе:
· идентификация классов пользователей для данного продукта;
· выяснение потребностей тех, кто представляет каждый класс пользователей;
· определение задач и целей пользователей, а также бизнес-целей, с которыми эти задачи связаны;
· анализ информации, полученной от пользователей, чтобы отделить задачи от функциональных и нефункциональных требований, бизнес правил, предполагаемых решений и поступающих извне данных;
· распределение высокоуровневых требований по компонентам: к определенным в системной архитектуре;
· установление относительной важности атрибутов качества;
· установление приоритетов реализации;
· документирование собранной информации и построение моделей;
· просмотр спецификации требований, который позволяет удостовериться в том, что запросы пользователей всеми понимаются одинаково, и устранение возникших проблем до передачи документа разработчикам.
Постепенность процесса — ключ к успеху разработки требований. Планируйте цикличность исследования требований, детализируйте высокоуровневые требования и уточняйте их корректность у пользователей. Выполнение этих задач требует времени и может разочаровать, однако это важный аспект работы с неясно определенным новым ПО.
Управление требованиями
Этот этап определяется как «выработка и поддержание взаимного согласия с заказчиками по поводу требований к разрабатываемому ПО» (Paulkи др., 1995). Это соглашение воплощается в спецификации (в письменной форме) и моделях. Одобрение пользователей — только половина дела. Разработчики также должны принять задокументированные требования и высказаться за создание этого продукта. К действиям по управлению требованиями относятся:
· определение основной версии требований (моментальный срез требований для конкретной версии продукта);
· просмотр предлагаемых изменений требований и оценка вероятности воздействия каждого изменения до его принятия;
· включение одобренных изменений требований в проект установленным способом;
· согласование плана проекта с требованиями;
· обсуждение новых обязательств, основанных на оцененном влиянии изменения требований;
· отслеживание отдельных требований до их дизайна, исходного кода и вариантов тестирования;
· отслеживание статуса требований и действий по изменению на протяжении всего проекта.
На рис. 1-3 показан другой способ разделения областей разработки требований и управления ими. В этой книге описано несколько дюжин специальных приемов для выполнения извлечения требований, их анализа, документации, проверки и управления,
Рис. 1-3. Разделение областей разработки требований и управления ими