Формирование требований к автоматизированной системе

Формирование требований к системе начинается со сбора необходимой для этого информации. На первом этапе работ проводится обследование компании, которое необходимо для формирования представлений о компании, ее целях, задачах и автоматизируемых бизнес-процессах. Также необходимо описать информационный ландшафт компании, чтобы определить в нем место для внедряемого решения. Существует несколько различных подходов к обследованию объекта автоматизации: экспресс-обследование и информационное обследование [10].

Экспресс-обследование компании

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

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

• · Краткое описание компании: виды деятельности, организационную и функциональную структуры.
• · Описание основных бизнес-процессов компании (as is — как есть).
• · Уровень автоматизации процессов, используемое в компании программное обеспечение и задействованные технические мощности.
• · Описание проблем, выявленных в компании.
• · Пожелания заказчика и варианты решения, концепцию будущей системы, с помощью которой будут совершенствоваться процессы (to be — как будет).

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

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

Информационное обследование компании

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

• · Сбор информации о компании (документации, анкет, интервью и т. д.).
• · Анализ и систематизация данных, полученных в ходе первого этапа.
• · Представление результатов для согласования с заказчиком.

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

Основными источниками информации для обследования (как для экспресс, так и для информационного) являются анкеты, интервью и внутренняя документация компании-заказчика. Для наилучшей оценки ситуации в компании составляются три вида анкет:

• · Анкеты для топ-руководителей;
• · Анкеты для линейных руководителей;
• · Анкеты для линейного персонала.

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

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

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

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

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

Следующим этапом работ является непосредственно формирование требований к автоматизированной системе.

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

Требования по методике Карла Виргеса

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

Функциональные требования:

• · Бизнес-требования — это высокоуровневые требования, содержащие цели заказчиков, спонсоров и организации в целом. Это цели, ради которых разрабатывается система. Данные требования фиксируются в документе концепции и границ или же уставе проекта.
• · Пользовательские требования — это требования, описывающие цели и задачи, которые система позволяет решать пользователям. Для иллюстрации данных требований используются диаграммы вариантов использования и сценариев.
• · Функциональные требования — требования, определяющие функциональность информационной системы, которая должна быть построена разработчиками, чтобы пользователи могли выполнять задачи для достижения целей сформулированных в рамках бизнес-требований.

Нефункциональные требования:

• · Бизнес-правила не являются требованиями в общепринятом смысле, но они являются источниками для требований к ИС. Бизнес-правилами могут быть политики, стандарты, регламенты и предписания, которые ограничивают или определяют ход бизнес-процессов.
• · Атрибуты качества — это требования, которые являются дополнительным описанием функций системы или ее производительности. Такими требованиями могут быть простота использования, логичность, отказоустойчивость, устойчивость к сбоям и прочие.
• · Ограничения — технические ограничения на разработку вида и структуры продукта.
• · Внешние интерфейсы — требования, описывающие взаимодействие меду системой и пользователем или другим ПО.

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

FURPS и FURPS+

Данная методика позволяет охватить все аспекты системы и является более широким представлением методики FURPS. Обе методики основаны на методике Карла Виргеса и делят требования на функциональные и нефункциональные, однако далее имеют немного отличающуюся логику деления. Название методики является аббревиатурой [12]:

• · Functionality (Функциональность) — это все требования, которые касаются функционального назначения системы. Сюда входят: безопасность, отчетность, лицензирование, ведение журнала и другие.
• · Usability (Удобство использования) — это требования, основанные на человеческом факторе. То есть субъективные пожелания пользователей системы. В данные требования могут быть включены требования к интерфейсу (его интуитивная понятность, эстетичность, логичность), к эксплуатационной документации (ее полнота и понятность), а также к защите от ошибок.
• · Reliability (Надежность) — данное требование к системе подразумевает ее способность работать в условиях высокой нагрузки и под воздействием неблагоприятных факторов. Требованиями к надежности могут быть доступность системы, отказоустойчивость и восстанавливаемость, время и частота сбоев, точность вычислений.
• · Performance (Производительность) — эти требования адресованы к объему информации, который может проходить через систему во время ее работы. Например, пропускная способность, время отклика, потребление ресурсов, масштабируемость и другие.
• · Supportability (Поддерживаемость) — это требования к обеспечению технической поддержки, то есть к тому как система может быть адаптирована, совместима с другими системами, конфигурируема. Также к этому типу требований относятся требования к поддержке системой стандартов, языков, валюты, времени, и то, как легко система устанавливается.

В методике FURPS+ помимо требований первоначального стандарта, были добавлены некоторые ограничения:

• · Ограничения проектирования — ограничения, которые влияют на границы проектных решений, в соответствии с которыми буде разрабатываться система.
• · Ограничения разработки — это ограничения, которые задают необходимые стандарты кодирования: язык программирования, стандарты, инструменты или платформы.
• · Ограничения на интерфейсы — требования к взаимодействию с другими системами, которые формируются пользователями.
• · Физические ограничения — это ограничения, которые оказывают влияние на аппаратную часть системы (размер, вес, условия работы и т. д)

SWEBOK

Как и FURPS, SWEBOK является аббревиатурой (Software Engineering Body of Knowledge). Это документ призванный объединить в себе знания по разработке программного обеспечения и содержащий 10 различных областей знаний, первой из которых является инженерия требований.

Согласно данному документу работа над формированием требований должна проходить в несколько этапов: определение, анализ, спецификация, проверка и управление, а область знаний «Требования к программному обеспечению» состоит из 6 разделов [13]:

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

Данные подходы к формированию требований могут быть применены в различных проектах, в зависимости от конкретной ситуации. Так методика Карла Виргеса является одной из первых методик, на которой были основаны ряд других. Методики FURUPS схожи с данной методикой, однако требования в них не привязаны к определенным регламентирующим документам. Последняя методика (SWEBOK) сформулирована в результате сбора и анализа многолетнего опыта разработки программного обеспечения и описывает этапы сбора требований.