Бизнес правила нефункциональные требования

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

Что такое нефункциональное требование?

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

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

9 лучших примеров нефункциональных требований

Вот девять примеров нефункциональных требований и их значение для приложений:

Скорость

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

Безопасность

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

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

Переносимость

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

Совместимость

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

Емкость

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

Надежность

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

Процент вероятности неудачи: Вы можете проверить процент вероятности отказа, или интенсивность отказов, чтобы определить надежность системы. Если процент выше, то система, скорее всего, будет нормально функционировать после значительного использования.
Количество критических отказов: Рассмотрите возможность регистрации количества критических отказов, которые система испытывает во время тестирования, чтобы проверить ее надежность. Если количество сбоев невелико, это означает, что система работает правильно.
Время между критическими отказами: Отслеживание времени между критическими отказами может помочь вам понять надежность системы. Если критические сбои происходят редко, это означает, что система функционирует нормально большую часть времени.

Окружающая среда

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

Локализация

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

Языки
Валюты
Измерения, например, фунты против. килограммы
Временные зоны

Юзабилити

Под удобством использования понимается возможность использования конкретного продукта, включая такие элементы, как:

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

Способы оценки нефункциональных требований

Вы можете оценить качество ваших нефункциональных требований следующими способами:

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

Лучшие практики для нефункциональных требований

Вы можете следовать этим практикам, чтобы максимально повысить эффективность нефункциональных требований:

Установить четкие ожидания

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

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

Применяйте последовательное форматирование

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

Количественно оцените свои ожидания

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

Отдавайте предпочтение опыту пользователя

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

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

Используйте существующие продукты в качестве руководства

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

Обратите внимание, что ни одна из компаний, упомянутых в этой статье, не связана с Indeed.

Ключевые слова:

indeed.com

Источник: hr-portal.ru

Группа функциональных требований

Группа нефункциональных требований (Non-Functional Requirements)

Бизнес-правила (Business Rules) – включают или связаны с корпоративными регламентами, политиками, стандартами, законодательными актами, внутрикорпоративными инициативами (например, стремление достичь зрелости процессов по CMMI 4-го уровня), учетными практиками, алгоритмами вычислений и т.д. На самом деле, достаточно часто можно видеть недостаточное внимание такого рода требованиям со стороны сотрудников ИТ-департаментов и, в частности, технических специалистов, вовлеченных в проект. Business Rules Group дает понимание бизнес-правила, как “положения, которые определяют или ограничивают некоторые аспекты бизнеса. Они подразумевают организацию структуры бизнеса, контролируют или влияют на поведение бизнеса”. Бизнес-правила часто определяют распределение ответственности в системе, отвечая на вопрос “кто будет осуществлять конкретный вариант, сценарий использования” или диктуют появление некоторых функциональных требований. В контексте дисциплины управления проектами, такие правила обладают высокой значимостью и, именно они, часто определяют ограничения бизнес-проектов, для автоматизации которых создается соответствующее программное обеспечение.
Внешние интерфейсы (External Interfaces) – часто подменяются “пользовательским интерфейсом”. На самом деле вопросы организации пользовательского интерфейса безусловно важны в данной категории требований, однако, конкретизация аспектов взаимодействия с другими системами, операционной средой (например, запись в журнал событий операционной системы), возможностями мониторинга при эксплуатации – все это не столько функциональные требования (к которым ошибочно приписывают иногда такие характеристики), сколько вопросы интерфейсов, так как функциональные требования связаны непосредственно с функциональностью системы, направленной на решение бизнес-потребностей.
Атрибуты качества (Quality Attributes) – описывают дополнительные характеристики продукта в различных “измерениях”, важных для пользователей и/или разработчиков. Атрибуты касаются вопросов портируемости, интероперабельности (прозрачности взаимодействия с другими системами), целостности, устойчивости и т.п.
Ограничения (Constraints) – формулировки условий, модифицирующих требования или наборы требований, сужая выбор возможных решений по их реализации. В частности, к ним могут относиться параметры производительности, влияющие на выбор платформы реализации и/или развертывания (протоколы, серверы приложений, баз данных, . ), которые, в свою очередь, могут относиться, например, к внешним интерфейсам.
Системные требования (System Requirements) – иногда классифицируются как составная часть группы функциональных требований (не путайте с как таковыми “функциональными требованиями”). Описывают высокоуровневые требования к программному обеспечению, содержащему несколько или много взаимосвязанных подсистем и приложений. При этом, система может быть как целиком программной, так и состоять из программной и аппаратной частей. В общем случае, частью системы может быть персонал, выполняющий определенные функции системы, например, авторизация выполнения определенных операций с использованием программно-аппаратных подсистем.

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

