|
|
@@ -0,0 +1,60 @@
|
|
|
+# Требования АИС
|
|
|
+**Автоматизированные информационные системы (АИС)** — это комплекс программных и технических средств, предназначенных для автоматизации процессов обработки, хранения и передачи информации. Их эффективная работа зависит от правильного формирования требований, что обеспечивает их соответствие нуждам пользователя и безопасности.
|
|
|
+
|
|
|
+Требования к автоматизированным информационным системам (АИС) представляют собой совокупность характеристик, которыми должна обладать система для эффективного решения поставленных задач и удовлетворения потребностей пользователей. Формирование этих требований является критически важным этапом жизненного цикла разработки, так как от их точности зависит качество итогового программного продукта.
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+### Основные виды требований к АИС
|
|
|
+Все требования к АИС традиционно разделяются на несколько крупных категорий. Первую группу составляют **функциональные требования**. Они определяют перечень конкретных задач, которые должна выполнять система: от способов обработки данных и формирования отчетности до реализации специфических алгоритмов вычислений. По сути, этот блок отвечает на вопрос, что именно делает система.
|
|
|
+
|
|
|
+Вторая группа включает **нефункциональные требования**, которые описывают свойства системы и ограничения среды. К ним относится производительность, определяющая время отклика и пропускную способность АИС при различных нагрузках. Не менее важна надежность, подразумевающая бесперебойную работу и способность системы восстанавливаться после сбоев. Сюда же входят требования к безопасности, обеспечивающие защиту информации от несанкционированного доступа и целостность данных.
|
|
|
+
|
|
|
+Отдельным блоком выделяют **эргономические требования** и требования к интерфейсу. АИС должна быть удобной для конечного пользователя, иметь интуитивно понятную навигацию и соответствовать стандартам юзабилити. Это минимизирует количество ошибок персонала и сокращает время на обучение сотрудников.
|
|
|
+
|
|
|
+**Технические требования** определяют программно-аппаратную платформу, на которой будет функционировать система. Они включают характеристики серверов, рабочих станций, сетевого оборудования, а также совместимость с операционными системами и базами данных. Также учитываются требования к масштабируемости, позволяющие системе расширяться по мере роста объема данных или количества пользователей.
|
|
|
+
|
|
|
+Заключительным этапом работы с требованиями является их **документирование**, обычно оформляемое в виде Технического задания (ТЗ). Грамотно составленный перечень требований служит инструментом контроля для заказчика и дорожной картой для разработчиков, гарантируя, что созданная АИС будет полностью соответствовать ожиданиям бизнеса.
|
|
|
+
|
|
|
+### Процесс формирования требований
|
|
|
+Процесс формирования требований к автоматизированной информационной системе (АИС) представляет собой циклическую и многоступенчатую деятельность, направленную на определение того, что именно должна делать система и в каких условиях она будет работать.
|
|
|
+
|
|
|
+**Предварительное обследование и сбор данных**
|
|
|
+Начальный этап фокусируется на погружении в предметную область. Проводится интервьюирование руководства и линейных сотрудников, анкетирование и наблюдение за рабочими местами. Важным элементом является изучение документооборота и нормативно-правовой базы, регулирующей деятельность организации, чтобы будущая АИС соответствовала законодательным и внутрикорпоративным стандартам.
|
|
|
+
|
|
|
+**Выявление бизнес-требований**
|
|
|
+Здесь определяются высокоуровневые цели проекта: какие проблемы бизнеса должна решить система и какую выгоду принести (например, сокращение времени обработки заявок на 30%). Бизнес-требования описывают «зачем» нужна система, не углубляясь в детали реализации.
|
|
|
+
|
|
|
+**Формирование функциональных требований**
|
|
|
+Этот этап описывает конкретное поведение системы — ее функции и задачи. Аналитики фиксируют, какие данные система должна принимать, как их обрабатывать, какие отчеты формировать и какие алгоритмы вычислений использовать. Часто для описания функциональности применяются сценарии использования (Use Cases), которые показывают взаимодействие пользователя с АИС для достижения конкретной цели.
|
|
|
+
|
|
|
+**Определение нефункциональных требований**
|
|
|
+Параллельно прорабатываются системные ограничения и характеристики качества. К ним относятся требования к производительности (время отклика), надежности (среднее время наработки на отказ), безопасности (уровни доступа, шифрование) и масштабируемости. Также учитываются требования к интерфейсу, чтобы обеспечить удобство работы пользователей разного уровня подготовки.
|
|
|
+
|
|
|
+**Документирование и моделирование**
|
|
|
+Все собранные данные систематизируются в спецификации (например, Техническое задание по ГОСТ или SRS). Для визуализации логики работы строятся модели данных (ER-диаграммы) и диаграммы потоков данных (DFD), что позволяет разработчикам увидеть архитектурную структуру будущей системы еще до написания кода.
|
|
|
+
|
|
|
+**Проверка и утверждение**
|
|
|
+Финальная стадия, на которой требования проверяются на полноту, непротиворечивость и реализуемость. Проводится совместная вычитка документа аналитиками, заказчиками и архитекторами системы. После достижения консенсуса требования фиксируются в качестве базиса для разработки, и любые изменения в них после этого момента обычно проходят через официальную процедуру контроля изменений.
|
|
|
+
|
|
|
+### Значение требований для успешной реализации АИС
|
|
|
+**Минимизация рисков и затрат**
|
|
|
+Четко сформулированные требования позволяют обнаружить ошибки и недопонимания на ранних стадиях, когда стоимость внесения изменений минимальна. Отсутствие двусмысленности предотвращает ситуации, при которых разработчикам приходится переделывать готовые модули из-за неверной интерпретации ожиданий заказчика.
|
|
|
+
|
|
|
+**Основа для планирования и оценки**
|
|
|
+На базе детальных требований руководитель проекта может точно рассчитать объем необходимых ресурсов, бюджет и сроки реализации. Это позволяет сформировать реалистичный график работ и избежать «раздувания» рамок проекта, когда в процессе разработки бесконтрольно добавляются новые функции.
|
|
|
+
|
|
|
+**Критерий качества и успешности**
|
|
|
+Документированные требования являются эталоном, по которому проверяется готовый продукт. Для специалистов по тестированию они служат основой для написания тест-кейсов. Система считается успешной только в том случае, если она полностью соответствует утвержденным критериям, выполняет заложенные бизнес-задачи и удовлетворяет потребностям пользователей.
|
|
|
+
|
|
|
+**Эффективная коммуникация**
|
|
|
+Требования выступают в роли общего языка между заказчиком, который описывает бизнес-проблему, и исполнителями, которые предлагают техническое решение. Это гарантирует, что все стороны одинаково понимают конечную цель и ожидаемый результат, что значительно снижает вероятность конфликтов при приемке системы.
|
|
|
+
|
|
|
+
|
|
|
+###### Заключение. Правильное определение и документирование требований к АИС — залог её успешного внедрения и эксплуатации. Это обеспечивает системную стабильность, безопасность и удобство использования, что в конечном итоге способствует достижению бизнес-целей.
|
|
|
+
|
|
|
+Список Литературы:
|
|
|
+1. https://www.edsd.ru/files/pdf/GOST-34.602-2020.-Tehnicheskoe-zadanie-na-sozdanie-avtomatizirovannoj-sistemy.pdf
|
|
|
+2. https://normativ.kontur.ru/document?moduleId=9&documentId=442605
|
|
|
+3.https://eduherald.ru/article/viewid=21418&utm_source=yandex.ru&utm_medium=organic&utm_campaign=yandex.ru&utm_referrer=yandex.ru
|
|
|
+4. https://redmine.tomsk.gov.ru/projects/ais-req/wiki/Типовое_ТЗ_на_создание_АС
|
