Классификация требований
Формируемые требования к системе разделены на две категории:
– функциональные требования, которые отображают возможности проектируемой системы;
– нефункциональные требования, которые отображают ограничения, определяющие принципы функционирования системы и доступа к данным системы пользователей.
Первая из приведенных категорий дает ответ на вопрос "что делает система", а вторая определяет характеристики ее работы, например, что вероятность сбоев системы на некотором промежутке времени, доступ до ресурсов системы разных категорий пользователей и др.
Функциональные требования характеризуют функции системы или ее ПО, а также способы поведения ПО в процессе выполнения функций и методы передачи и преобразования входных данных в результаты. Нефункциональные требования определяют условия и среду выполнения функций (например, защита и доступ к БД, секретность и др.). Разработка требований и их локализация завершается на этапе проектирования архитектуры и отражается в специальном документе, по которому проводится окончательное согласование требований для достижения взаимопонимания между заказчиком и разработчиком.
Функциональные требования связаны с семантическими особенностями ПрО, для которой планируется разработка ПС. Важным фактором является проблема использования соответствующей терминологии при описание моделей ПрО и требований к системе. Одним из путей ее решения является стандартизации терминологии для нескольких ПрО (например, для информационных технологий, систем обеспечения качества и др.). Тенденция к созданию стандартизированного понятийного базиса для большинства ПрО отражает важность этой проблемы в плане обеспечения единого понимания терминов, используемых в документах, описывающих требования к системе и к ПО.
Нефункциональные требования могут иметь числовой вид ( например, время ожидания ответа, количество обслуживаемых клиентов, БД данных и др.), а также содержать числовые значения показателей надежности и качества работы компонентов системы, период смены версий системы и др.
Для большинства ПС, с которыми будут работать много пользователей, требования должны выражать такие ограничения на работу системы:
– конфиденциальность;
– отказоустойчивость;
– одновременность доступа к системе пользователей;
– безопасность;
– время ожидания ответа на обращение к системе;
– ограничения на исполнительские функции системы ( ресурсы памяти, скорость реакции на обращение к системе и т.п.);
– регламентации действующих стандартов, упрощающих процессов организации формирования требований и менеджмента.
Иными словами, для каждой системы формулируются нефункциональные требования, относящиеся к защите от несанкционированного доступа, к регистрации событий системы, аудиту, резервному копированию, восстановлению информации. Эти требования на этапе анализа и проектирования структуры системы должны быть определены и формализованы аналитиками. Для обеспечения безопасности системы должны быть определены категории пользователей системы, которые имеют доступ к тем или иным данным и компонентам.
Определяются объекты и субъекты защиты. На этапе анализа системы решается вопрос, какой уровень защиты данных необходимо предоставить для каждого из компонентов системы, выделить критичные данные, доступ к которым строго ограничен. Для этого применяется система мер по регистрации пользователей, т.е. идентификации и аутентификации, а также реализуется защита данных, ориентированная на регламентированный доступ к объектам данных (например, к таблицам, представлениям). Если же требуется сделать ограничение доступа к данным (например, к отдельным записям, полям в таблице), то в системе должны предусматриваться определенные средства (например, мандатная защита).
Для обеспечения восстановления и хранения резервных копий БД, архивов баз данных изучаются возможности, предоставляемые СУБД, и рассматриваются способы обеспечения требуемого уровня бесперебойной работы системы, а также организационные мероприятия, отображаемые в соответствующих документах по описанию требований к проектируемой системе.
В целях описания нефункциональных (защита, безопасность, аутентификация и др.) требований к системе и фиксации сведений о способности компонента обеспечивать несанкционированный доступ к нему неавторизованных пользователей, языки спецификаций компонентов дополнились средствами описания нефункциональных свойств. Эта группа свойств целиком связана с сервисом среды функционирования компонентов, ее способностью обеспечивать меры борьбы с разными угрозами, которые поступают извне от пользователей, не имеющих прав доступа к некоторым данным или ко всем данным системы.
Процесс формализованного описания функциональных и нефункциональных требований, а также требований к характеристикам качества с учетом стандарта качества ISO/IEC 9126–94 будет уточняться на этапах ЖЦ ПО и специфицироваться. В спецификации требований отражается структура ПО, требования к функциям, качеству и документации, а также задается архитектура системы и ПО, алгоритмы, логика управления и структура данных. Специфицируются также системные, нефункциональные требования и требования к взаимодействию с другими компонентами и платформами (БД, СУБД, сеть и др.).