Например, методология RUP выделяет отдельный артефакт Business Rule в рамках дисциплины Business Modeling. Все бизнес-правила, в рамках данной дисциплины, идентифицируются и описываются в документе Business Rules Document. При разработке требований, в сценариях Use Cases обычно включается ссылка на уже описанное бизнес-правило. Скотт Амблер так же выделяет бизнес-правило как один из артефактов, который используют в семействе Agile методологий.

В настоящее время разработаны методы и подходы формального представления бизнес-правил, вплоть до формальных языков описания (использование OCL – Object Constraint Language, BRML – Business Rules Markup Language).

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

Рассматривая бизнес-правила, как артефакты относящиеся к области программных требований можно отметить, вернее дать одно из пояснений, почему БП относят к нефункциональным требованиям: Например, при написании определенного шага в сценарии use case, используется ссылка на бизнес правило: «… система производит расчет стоимости в соответствии с бизнес-правилом BP41 …». В свою очередь данное бизнес-правило может определять алгоритм расчета стоимости. Т.е. налицо «с соблюдением каких условий система делает расчет».

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

Даже в рамках этой классификации, существуют и различные взгляды на ее интерпретацию и детализацию. Например, как результат определения целевой аудитории и в рамках маркетинговой стратегии продвижения тиражируемого решения, возможно определять высокоуровневые возможности (ключевые характеристики, особенности) – “фичи” (features) разрабатываемого продукта. Иногда, такие возможности детализируются в смысле функциональных требований в некоторых agile-техниках, например, FDD – Feature-Driven Development (как вы видите вплоть до самого названия целого комплекса практик, метода разработки).

Вигерс, описывает feature как “множество логически связанных функциональных требований, которые предоставляют определенные возможности для пользователя и удовлетворяют бизнес-целям ”. С точки зрения маркетинга программного обеспечения, как отмечает Вигерс, feature это «группа требований, узнаваемая заинтересованными лицами, которые вовлечены в процесс принятия решения по приобретению ПО – это список , присутствующий в описании продукта». В то же время, Леффингвелл и Видриг (D.Leffingwell, D. Widrig, Managing Software Requirements: A Use Case Approach, Second Edition, 2003) определяют feature как “сервисы, которые оказывает система для удовлетворения одной или более потребностей заинтересованных лиц (stakeholders needs)”. Ими же отмечается, что в реальных проектах могут быть не определены stakeholders needs (а их часто выделяют, особенно если у проекта/продукта есть много заинтересованных лиц со своими потребностями, и эти потребности могут носить взаимоисключающий характер), но существовать features могут и самостоятельно (как и stakeholder needs), и конечно же возможно существование и stakeholder needs и features со взаимной трассировкой.

Развивая тему features — Kurt Bittner https://studfile.net/preview/9720251/page:2/» target=»_blank»]studfile.net[/mask_link]

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

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

Две категории требований

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

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

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

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

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

Однако большое значение имеют и такие нефункциональные требования:

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

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

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

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

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

Как определять данные требования?

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

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

Источниками для составления подобных шаблонов разработчики обычно выбирают следующее:

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

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

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

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

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

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

Роли участников рабочей группы

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

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

Сценарий для определения требований

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

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

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

А теперь составим требования к сформированному в предыдущем подзаголовке сценарию:

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

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

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

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

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

Источник: fb.ru