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

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

В этой статье мы объясним, что такое функциональные и нефункциональные требования, и перечислим 12 общих требований к программным системам.

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

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

Нефункциональные требования. Как не упустить качество продукта

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

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

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

Общие функциональные и нефункциональные требования

Рассмотрите эти 12 функциональных и нефункциональных требований:

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

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

1. Бизнес-требования

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

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

2. Административные протоколы

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

3. Предпочтения пользователей

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

4. Системные требования

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

5. Аутентификация

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

6. Юридические требования

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

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

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

1. Удобство использования

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

2. Надежность

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

3. Масштабируемость

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

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

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

5. Локализация

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

6. Производительность

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

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

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

Функциональные требования

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

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

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

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

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

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

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

Привет, Хабр! Меня зовут Елена, я ведущий аналитик ИТ-компании SimbirSoft. Сегодня хочу затронуть такую тему, как нефункциональные требования к ИТ-продукту, которым не всегда уделяется должное внимание, а зря. Их несоблюдение может привести к потере прибыли, клиентов, репутации, остановке производственных процессов и большим штрафам, хотя с первого взгляда их влияние на осуществление пользовательского функционала неочевидно.

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

• мощности и производительности;
• безопасности, соответствию стандартам и законодательству;
• переносимости и совместимости.

При проектировании системы чаще всего говорят о её функциональности: что она должна делать для того, чтобы соответствовать целям бизнеса, как решать те или иные проблемы пользователей, какие ценности им поставляет, как оптимизирует процессы в компании и т.п. Ключевая формулировка – «ИТ-продукт должен делать то-то и то-то». Но это даже не вершина айсберга, это Титаник. Айсбергом в этом случае станет среда, в которой ИТ-система будет существовать после релиза.

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

Так и с ИТ-системой: она может быть изящной, эффективной, функциональной, даже гениальной и уникальной, но вдребезги разбиться о реалии своего существования. Нужно ли говорить о том, какие за этим стоят риски для бизнеса?

Что такое нефункциональные требования и какими они бывают

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

Нефункциональные требования (НФТ) описывают, как должен работать программный продукт и какими свойствами или характеристиками обладать, чтобы доставить ту ценность, которую несёт система, с учетом условий ее существования. Такие требования вносят вклад в инфраструктуру, а не в поведение системы.

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

Нефункциональных требований достаточно много. Подробно они описываются в BABOK (руководство к Своду знаний по бизнес-анализу), в ISO / IEC 25000. В рамках данной статьи мы рассмотрим три:

1. Требования, описывающие производительность и мощность. Должны содержать информацию о планируемых нагрузках, которые ваша система должна выдерживать в пиковые моменты ее работы.
2. Требования к безопасности и соответствию законодательству и стандартам. Гарантируют, что все данные внутри системы или ее компонентов будут защищены от вредоносных атак или несанкционированного доступа.
3. Требования к переносимости и совместимости системы. Они описывают среду, в которой будет использоваться система – устройства, операционные системы, браузеры, другие системы, с которыми приложение должно работать.

О том, как мы работаем с требованиями, – в нашем видео. А теперь расскажем подробнее о каждой группе и дадим рекомендации о том, на что стоит обратить внимание.

Производительность и мощность

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

Другой пример. Во время пандемии ПЦР-тесты были обязательными для въезда в страну, посещения мероприятий, офиса и т.д. На тот момент серьезно возросла нагрузка на ИТ-системы не только лабораторий и медицинских организаций, но и учреждений, куда эти документы необходимо было подгружать. В тот же период многократно увеличилось количество заказов в интернет-магазинах, сервисах доставки готовых блюд и продуктов из супермаркета.

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

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

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

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

«Приложение должно максимально быстро реагировать на действия пользователя»

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

«Пользователь, находясь в сети 3G, должен получать расчёт стоимости услуги не более чем за 2 секунды»

Чек-лист «Как определить требования к производительности и мощности»

1. Сколько запросов в секунду предполагается для системы:

1. В обычном режиме;
2. В периоды пиковой нагрузки.

1. В обычном режиме;
2. В периоды пиковой нагрузки.

1. Первичная загрузка;
2. Повторная загрузка.

1. Активных:

1. На старте;
2. Через год;
3. Через 2 года.

1. На старте;
2. Через год;
3. Через 2 года.

1. В обычном режиме;
2. В периоды пиковой нагрузки.

1. Сколько данных можно хранить и что с ними нужно делать:

1. Ожидаемое число объектов различного типа в день / неделю / месяц / год, а также в пиковые периоды (например, позиций в каталоге, количество сформированных заказов);
2. Каковы прогнозируемые темпы роста;
3. Типы хранимых файлов и их объем (документы, изображения, аудио, видео):

1. Максимальный размер файла;
2. Есть ли ограничения по количеству загружаемых к объекту/сущности файлов?
3. Как долго эти данные надо хранить в системе (например, можно удалить их через N лет)?

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

Безопасность, соответствие стандартам и законодательству

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

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

