Функциональные и нефункциональные требования помогают программной системе работать эффективно. Каждое требование имеет уникальные функции, которые способствуют повышению удобства использования и безопасности, поскольку они позволяют программному обеспечению работать быстрее и использовать надежные протоколы безопасности.
В этой статье мы объясняем, что такое функциональные и нефункциональные требования, и перечисляем 12 общих требований к программным системам.
Что такое функциональное требование?
Функциональное требование — это техническая особенность программного обеспечения, которая помогает системам вести себя и работать. Инженеры обычно программируют эти функции непосредственно в программном обеспечении системы. Очень важно, чтобы программное обеспечение имело функциональные требования, чтобы помочь системе правильно выполнять задачи. В целом, функциональные требования дают представление о возможностях и функциях системы. Вот три этапа, через которые проходит функциональное требование при выполнении действия:
Лекция 8 Функциональные и нефункциональные требования
- Входные данные: когда инженеры-программисты создают функциональные требования, они создают входные данные, которые сигнализируют о том, что система должна вести себя или работать. Например, если веб-сайт позволяет пользователю щелкнуть ссылку, ведущую на другую веб-страницу, действие нажатия на ссылку является вводом.
- Поведение системы: это ответ на ввод, и он определяет, как функциональное требование. Например, поведение системы может включать в себя отключение программного обеспечения при обнаружении потенциальной угрозы безопасности.
- Вывод: вот как поведение влияет на программное обеспечение. Например, если поведение системы предполагает увеличение объема памяти, выходные данные включают в себя дополнительное пространство для файлов, чтобы пользователи могли сохранять свои данные.
Что такое нефункциональное требование?
Нефункциональное требование — это функция, которая помогает программному обеспечению работать эффективно. Эти требования не являются обязательными для системы, хотя они обычно повышают общее качество, скорость и емкость программного обеспечения. Нефункциональные требования позволяют пользователям использовать определенные функции программного обеспечения, повышающие удобство их использования. Например, если пользователь предпочитает, чтобы его программное обеспечение имело больший объем хранилища данных, он может выбрать программную систему, которая имеет нефункциональные требования, требующие большего объема памяти.
Программы для Windows, мобильные приложения, игры — ВСЁ БЕСПЛАТНО, в нашем закрытом телеграмм канале — Подписывайтесь:)
Общие функциональные и нефункциональные требования
Рассмотрим эти 12 функциональных и нефункциональных требований:
6 функциональных требований
Вот несколько общих функциональных требований, которые вы можете найти в программной системе:
Общие функциональные требования включают в себя требования, которые необходимы компании для работы. У каждой компании могут быть разные бизнес-требования, которые помогают им функционировать должным образом. Например, продуктовый магазин может включать функциональное требование, которое позволяет пользователям вводить свой номер телефона в систему вознаграждений, чтобы получать скидки на продукты.
Как отличать нефункциональные требования?
2. Административные протоколы
Административные протоколы позволяют программному обеспечению выполнять административные протоколы, которые являются рутинными операциями для системы. Эти протоколы могут включать системные отчеты и тестирование, чтобы обеспечить бесперебойную работу программного обеспечения. Например, программная система может выполнять ежемесячное сканирование, выявляющее области улучшения, которые система может включить в отчет. Вы можете просмотреть отчет, чтобы лучше понять функции и качество вашей системы.
3. Пользовательские настройки
Пользовательские предпочтения — это функциональное требование, которое помогает людям легко работать с программным обеспечением. Он может включать в себя определенные функции, повышающие удобство использования, например функции, помогающие переходить на определенные веб-страницы. В зависимости от программного обеспечения вы можете установить определенные предпочтения, основанные на ваших технологических потребностях.
4. Системные требования
Системные требования включают спецификации программного и аппаратного обеспечения. Это может включать в себя конкретные действия, которые система предпринимает для выполнения задачи. Например, если программное обеспечение архивирует данные в соответствии с датой сохранения данных пользователем, оно может просмотреть все данные, чтобы найти самые старые файлы, прежде чем перемещать данные в системные архивы. Это также включает в себя то, как система реагирует на особые обстоятельства. Например, если программное обеспечение обнаруживает брешь в системе безопасности, оно может временно отказать всем пользователям в доступе.
Аутентификация гарантирует, что пользователи подтверждают свою личность перед выполнением определенных программных функций. Это может включать в себя требование от пользователей ввести пароль, имя пользователя или информацию о компании. Вы можете использовать это требование в своем программном обеспечении для защиты информации. Компании часто используют требование, чтобы гарантировать, что соответствующие лица имеют доступ к конфиденциальным данным, например, определенные члены руководства. Бизнес может потребовать, чтобы все сотрудники использовали аутентификацию, или они могут потребовать, чтобы руководство вводило свою информацию только при доступе к ценной информации.
6. Юридические требования
Некоторые отрасли требуют от компаний соблюдения правил и требований к своим программным системам. Программное обеспечение компании может иметь функциональные требования, которые помогают системам соответствовать этим правилам и требованиям. Программное обеспечение может выполнять обычное сканирование, чтобы убедиться, что компания соблюдает надлежащие протоколы, или оно может регулярно обновлять системы, чтобы быть в курсе новых правил.
6 нефункциональных требований
Вот некоторые общие нефункциональные требования:
1. Удобство использования
Общее нефункциональное требование включает в себя определенные функции, которые помогают пользователям работать с программным обеспечением. Хотя удобство использования иногда является функциональным требованием, оно также может быть нефункциональным требованием, если пользователь добавляет дополнительные протоколы и функции для дальнейшего повышения удобства использования. Если программное обеспечение имеет высокий уровень удобства использования, это означает, что пользователи могут легко работать с интерфейсом программного обеспечения, понимая при этом различные функции и возможности системы.
Общее нефункциональное требование включает в себя функции, которые анализируют и повышают надежность системы. Для пользователей важно иметь надежное программное обеспечение, чтобы их информация была защищена от потенциальных угроз безопасности или потери данных. Чтобы определить надежность вашей системы, вы можете учитывать количество сбоев, которые произошли в вашей системе во время тестирования надежности. Сбой может включать неожиданное отключение системы, потерю информации, проблемы с подключением или некорректную загрузку данных.
Масштабируемость — это функция, которую компании могут добавить при получении больших объемов данных, которые необходимо сохранить в их системе. Масштабируемое программное обеспечение предполагает расширение пространства для хранения, чтобы можно было хранить больше информации. Компании могут использовать нефункциональное требование, которое дает им возможность расширить пространство хранения сверх исходных возможностей программного обеспечения.
Нефункциональные функции безопасности включают добавление протоколов для защиты ценных данных. Хотя в большинстве программ используются функции аутентификации пользователей, компания может добавить дополнительные меры безопасности, чтобы свести к минимуму риск потенциальной утечки данных. Например, колледж может добавить дополнительные протоколы безопасности, такие как брандмауэр, для студентов, получающих доступ к своей финансовой информации, чтобы обеспечить безопасность своих данных.
Программное обеспечение может включать нефункциональные требования, которые включают локализацию данных в программном обеспечении для региона пользователя. Программное обеспечение адаптируется к местоположению, чтобы пользователь мог лучше понять информацию, найденную в системе. Это может изменить язык системы, денежную валюту или часовой пояс. Например, если пользователь путешествует в другую страну, в его системе может быть установлена программная функция, которая автоматически меняет часовой пояс.
Пользователи могут устанавливать нефункциональные требования, повышающие общую производительность их системы. Как правило, уровень скорости, которым обладает система, важен для пользователей, поскольку им может понадобиться система, которая работает быстро. Нефункциональные требования могут повысить скорость и эффективность компьютера. Например, если сотрудник отправляет проект, высокая скорость может помочь отправить проект быстрее.
Примеры функциональных и нефункциональных требований
Вот несколько примеров функциональных и нефункциональных требований:
Функциональные требования
Функциональные требования должны быть внутри операционной системы, чтобы помочь ей работать эффективно. Вот несколько примеров функциональных требований в операционной системе:
- Операционная система требует, чтобы пользователи вводили пароль и имя пользователя при входе в систему, чтобы система могла аутентифицировать их личность.
- Система проводит регулярные проверки, чтобы убедиться, что их компания соответствует надлежащим правовым стандартам для своего конкретного программного обеспечения.
- Операционная система предоставляет пользователям квитанцию при выполнении транзакции, а система записывает информацию о транзакции в сохраненный файл.
Нефункциональные требования
Хотя операционные системы не нуждаются в нефункциональных требованиях, компании могут предпочесть, чтобы они помогали в проведении бизнес-операций. Вот несколько примеров нефункциональных требований в операционной системе:
- Операционная система переводит все иностранные сообщения на язык текущего местоположения системы.
- Операционная система автоматически отключается при обнаружении потенциальной угрозы безопасности.
- В систему добавлены функции, повышающие удобство использования, в том числе большой курсор, чтобы зрители могли легко идентифицировать его на экране, и текст с поддержкой речи, который позволяет пользователям печатать, используя свой голос.
Источник: buom.ru
Разделяй и требуй
Требования к автоматизированной информационной системе (АИС), которые позволяют достичь результата при решении какой-либо бизнес-задачи, на практике могут по-разному трактоваться и восприниматься представителями бизнеса и пользователями. О собственном понимании терминологии и наглядной разнице в смыслах рассказал читателям RSpectr функциональный архитектор PROF-IT GROUP Денис Окулов.
ПОЛЬЗОВАТЕЛИ И СТЕЙКХОЛДЕРЫ
Заинтересованных представителей бизнеса, который мы собираемся оцифровывать, автоматизировать, обычно называют стейкхолдерами. Это могут быть, например, шефы производства, финансов, коммерции, логистики и прочих подразделений. Бывает, что в круг стейкхолдеров вносят и акционеров, собственников бизнеса, и клиентов по причине их заинтересованности в конечной автоматизации.
Люди, которые будут использовать информсистему для своей работы или целей, – это пользователи. При этом пользователь может одновременно быть стейкхолдером, если он отвечает за выполнение бизнес-задачи. А если перед ним не стоит такая ответственность, то его основными целями являются удобство и простота цифровых продуктов.
Часто пользовательские требования трудно отделить от бизнес-требований именно потому, что стейкхолдеры являются одновременно и пользователями, и бизнес-ответственными за задачи
При этом важно понимать, что цели пользователей и стейкхолдеров чаще всего не совпадают.
Пользовательские требования – это то, как себе представляет в идеале работу в АИС пользователь. Обычно эти требования включают в себя не только ответы на вопросы, что и как должна позволять делать система, но и эргономику, и визуальное отображение пользовательского интерфейса.
С другой стороны, есть функциональные требования – это требования к выполнению определенных бизнес-функций в АИС, например, функции казначея или бухгалтера. Обычно описываются очень подробно и детально. Также для большей точности их еще называют функционально-техническими требованиями (ФТТ), но по сути они все равно остаются функциональными требованиями и к чисто техническим их отнести нельзя.
Нефункциональные требования (технические) – это требования к системе как к техническому продукту и его эксплуатации. Например, туда относят доступность системы для пользователя или время отклика на операцию. Чаще это цифры, нежели слова.
ИДЕАЛЬНАЯ МОДЕЛЬ АВТОМАТИЗАЦИИ
Теперь давайте перейдем к модели того, как все это должно работать:
1. Бизнес-вызовы ставят перед стейкхолдерами бизнес-задачи.
2. Бизнес-задачи закрываются реализацией бизнес-требований к новой системе.
3. Бизнес-требования закрываются выполнением функциональных и нефункциональных требований к АИС.
Если все учтено и описано правильно, то мы получаем на выходе положительный результат и выполнение цели автоматизации.
Кто-то из читателей воскликнет: «А где здесь пользовательские требования, забыли про них?!» Все верно, мы про них забыли. Правильно это или нет, тут нужно разобрать поподробнее.
Итак, с точки зрения «оголтелого» бизнеса удобство рядовых пользователей АИС, если это не клиенты, которые приносят жизненно важную выручку, отходит на второй план, потому как за реализацию этих требований платит в конечном счете собственник бизнеса. Более того, реализация такого рода требований зачастую не коррелируется с достижением бизнес-требований и бизнес-задач, а скорее имеет обратное влияние на эффективность.
дополнительное удобство и легкость выполнения работы наемными работниками, конечно, имеют важность, но ценности бизнесу не несут сами по себе, а только в связке с другими элементами цепочки добавления ценности для клиента
Именно поэтому внедренцы на практике стараются не выделять отдельный этап работы по спецификации и реализации пользовательских требований к системе. Однако пользовательские требования не стоит игнорировать как вид вообще, иначе они все равно растворятся в бизнес- или функциональных требованиях, а малоопытные аналитики не смогут их выявить и правильно организовать работу с ними. Далее это приводит к весьма негативным эффектам.
ОЖИДАНИЕ И РЕАЛЬНОСТЬ
На практике вышеописанная модель работает совсем не так, как в теории.
Бизнес-вызовы ставят перед стейкхолдерами бизнес-задачи – с этим все ок.
По мнению заказчика, бизнес-задачи закрываются реализацией бизнес-требований, пользовательских требований, функциональных и нефункциональных требований к системе.
По мнению подрядчика/исполнителя от IТ, бизнес-задачи закрываются реализацией иногда пользовательских требований, чаще функциональных и не всегда нефункциональных требований к системе.
На данном этапе возникает много разногласий и противоречий
Бизнес-требования закрываются выполнением функциональных и нефункциональных требований к АИС, но противоречия предыдущего этапа могут не позволить до этого этапа добраться.
Почему же возникает путаница на втором этапе «идеальной» модели работы с требованиями к информационным системам/бизнес-приложениям? Причин, как всегда, сразу несколько.
Во-первых, в стане заказчика будущего решения таким мелочам, как различия между видами требований к будущей информационной системе, не часто придают значение, считая, что это «птичий» айтишный язык.
Во-вторых, нужно понимать, что проектные команды от бизнеса имеют, как правило, «двухголовое» управление – IТ-заказчик и функциональный заказчик. Это накладывает некоторые условности, например, решения по нефункциональным требованиям тяготеют к юрисдикции IТ-заказчика, а по функциональным – функционального заказчика.
В-третьих, команда исполнителя работ по автоматизации также может поставить в один ряд разные виды требований, что сначала дает преимущества по экономии времени и ресурсов, но в конечном счете приводит к неразрешимым противоречиям и путанице.
В-четвертых, зачастую никто не держит в голове, что процесс управления требованиями при внедрении/разработке АИС – это такая постоянная деятельность, которую невозможно ограничить конкретным этапом проекта. У многих складывается впечатление, что достаточно один раз переписать все требования и на этом все закончится. Однако заказчики всегда будут приходить с новыми требованиями, пересмотром старых, и если у вас нет упорядоченности в этом процессе, то управлять изменениями становится трудоемко и конфликтно.
Если на практике возникают аналогичные проектные трудности, то это негативно влияет на цель проекта и снижает удовлетворенность заинтересованных сторон.
С чего можно начать в таких ситуациях? Для начала
необходимо четко развести требования по разным слоям проектных команд заказчика
Например, с бизнес-требованиями лучше всего позволят разобраться стейкхолдеры, потому что именно эти люди наиболее заинтересованы в их выполнении.
Функциональные требования лучше фиксировать с фокус-группой из ключевых пользователей будущей АИС, ведь именно они будут потом тестировать будущую систему.
Нефункциональные требования лучше проводить через IТ-заказчика.
Здесь важно не пытаться согласовывать или выспрашивать у функционального заказчика особенности технической стороны реализации тех или иных требований к будущей системе, хотя такие случаи не редкость. И это только один пример инструмента для успешного управления требованиями, а вообще управление требованиями – это целый арсенал, который объединяется в отдельную систему мер в проектной технологии.
Постоянно пересматривать подходы к управлению требованиями в силу причин и обстоятельств, описанных выше, нужно и важно.
Источник: rspectr.com
Архитектурные требования
Какие бывают требования к Архитектуре? Как мы говорили ранее требования можно делить на функциональные и нефункциональные требования. Функциональные требования собираются (предоставляются) бизнесом. Точнее будет сказать, что главная задача бизнес аналитика заключается в том, чтобы собрать функциональные требования.
К функциональным требованиям можно отнести все требования которое подпадают под “Сценарии выполнения системы” или “Поведенческие сценарии”. Например: — Пользователь заходит в систему, логинится и видит список товаров, которые он может добавить в корзину. Это очень похоже на поведенческий сценарий.
То есть сценарий показывает, как система должна работать или реагировать на какие-то действия.
Важно понимать что сценарии являются на мой взгляд самой важной частью сбора требований, без сценариев архитектуру и продукт построить нельзя. Но без архитектуры вполне себе можно построить продукт. Диаграмма продукта будет выглядеть как один большой квадрат в котором будут хранится каша из кода, но оно вполне может работать.
Далее следуют нефункциональные требования. Нефункциональные требования — это все требования, которые подпадают под одну из двух групп:
- то что можно измерить или посчитать
- то что является прямой пожеланием заказчика.
Для чего нужны нефункциональные требования?
Они определяют сложность и стоимость системы. Ниже приведены две картинки, которые демонстрируют разницу в нефункциональных требованиях
Оба телефона отлично работают с функциональными требованиями от бизнеса (звонить, слать смс, будильник). Но разница в цене и других характеристиках очень велика.
Разумеется что нефункциональные требования должны быть максимально детализированы. Ниже приведена картинка, которая показывает уровень детализации для различных видов требований.
Я не раз говорил, что нефункциональные требования самые тяжкие в получении. Дело в том, что бизнес, как правило, очень далек от технологий. И они не знают ответы на такие вопросы как. За какое время должна отрабатывать транзакция в базе ? Какой средний размер дампа базы данных у вас есть, если вы хотите делать миграцию в клауд?
Получение нефункциональных требований является одной из самых важных частей работы архитектора. Как же их получать ? — Да как хотите! Можете читать письма, изучать порталы и документы, которые вам заказчик передает. Можете просить доступы к энвайронменту технического отдела. Можете так же ходить на кофе или в стрип клуб с архитектором заказчика (и такой опыт бывает).
Хотя конечно существует и формальный подход к сбору требований. Но о нем мы будем говорить в следующих публикациях.
Очень важно отметить, что заказчик не всегда готов делиться такой информацией. Причин тому может быть много: NDA, боязнь утечек информации, или просто кому-то стыдно признаваться, что у них фиговенький продукт. Так же бывают ситуации, когда заказчик сознательно не обговаривает те или иные нефункциональные требования. Для того, чтобы сэкономить бюджет.
Хотя самая распространенная причина — заказчик просто не знает технических деталей. Спросите у любого вашего знакомого предпринимателя, который занимается не айти бизнесом — какой уровень покрытия нагрузочным или юнит тестированием он хочет чтобы был у него на сайте ? Я таки думаю, что он немного подвиснет, а потом скажет что-то невнятное или просто скажет: я человек от бизнеса поговори с ребятами которые мне делают сайт.
Примеры нефункциональных требований
- Performance – производительность (Система должна выдерживать 50000 запросов в секунду)
- Scalability — масштабируемость (система должна быть разбита на 5 сервисов)
- Data Integrity — целостность данных (В случае поломки, система не должна терять информацию)
- Testability — тестируемость (заказчик хочет получить 90% покрытия тестами кода)
Видов этих требований огромное множество — больше примеров можно найти на вики https://en.wikipedia.org/wiki/Non-functional_requirement
Как же узнать какие требования нам нужны для построения архитектуры? Какие полезные, а какие нет? Как приоритезировать и валидировать требования? об этом мы поговорим в следующей статье…
Источник: architectvelichko.com