Анализ требований при проектировании ИС

Анализ требований является первой фазой разработки ИС, на которой требования заказчика уточняются, формализуются и документируются.
Фактически на этом этапе дается ответ на воп­рос: «Что должна делать будущая система?».
Именно здесь лежит ключ к успеху всего проекта.
В практике создания больших систем известно немало примеров неудачной реализации проекта именно из-за неполноты и нечеткости определения системных требований.

• Оргштатная структура предприятия это — инструмент управления деятельностью предприятия в соответствии с его «миссией» (как говорится в наставлениях по менеджменту), т.е. в соответствии с целями, ради достижения которых предприятие создавалось.;

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

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

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

РАЗРАБОТКА ТЕХНИЧЕСКОГО ЗАДАНИЯ
После построения модели, содержащей требования к будущей системе, на ее основе осуществляется разработка Технического задания на создание системы, включающего в себя:

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

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

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

Безусловно, ручные системы имеют и массу недостатков. В отличие от машин люди болеют, увольняются, требуют повыше­ния зарплаты.
Однако наиболее важно, что размер и сложность ручной системы будут возрастать с увеличением числа запросов, поскольку человек может обрабатывать меньше данных, чем машина.

После определения границ ручной реализации необходимо ре­шить, какая часть системы должна быть пакетной, а какая диалоговой.
Для большинства современных предприятий вся АСУП должна быть диалоговой, если только не доказано противное. Соответствующее заключение может быть сделано на основе собранных статистических данных, например скорости поступления запросов и частоты изменения данных. В качестве примеров причин для пакетной реализации можно привести следующие:

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

• На основании выявленных требований разрабатывается тех­ническое задание (ТЗ) и, по необходимости, частные
ТЗ на ее компоненты (подсистемы). ТЗ создается на основе
ГОСТ 34.602—89. Техническое задание на создание автоматизированной системы и включает в себя следующие основные раз­делы:

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

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

Раздел Характеристика объекта автоматизации
• приво­дятся общие сведения о предприятии согласно его уставу, пере­чень основных видов деятельности и бизнес-процессов, пере­чень бизнес-процессов, подлежащих автоматизации, характеристики видов обеспечения - организационного, методическо­го, программного, технического, лингвистического, математиче­ского, правового и информационного.

Раздел Требования к системе
• включает следующие три под­раздела:
требования к системе в целом,
требования к функциям,
требования к видам обеспечения.
В подразделе Требования к системе в целом содержатся:

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

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

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

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

Воз­можный перечень необходимых документов
Частное техническое задание - в соответствии с ГОСТ 34.602-89.
Описание информационного обеспечения - в соответствии с РД 50-34.698-90, п. 5.3. (при необходимости).
Описание программного обеспечения - в соответствии с РД 50-34.698-90, (РУКОВОДЯЩИЕ ДОКУМЕНТЫ)
Инструкция по обозначениям и кодированию (при необхо­димости).
Альбом выходных форм.
Руководство администратора подсистемы.
Руководство пользователя - в соответствии с РД 50-34.698-90, п. 3.4.
Программа и методика испытаний - в соответствии с РД 50-34.698-90, п. 2.14.

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