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

   1. Спецификация требований согласно следующей структуре

№ требования (идентификационный код)	Определение требования (требование описывается в свободном стиле )	Приоритет (высокий, средний, низкий – отражает важность требования, используется для выработки порядка его выполнения)	Краткое описание (как можно короче – от 2 до 6 слов )

2. Разделение требований по типу

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

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

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

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

• Отдел администрирования предприятия (отвественный за принятие решений);

• Научно-исследовательский отдел и отдел научно-технического развития предприятия;

• Отдел поставок основного сырья необходимого для производства;

• Производственный отдел, который отвечает за основное производство либо за предоставление определенных услуг;

• Отдел продаж (предоставления) основных продуктов и услуг предприятия;

• Складской отдел;

• Отдел кадров;

• Бухгалтерия (отдел финансовой отчетности)[1].

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

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

Примечание: Органиграмма может быть построена

- для организации в целом;

- для части организации – она отображает функции одного отдела либо нескольких компонент организации.

Основные правила, применяемые при построении органиграммы:

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

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

3. Сложные органиграммы должны содержать легенды.

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

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

Другая диаграмма - нулевого уровня - показывает основные подсистемы анализируемой системы и взаимодействие этих подсистем с местом скопления данных и внешними сущностями, указанными в контекстной диаграмме.

Для кажной из подсистем, указанных на диаграмме нулевого уровня, будут строиться диаграммы первого уровня, которые отображают все основные процессы данной подсистемы. Для облегчения восприятия процессы детализируемой подсистемы нумеруют, соблюдая иерархию номеров: так процессы, полученные при детализации процесса или подсистемы «1», должны нумероваться «1.1», «1.2» и т.д. Кроме этого желательно размещать на каждой диаграмме от 3-х до 6-7-ми процессов и не загромождать диаграммы деталями, не существенными на данном уровне.

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

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

Синтаксис диаграмм потоков данных (Data Flow Diagram)[1, 2, 3]:

Обозначение		Пояснения
Нотация Жордана-ДеМарко	Нотация Гейна-Сарсона
		- Процесс преобразования входящего потока данных в выходящий информационный поток; - система либо подсистема Например, для системы или подсистемы надпись содержит текст «система учета заказов». Для процесса надпись представляет собой глагольную форму - «принятие и регистрация заказов».
		Место скопления данных. Текст отображает содержание всех тех данных которые хранятся в месте скопления, например, «данные о клиентах»
		Поток данных, отображает передачу потока данных либо информационного потока между разными сущностями. Текст поясняет логический или физический поток данных, например «данные о заказе клиента» или «счет-фактура»
		Внешняя сущность. Она обычно находится за границей системы и является источником либо приемником информационного потока (данных). Поясняющий текст должен быть существительным в единственном числе, например, «клиент», «кассир», «поставщик».

Модель, соответсвующая этапу анализа, называется моделью анализа либо информационная модель.

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

Требования к ИС можно раздель на функциональные и нефункциональные [6]:

• Функциональные требования – это перечень сервисов, которые должна выполнять система, причем должно быть указано, как система реагирует на те или иные вход­ные данные, как она ведет себя в определенных ситуациях и т.д. В некоторых слу­чаях указывается, что система не должна делать.

• Нефункциональные требования - описывают характеристики системы и ее окружения, а не поведение системы. Здесь также может быть приведен перечень ограничений, наклады­ваемых на действия и функции, выполняемые системой. Они включают временные ограничения, ограничения на процесс разработки системы, стандарты и т.д. В этот список можно добавить требования по защите информации, по используемой технике, требования предметной области где будет внедренена АИС. Одну из структур технического задания, содержащюю требования к АИС можно найти здесь http://lex.justice.md/viewdoc.php?action=view&view=doc&id=316454&lang=2, anexa).

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

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