Самые чувствительные в этом отношении проекты связаны с хранением и безопасностью персональных данных. Например, FinTech и банковские приложения должны соответствовать как международным стандартам, так и стандартам безопасности отдельных стран. Например, в России – есть требования Федеральной службы по техническому и экспортному контролю, 152-ФЗ «О персональных данных», а за рубежом – требования GDPR.

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

Под безопасностью также подразумеваются:

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

Рекомендуем ознакомиться с топ-10 OWASP. Этот стандарт отражает наиболее критичные угрозы для веб-приложений. В этой статье мои коллеги как раз рассказывали о веб-уязвимостях.

Плохой пример:

Приложение должно соответствовать стандартам безопасности

Хороший пример

Клиент должен взаимодействовать с сервером посредством протокола SSL.

Чек-лист «Как определить требования к безопасности системы»

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

1. Какие роли пользователей предусмотрены в системе и какими правами они должны быть наделены.
2. Какая схема авторизации и аутентификации предусматривается:

1. Требуется ли SSO, нужна ли интеграция с LDAP, Active Directory;
2. Нужна ли двухфакторная аутентификация;
3. Какие требования к парольной политике;
4. Какие требования к продолжительности сессии. Например:
   — должен ли пользователь быть разлогинен через какое-то время без активности;
   — удаляется ли текущая сессия при завершении сеанса;

1. Нужно ли шифровать межсервисный трафик (HTTP, HTTPS).
2. Предусматривается ли работа с персональными данными:

1. Обработка;
2. Хранение (если да, то на какой срок);
3. Передача третьим сторонам;
4. Где должны располагаться сервера, хранящие данные.

1. Наличие резервной копии;
2. Наличие и правила создания точек сохранения БД.

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

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

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

Совместимость – это дополнительный аспект переносимости. Она описывает, как система может существовать и взаимодействовать с другими системами и процессами в той же среде.

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

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

На данный момент общепринятый стандарт для веб-приложений — кроссплатформенное, кроссбраузерное и мобильное решение.

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

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

Плохой пример

Приложение должно полноценно работать на iPhone и Android

Хороший пример

Приложение должно поддерживать устройства, работающие на операционных системах:

1. iOS 9.0- 16.0

2. Android 7.0 – 12.0 (учитывая специфические особенности марок Xiaomi, Sony, Huawei)

Чек-лист «Как определить требования к совместимости и переносимости»

1. На каких типах устройств планируется использовать приложение.
2. На каких операционных системах должно работать приложение.
3. В каких браузерах и их версиях должно работать приложение.
4. Каковы минимальные требования к устройствам и другому оборудованию, необходимые для нормальной работы приложения.
5. Требования к подключению. Использование каких сетей предполагается для работы приложения и какова их пропускная способность:

1. Локальная;
2. Широкополосный интернет;
3. Мобильный интернет;
4. Спутниковая связь;
5. Оффлайн.

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

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

Продолжая обучение начинающих системных и бизнес-аналитиков основам разработки ТЗ, сегодня рассмотрим, что такое нефункциональные требования к ПО и как их составить. Также разберем, чем доступность отличается от надежности, как измерить качество пользовательского интерфейса и других характеристик проектируемой системы с комментариями BABOK®Guide, а также рекомендациями российских ГОСТ’ов и зарубежных стандартов.

Что такое нефункциональные требования и какие они бывают: взгляд BABOK®Guide

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

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

• доступность– степень работоспособности и доступности решения для использования, часто выражается в процентах времени;
• совместимость – степень успешности взаимодействия решения с другими окружающими компонентами (бизнес-процессами, информационными системами, аппаратным обеспечением и пр.);
• функциональность– степень соответствия функций решения потребностям пользователей, включая пригодность, точность, совместимость, т.е. корреляция с требованиями стейкхолдеров;
• ремонтопригодность – легкость изменения решения или его компонента, чтобы улучшить их, исправить ошибки или адаптировать к изменениям окружающей среды;
• эффективность работы – способность решения или его компонента выполнять свои целевые функции с минимальным потреблением ресурсов в контексте или временном периоде, например, в условиях пиковой нагрузки;
• надежность– способность решения или его компонента выполнять требуемые функции в определенных условиях в течение конкретного периода времени, например, наработка на отказ, измеряемая в часах и равная среднему времени работы устройства до сбоя;
• масштабируемость– способность решения расти или развиваться по мере роста объемов данных и количества пользователей;
• расширяемость– возможность добавления в решение новых функциональных возможностей. Это свойство тесно связано с архитектурой ПО, например, микросервисная архитектура проще поддается модификациям, чем «монолитная».
• переносимость– легкость переноса решения или его компонента из одной среды в другую, например, миграция на новую версию операционной системы или аппаратной платформы;
• безопасность– защита данных и компонентов решения от случайного или злонамеренного доступа, неправомерного использования, разрушения или раскрытия. Подробнее про процедуры аутентификации и авторизации в веб-приложениях читайте в моей новой статье.
• удобство использования– легкость взаимодействия пользователя с решением, включая простоту ежедневной работы и обучения;
• сертификация– соответствие отдельным стандартам или отраслевым соглашениям;
• соответствие– нормативные, финансовые или правовые ограничения в зависимости от контекста и юрисдикции;
• локализация – адаптация текстовых и графических компонентов интерфейса, а также представления данных к языкам, законам, валютам и особенностям культуры пользователей в определенной местности или отрасли;
• соглашения об уровне обслуживания между поставщиком и пользователем решения. На практике это свойство тесно связано с доступностью, о чем мы поговорим далее.

