Разработка требований к информационной системе - SearchInform

Разработка требований к информационной системе

ИБ-аутсорсинг
на базе DLP-системы

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

Понятие информационной системы

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

Соответственно, разрабатывая требования к ИС, необходимо учитывать, что они будут складываться из требований к ее составляющим:

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

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

Отличия информационных систем для компаний разной величины 

Архитектура системы зависит от того, каким бизнесом занимается фирма, Жизнеспособность ИС опирается на два фактора:

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

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

Как разработать требования к ИС

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

На первом этапе необходимо собрать запросы от подразделений, которые станут пользователями системы:

  • аппарат управления;
  • производственные службы;
  • сбытовые подразделения;
  • делопроизводители;
  • бухгалтерия.

Свои задачи к программному обеспечению поставят отделы НИОКР, юристы, маркетологи. Дополнительные требования заявят IТ-службы, работающие с системой. 

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

Запросы пользователей выявляются различными способами, среди которых: 

  • анкетирование;
  • создание фокус-групп;
  • тренинги, в ходе которых сотрудники компании моделируют идеальную архитектуру ИС.

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

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

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

Требования к информационной системе, описанные в ТЗ, на практике должны отвечать следующим критериям:

  • единичность. Одна задача касается одного элемента системы;
  • завершенность. После реализации ТЗ система не должна требовать доработок;
  • последовательность. Поставленные задачи должны быть реализуемыми и не противоречащими друг другу;
  • актуальность. Система не должна требовать обновления сразу после внедрения;
  • выполнимость. Нерешаемые задачи не должны попасть в ТЗ;
  • обязательность. Если существуют требования к ИС, обусловленные бизнес-процессами или действующим законодательством, они должны быть учтены;
  • проверяемость. Решение задач должно быть проверяемо в процессе аудита. 

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

  • нормативно-правовое регулирование. Так, нормы ФСТЭК России определяют типы программных продуктов, для защиты персональных данных или государственной тайны; при участии в тендерах на госзакупки есть потребность в генерации электронной подписи определенных типов, способной работать только с собственными программными продуктами;
  • корпоративные политики, где прописываются уровни допуска к информации, стандарты безопасности, особенности работы с компьютерами;
  • структуру организации, которая предполагает кластеризацию системы, выделение отдельных блоков с разной архитектурой;
  • аналитику по эффективности использования аппаратных и программных средств, внедренных ранее; 
  • описание бизнес-процессов, выполненное как вручную, так и программными средствами.

Данные ложатся в основу модели ИС, которая согласовывается вновь и наполняется конкретными цифрами и сроками. Бюджетные и временные характеристики опираются на необходимость установки конкретного оборудования или программного обеспечения и стоимость оборудования, лицензий, учитывают потребность в доработке программных продуктов, время на монтаж и внедрение элементов. При разработке требований можно руководствоваться и ГОСТ 34.602-89 «Техническое задание на создание автоматизированной системы». Если требования ГОСТа учитываются, снижается риск конфликта интересов и разработка системы идет быстрее. Если модель системы подлежит согласованию, например, с вышестоящими организациями, утвердить предложенное решение будет легче. 

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

28.11.2019

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