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

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

Модель описания требований FURPS+ [1]  делит их на следующие категории:

-       Функциональные требования — свойства, возможности, безопасность.

-       Нефункциональные требования:

• Удобство — человеческий фактор, справочная система, документация.
• Надежность — частота сбоев, возможность восстановления и предсказуемость поведения.
• Производительность — время отклика,  точность, доступность,  использование ресурсов.
• Возможность поддержки — адаптивность, возможность поддержки соответствие международным стандартам, возможность конфигурирования.
• Реализация — требования к ресурсам, языки и средства, аппаратное обеспечение.
• Интерфейс – ограничения накладываемые необходимостью взаимодействия с внешними системами.
• Операции — управление системой и ее параметры.

Категории FURPS+ необходимо использовать при формулировке требований, чтобы не упустить важные аспекты жизнедеятельности системы. Некоторые из этих требований (удобство, надежность, производительность и возможность поддержки) называются атрибутами качества (quality attributes).

Для выявления требований существуют следующие методы:

-       Определение требований на основе точек зрения (Viewpoint-Oriented Requirements Definition (VORD))  [2]

-       Этнографический подход [2]

-       Варианты использования [3]

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

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

Предварительный анализ показывает, что весь набор критериев оценки может быть сведен в шесть основных групп:

1. Критерии, относящиеся к вводу и валидации данных.
2. Критерии, относящиеся к обработке и хранению данных.
3. Критерии, относящиеся к формированию отчётной документации.
4. Критерии, относящиеся к мониторингу.
5. Критерии, относящиеся к администрированию системы.
6. Критерии, относящиеся к технологической платформе ИСМ.

К функциональным требованиям к ИСМ на этапе ввода и валидации данных можно отнести:

1. Возможность импорта данных из систем документооборота Е1 Евфрат [4], DIRECTUM [5] и др.
2. Возможность импорта данных из офисных пакетов, таких как Microsoft Office [6], Open Office [7] и LibreOffice [8].
3. Возможность автоматической проверки введённых данных на предмет их корректности, например у научной статьи всегда должен быть хотя бы один автор.
4. Возможность автоматической валидации данных.
5. Автоматическое предотвращение дублирования данных.

К функциональным требованиям к ИСМ на этапе обработки и хранении данных можно отнести:

1. Накопление статистических данных по деятельности профессорско-преподавательского состава кафедры.
2. Накопление статистических данных по деятельности студентов кафедры.
3. Поддержка целостности данных.
4. Применения многомерной модели хранения данных.
5. Возможность статистической обработки данных.

К функциональным требованиям к ИСМ на этапе формирования отчётной документации можно отнести:

1. Возможность печати отчётов непосредственно из ИСМ.
2. Возможность формирование регламентированной отчётности.
3. Возможность формирование нерегламентированной отчётности, т.е. выдача справок различного вида.
4. Возможность создание итогового отчёта за выбранный период по конкретному направлению деятельности кафедры.

К функциональным требованиям к ИСМ на этапе мониторинга можно отнести:

1. Предоставление рекомендаций лицу, принимающему решение (ЛПР) в графической форме.
2. Автоматическая генерация рекомендаций по принятию управляющих решений ЛПР в текстовой форме.
3. Прогнозирование вариантов развития, на основе анализа имеющихся в системе данных.
4. Анализ деятельности кафедры согласно методике Минобрнауки, описанной в [9].
5. Возможность настройки весовых коэффициентов для модели оценки деятельности кафедры.
6. Возможность поиска скрытых закономерностей с использованием методов интеллектуального анализа данных.

К функциональным требованиям к ИСМ на этапе администрирования можно отнести:

1. Использование одной из моделей разграничения прав доступа пользователей  к ИСМ.
2. Экспорт данных во внешние программы обработки и анализа статистической информации (SPSS [10], Statistica [11] и пр.)
3. Шифрование данных.
4. Защита данных от несанкционированного доступа.
5. Защита персональных данных.
6. Создание и редактирование информации о пользователях ИСМ.
7. Возможности регулярного создания резервных копий данных.

К нефункциональным требованиям к ИСМ можно отнести:

1. Возможность удалённого доступа к системе через Internet.
2. Возможность удалённого доступа к системе через Intranet.
3. Использование единой технологической платформы.
4. Построение ИСМ на базе свободного программного обеспечения.
5. Построение ИСМ на принципах открытой системы.
6. Построение ИСМ на базе сервис-ориентированной архитектуры.
7. Возможность использование технологии хранилищ данных.
8. Возможность использования технологии OLAP.
9. Возможность использования интеллектуального анализа данных.
10. Возможность беспроводного мобильного доступа к ИСМ.
11. Возможность доступа к данным через веб-интерфейс.
12. Необходимость установки конечным пользователем ИСМ дополнительного программного обеспечения.

 Список литературы

1. Информационный  сайт фирмы IBM [Электронный ресурс]. – Режим доступа:http://www128.ibm.com/developerworks/rational/library/4706.html
2. Соммервилл, И. Инженерия программного обеспечения / И. Соммервилл – М.: Вильямс, 2002. – 624 c.
3. Полис, Г. Разработка программных проектов на основе Rational Unified Process (RUP) / Г. Полис – М.: Бином-Пресс, 2005. -  256 с.
4. Е1 Евфрат – документооборот и автоматизация бизнес-процессов [Электронный ресурс]. — Режим доступа:  http://www.evfrat.ru/
5. Электронный документооборот. Система электронного документооборота и управления взаимодействием DIRECTUM [Электронный ресурс]. — Режим доступа: http://www.directum.ru/
6. Microsoft Office – Office.com [Электронный ресурс]. — Режим доступа: http://office.microsoft.com/ru-ru/
7. OpenOffice.org – The Free and Open Productivity Suite [Электронный ресурс]. — Режим доступа: http://www.openoffice.org/
8. LibreOffice Productivity Suite [Электронный ресурс]. — Режим доступа: http://www.libreoffice.org/
9. Приказ РОСОБРНАДЗОРА от 30.09.2005 № 1938 об утверждении показателей деятельности и критериев государственной аккредитации высших учебных заведений.
10. SPSS, Data Mining, Statistical Analysis Software, Predictive Analysis, Predictive Analytics, Decision Support Systems [Электронный ресурс].— Режим доступа: http://spss.ru/
11. Официальный сайт компании StatSoft Russia [Электронный ресурс]. — Режим доступа: http://www.statsoft.ru/ 

Все статьи автора «altok»