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

Опубликованно 23.09.2018 10:57

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

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

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

Шаг 1. Понятие функциональных и не функциональных требований у нас формате. Теперь перейдем ко второму пункту - вы считаете, что, в частности, могут быть отнесены к последним.

Что относится к категории?

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

Однако большое значение имеют и такие нефункциональные требования: Ограничений. Т. е. условия, которые ограничивают выбор возможных решений, чтобы воплотить в жизнь отдельных требований (или набора требований). Что сужает разнообразие выбора инструментов, стратегий, инструментов во время развития, как структуры (архитектуры), и появление информационного или программного продукта. Бизнес-правила. Здесь существуют правила, руководства, политики, принципы, положения, как-то ограничивают некоторые аспекты бизнеса. Например, они могут определить состав и правила выполнения каких-либо бизнес-проекты. Что можно отнести к этой категории? Корпоративной политики, всех видов правительственных постановлений и указов, промышленные стандарты, алгоритмы расчета. Все правила, которые влияют на развитие системы, продукта, используются во время проекта. Предложения по реализации. Группа включает в себя конкретные предложения, которые рассматривают возможность применения специальных архитектурных и технологических решений. Внешние интерфейсы. Описание ключевых аспектов взаимодействия продукта с другими системами и окружающей среды операционной системы. Прежде всего, это требования к API системы или продукта, а также требования API других систем, с которыми планируется интеграция продукта в стадии разработки. Предложения, проверка, тестирование, разработка программного обеспечения. Это из серии дополнений к требованиям показать, как то или иное требование должно быть проверено на практике. Юридические требования. Лицензии для продукта, наличие патентов и так далее.

Важно отметить, что не-функциональные требования к системе предварительно определены и зафиксированы. Только после этого специалист может приступить к разработке продукта.

Примеры требования

Для того, чтобы иметь более четкое представление о нефункциональные требования к информационной системе, давайте посмотрим на некоторые примеры: Ограничений. "Это развитие только на платформе вендора-Х". "Когда проверка подлинности пользователя в информационной системе, должны быть использованы только биометрические методы идентификации". Бизнес-правила. "В момент отгрузки продукции менеджер обязан требовать бухгалтера предприятия счет-фактуру и транспорта, сырья, счета-фактуры". "Заказ будет считаться отменен, если оплата по счету не поступила к поставщику в течение 14 дней". Внешние интерфейсы. "Обеспечить запись в реестре развитие операционной системы для таких событий: сообщения о запуске и остановке сервиса Х". "Обеспечить запись в журнал, разработка программного обеспечения, параметров, данных его модули: ядро, антивирусный сканер. Информация должна быть внесена в реестр как при запуске приложения, и обновление модулей". Как определить требования?

Мы разобрали конкретные примеры нефункциональных требований. А теперь другой важный вопрос : "Как их идентификация по отношению к определенному продукту?"

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

Источники для построения таких моделей, разработчики, как правило, выбирают следующее: ГОСТ (государственный стандарт РФ) 34-й серии. Книга "Разработка требований к программному обеспечению" (автор - Потому что Пирс). В частности, необходимо обратить внимание на раздел "Приложение D". В нем содержатся конкретные примеры документации с требованиями.

Теперь рассмотрим, кто конкретно занимается этой работой.

Деятельности, определение требований к продукции

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

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

Роль членов рабочей группы

Теперь рассмотрим роли распределяются между членами группы экспертов, которые определяют и утверждают, не-функциональные требования к продукту: Пользователей. Эти участники дают оценки значений тех параметров, которые определяют нефункциональные требования. Системный аналитик. Участник собирает, анализирует, организует и документирует требования, не функциональные. Основными разработчиками и системным архитектором. Какую роль играет эта группа? Участвуют в определение, анализ нефункциональных требований, и контролировать степень их достижения. Группа тестирования. Также участвует в определении, анализе список нефункциональных требований к программе. Кроме того, разработка сценариев тестирования для данных предписаний. Скрипт для определения требований к

Вот давайте конкретный пример сценария, используемого для определения нефункциональных требований к производительности модуля, предназначенный для отправки уведомлений пользователям интернет-ресурса-e-mail: Система получает сигнал о событии, начать рассылку. Система осуществляет отправлять сообщения пользователям из списка И, используя модель Б. Для отправки сообщения используется служба В. В случае невозможности завершения операции, система выполняет повторную попытку доставки сообщения.

Формирование требований к продукту для сценария

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

Важные критерии, требования

Сами нефункциональные требования должны соответствовать ряду критериев качества к их содержанию: Полнота (в качестве отдельного требования, а полный их список). Что это значит? Требование должно содержать все сведения, необходимые для его реализации. Уникальность. Требование не должно быть ни себя, ни других элементов из списка. Все работающие с ним специалисты должны понимать одинаково. Правильность определенной потребности, обеспечивает согласованность системы. Необходимость. Реализация такого запроса, на самом деле нужно пользователям. Технико-экономическое. Реализовать это требование в реальной жизни. Проверить. Должен обеспечить четкий контроль за ее выполнением.

Мы с вами знакомы с таким понятием, как нефункциональные требования к программному продукту, информационная система. Также разобрали их на конкретных примерах, в отличие от функциональных категорий, критерии качества категория. Вы знаете, что группа специалистов, в, что так они создают и поддерживают настоящих правил. Автор: Юлия Лебези Я Этого 9 Августа, 2018

Категория: Новости