Методы определения требований в программной инженерии

3.1.2. Анализ и сбор требований

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

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

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

Современные ПС предоставляют набор услуг для выполнения функций ПрО, которые ориентированны на определенную профессиональную деятельность пользователей (например, веб-сервисы). Лицо, которое заказало проект системы, желает получить от разработчика набор необходимых услуг. К участникам системы относятся операторы, менеджеры разных уровней, бухгалтеры и т.п. Именно они будут обращаться к системе за услугами, получать от нее сообщения, реагировать на них в соответствии со своими профессиональными обязанностями.

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

• спектра проблем ПрО, при решении которых будут реализованы услуги системы;
• функциональное содержание услуг;
• операционную среду работы системы.

В обсуждении требований на систему принимают участие:

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

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

Анализ требований начинается после обсуждения проблематики проекта. При рассмотрении требований среди них могут оказаться

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

Разработчики требований должны обладать определенными знаниями в данной предметной области и уметь провести:

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

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

Ошибки по причине нечетких или неоднозначных формулировок требований, которые могут привести к тому, что будет изготовлена система, не удовлетворяющая заказчика. Поэтому на этапах разработки требования должны постоянно уточняться и переутверждаться заказчиком. В отдельных случаях внесенные изменения в требования могут привести к необходимости перепроектировать отдельные части или всю систему в целом. Согласно статистике, доля ошибок в постановке требований и в определении задач системы превышает долю ошибок, допускаемых во время кодирования системы. Это объясняется субъективным характером процесса формулирования требований и отсутствием способов их формализации. В США, например, ежегодно расходуется до $ 82 млрд. на проекты, признанные после реализации не соответствующими требованиям заказчиков.

Существующие стандарты (ГОСТ 34.601-90 и ГОСТ 34.201-89) на разработку требований к системе и документам фиксируют результаты создания программного, технического, организационного и др. видов обеспечения автоматизированных систем на этапах ЖЦ.

Сбор требований.Источниками сведений для формирования требований могут быть:

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

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

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

Методы сбора требований следующие:

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

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

При определении требований, относящихся к внешним и внутренним характеристикам качества, выбираются методы их достижения на процессах ЖЦ. Внутренние характеристики предназначены для достижения необходимых внешних показателей качества и применяются при оценке промежуточных (рабочих) продуктов ПС на процессах ЖЦ.

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

3.1.3. Инженерия требований

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

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

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

Качество и процесс улучшения требований - это процесс проверки характеристик и атрибутов качества (надежность, реактивность и др.), которыми должна обладать система и ПО, методы их достижения на процессах ЖЦ.

Управление требованиями к системе - это руководство процессами формирования требований на всех этапах ЖЦ, которое включает управление изменениями требований, отражающих свойства программного продукта, а также восстановление источника требований. Неотъемлемой составляющей процесса управления является трассирование требований, состоящее в отслеживании правильности задания и реализации требований к системе и ПО на этапах ЖЦ и обратный процесс сверки ПС с заданными требованиями.

Основные задачи управления требованиями это:

• разработка атрибутов требований,
• управление вариантами требований,
• управление рисками, возникающими при неточном определении требований,
• контроль статуса требований, измерение усилий при формировании требований;
• реализация требований на этапах ЖЦ.

Разработка и управление требованиями связана с другими областями знаний (рис. 3.2.): проектирование, интеграция, управление качеством, версиями, рисками и др. Кроме того, приведены основные задачи разработки требований: спецификация и утверждение, формирование проектных решений.

Рис. 3.2. Разработка, управление требованиями и связь с задачами SWEBOK

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

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

3.1.4. Фиксация требований

Сбор требований является начальным этапом процесса разработки ПС, завершается формированием списка требований к системе, именуемого в отечественной практике техническим заданием. Фиксация требований (Requirement Capturing) в техническом задании определяется желаниями заказчика получить при реализации заданные им свойства системы. При этом предусматривается спецификация, верификация и валидация требований на правильность, соответствие и полноту.

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

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

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