Лучшее из BABOK®Guide: ТОП-10 задач и 20+ техник для аналитика

Код курса

EXBAB

Ближайшая дата курса

3 июля, 2023

Длительность обучения

24 ак.часов

Стоимость обучения

45 000 руб.

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

Российские ГОСТ’ы по разработке технического задания (ТЗ), 34.602-89 и 19.201-78, которые мы разбирали здесь, также предлагают свой список нефункциональных требований, который частично пересекается с перечнем BABOK. Зарубежные стандарты по спецификации требований к ПО (SRS, Software Requirements Specification), ISO IEEE 29148-2018 и IEEE 830-1998, тоже приводят рекомендации по атрибутам качества ПО, которые можно использовать в качестве нефункциональных требований.

Еще атрибуты качества ПО подробно разбираются в стандарте ISO/IEC 25010:2011 (ГОСТ Р ИСО/МЭК 25010-2015) «Требования и оценка качества систем и программного обеспечения. Модели качества систем и программных продуктов». Наконец, некоторые метрики оценки качества, которые относятся к ИТ-сервису, упомянуты в библиотеке ITIL. Разумеется, в каждом конкретном случае не все категории нефункциональных требований будут упомянуты в отдельно взятом ТЗ или SRS. Однако, поскольку нефункциональные требования являются именно требованиями, а не пожеланиями, они должны быть точно сформулированы и иметь четкие критерии проверки их достижимости, т.е. значения упомянутых характеристик.

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

Наиболее часто используемым показателем для измерения доступности является значение SLA (Service Level Agreement, соглашение об уровне предоставления услуг между поставщиком и потребителем). Этот показатель обычно измеряется в процентах и говорит о времени безотказной работы и простоя системы.

Например, при SLA 99,99% максимальный период возможной недоступности системы в день соответствует 9 секундам, а время безотказной работы составляет 23 часа 59 минут и 51 секунду. Если брать годовой период измерения (365 дней или 8760 часов), то при этом уровне SLA система может быть недоступной 52 минуты и 36 секунд.

Чем выше уровень SLA, тем дороже будет TCO (Total Cost Ownership, общая стоимость владения) системы. Для некоторых решений, связанных с жизненно важными сервисами, требуется действительно высокая доступность со SLA близким к 100%, например, уровень «5 девяток» – 99,999%. А для приложений внутреннего документооборота или других учетных систем в рамках одного предприятия такой SLA будет избыточным. Для расчета времени безотказной работы существует множество открытых сервисов, например, http://shootnick.ru/uptime/99.

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

Чтобы снизить степень неопределенности и облегчить процесс верификации требований, аналитик должен определить критерии их приемки. Например, требование к удобству пользовательского интерфейса может быть сформулировано как необходимость соответствия предписаниям ГОСТ Р 52872-2019 «Интернет-ресурсы и другая информация, представленная в электронно-цифровой форме. Приложения для стационарных и мобильных устройств, иные пользовательские интерфейсы. Требования доступности для людей с инвалидностью и других лиц с ограничениями жизнедеятельности». Для веб-приложений актуальны время первого отклика страницы и адаптация к мобильным устройствам, что можно выразить в численных значениях с помощью сервиса https://developers.google.com/speed/pagespeed/insights.

Разработка ТЗ на информационную систему по ГОСТ и SRS

Код курса

TTIS

Ближайшая дата курса

24 июля, 2023

Длительность обучения

12 ак.часов

Стоимость обучения

20 000 руб.

Удобство использования в контексте обучения можно выразить долей пользователей, которые освоят часть функциональных возможностей системы за конкретный период времени. Например, 95% пользователей должны быть способны использовать 80% функций системы не более чем через 8 часов обучения. Эффективность работы может выражаться в быстродействии или объеме обрабатываемых данных, например, система должна выполнять 90% запросов не более чем за 1 секунду в условиях средней загрузки (10 тысяч пользователей и объем трафика 1 Гб/сек).

Таким образом, разработка нефункциональных требований предполагает не только выявление характеристик проектируемой системы, но и определение критериев их измеримости и желаемых значений. Это коррелирует с концепцией определений (Definition of Done), которые бизнес-аналитик разрабатывает с учетом условий функционирования будущего решения, особенностей его поведения (т.е. функциональных требований), архитектурных ограничений, ограничений среды, а также рекомендаций экспертов предметной области и конечных пользователей продукта.

Источник: babok-school.ru