Рубрики

Технические требования к информационной системе

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

требования к безопасности информационных систем

Общее понимание вопроса

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

Внимание всем деталям

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

Какие бывают?

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

требования к информационным системам персональных данных

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

Требования: откуда их взять?

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

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

Не все так однозначно

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

утверждение требований к информационной системе

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

Как это выглядит?

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

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

Продолжая работу

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

требования к информации в информационных системах

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

Шаг за шагом

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

Чтобы процесс формирования требований был эффективным, а его результаты – применимыми в работе, необходимо следовать общепринятым алгоритмам формулировки условий.

Опорные точки зрения

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

требования к данным информационной системы

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

Альтернативный подход

Еще одна трактовка понятия «точка зрения» предполагает восприятие термина как структуры представления. Фактически речь идет об элементе модели продукта. Различные точки зрения позволяют создать многочисленные модели конечных автоматов, взаимодействия сущностей и связей между ними в рамках конкретного проекта. Учитывается специфика области применения проекта.

Точка зрения может означать мнение внешнего получателя сервиса, реализованного через ИС. На основании ТЗ можно выявить данные, которые используются при воплощении сервисов системы, управлении таковыми. Этот подход принято считать самым эффективным. Он лег в основу Viewpoint-Oriented Requirements Definition – специфического метода выявления требований, позволяющего определять информацию и эффективно анализировать ее.

Работа с точками зрения

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

требования к муниципальным информационным системам

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

Не торопиться!

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

Аттестация требований

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

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

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