Методы и средства инженерии программного обеспечения

       

Классификация требований


Формируемые требования к системе разделены на две   категории:

  –  функциональные требования, которые отображают возможности проектируемой системы;

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

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

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

 

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

 

Нефункциональные требования могут иметь  числовой вид  ( например, время ожидания ответа, количество обслуживаемых клиентов,  БД данных и др.), а также содержать числовые значения показателей надежности и качества  работы компонентов системы, период смены версий системы и др.
Для большинства ПС, с которыми будут работать много пользователей, требования должны выражать такие ограничения на работу системы:

– конфиденциальность;

– отказоустойчивость;

– одновременность  доступа к системе пользователей;

– безопасность;

– время ожидания ответа на обращение к системе;

– ограничения на исполнительские функции  системы ( ресурсы памяти, скорость реакции на обращение к системе и т.п.);

– регламентации действующих стандартов, упрощающих  процессов организации формирования требований и  менеджмента.

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

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

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





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

Процесс формализованного описания функциональных и нефункциональных требований, а также требований к характеристикам  качества   с учетом  стандарта  качества  ISO/IEC 9126–94 будет уточняться   на этапах ЖЦ ПО и специфицироваться. В спецификации требований отражается структура ПО, требования к функциям,   качеству и  документации, а также задается архитектура системы и ПО, алгоритмы, логика управления и структура данных. Специфицируются также системные,  нефункциональные требования и требования к взаимодействию с другими   компонентами и платформами (БД, СУБД,  сеть и др.).  


Содержание раздела