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

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