Содержание:

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

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

Приведите примеры для каждого случая.

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

Позвольте мне уточнить.

Примером функционального требования будет:

  • Система должна отправлять электронную почту всякий раз, когда выполняется определенное условие (например, заказ размещен, клиент подписывается и т.д.).

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

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

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

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

  • Доступность
  • Емкость, текущий и прогноз
  • Соответствие
  • Документация
  • Аварийное восстановление
  • Эффективность
  • Эффективность
  • расширяемость
  • Отказоустойчивость
  • Interoperability
  • ремонтопригодность
  • Конфиденциальность
  • Портативность
  • Качество
  • Надежность
  • Упругость
  • Время отклика
  • Надёжность
  • Масштабируемость
  • Безопасность
  • Устойчивость
  • Supportability
  • Тестируемость

Более полный список доступен в Википедии для нефункциональных требований.

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

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

Нефункциональное приобретение не является прямым требованием к системе, а связано с удобством использования (например, для банковского приложения), поскольку основным нефункциональным требованием будет наличие приложения, которое должно быть доступно 24/7 с нет простоя, если это возможно.

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

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

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

Функциональные требования — это то, что система должна выполнять. Это может быть

  • Расчеты
  • Технические характеристики
  • Обработка данных
  • Обработка данных
  • Другие специальные функции

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

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

Л.Бушкин уже объяснил больше о нефункциональных требованиях. Я добавлю больше.

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

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

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

  • качества выполнения, такие как безопасность и удобство использования, которые можно наблюдать во время выполнения.
  • Эволюционные качества, такие как тестируемость, ремонтопригодность, расширяемость и масштабируемость, которые воплощены в статической структуре программной системы.
  • Нефункциональные требования устанавливают ограничения на разрабатываемый продукт, процесс разработки, и указать внешние ограничения, которые продукт должен встретиться.
  • IEEE-Std 830 — 1993 содержит 13 нефункциональных требований, которые должны быть включены в Документ требований к программному обеспечению.
    • Требования к производительности
    • Требования к интерфейсу
    • Эксплуатационные требования
    • Потребности в ресурсах
    • Требования для проверки
    • Принятые требования
    • Требования к документации
    • Требования безопасности
    • Требования к переносимости
    • Требования к качеству
    • Требования надежности
    • Требования по пригодности
    • Требования безопасности

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

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

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

    Какие бывают требования?

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

    Бизнес-требования (business requirements) содержат высокоуровневые цели организации или заказчиков системы. Как правило, их высказывают те, кто финансируют проект, покупатели системы, менеджер реальных пользователей, отдел маркетинга. В этом документе объясняется, почему организации нужна такая система, то есть описаны цели, которые организация намерена достичь с ее помощью. Мне нравится записывать бизнес-требования в форме документа об образе и границах проекта, который еще иногда называют уставом проекта (project charter) или документом рыночных требований (market requirements document). Определение границ проекта представляет собой первый этап управление общими проблемами увеличения объема работ.

    Требования пользователей (user requirements) описывают цели и задачи, которые пользователям даст система. К отличным способам представления этого вида требований относятся варианты использования, сценарии и таблицы «событие — отклик». Таким образом, в этом документе указано, что клиенты смогут делать с помощью системы.

    Функциональные требования (functional requirements) определяют функциональность ПО, которую разработчики должны построить, чтобы пользователи смогли выполнить свои задачи в рамках бизнес-требований. Иногда они называются требованиями поведения (behavioral requirements), они содержат положения с традиционным «должен» или «должна»: «Система должна по электронной почте отправлять пользователю подтверждение о заказе».
    Функциональные требования документируются в спецификации требований к ПО (software requirements specification, SRS), где описывается так полно, как необходимо, ожидаемое поведение системы.

    Системные требования (system requirements) — это высокоуровневые требования к продукту, которые содержат многие подсистемы. Говоря о системе, мы подразумеваем программное обеспечение или подсистемы ПО и оборудования. Люди — часть системы, поэтому определенные функции системы могут распространяться и на людей.

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

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

    Смотрите так же:  Виндоус 8 требования

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

    Все для аналитиков

    среда, 17 августа 2011 г.

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

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

    Кратко: требование это зафиксированное желание пользователя, которое должна выполнять система.

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

    • Бизнес-требования. Что система система должна делать с точки зрения бизнеса. Слово «бизнес» в данном контексте ближе к слову «заказчик». Пример бизнес-требования: промо-сайт, привлекающий внимание определенной аудитории к определенной продукции компании.
    • Пользовательские требования – описывают цели/задачи пользователей системы, которые должны достигаться/выполняться пользователями при помощи создаваемой программной системы. Эти требования часто представляют в виде вариантов использования (Use Cases). Иначе говоря, пользовательские требования — это что может сделать пользователь: зарегистрироваться, посмотреть определенную информацию, пересчитать данные по определенному алгоритму и прочее.
    • Функциональные требования – определяют функциональность (поведение) программной системы, которая должна быть создана разработчиками для предоставления возможности выполнения пользователями своих обязанностей в рамках бизнес-требований и в контексте пользовательских требований. Другими словами, что будут делать разработчики, чтобы выполнить пользовательские требования.
    • Бизнес-правила. Они определяют почему система работать должна именно так, как написано. Это могут быть ссылки на законодательство, внутренние правила заказчика и прочие причины. Часто упускают этот раздел и получается, что некоторые системные решения выглядят нетипичным и совсем неочевидными. Например, многие табачные компании и компании, производящие алкоголь требуют постоянного доказательства того, что промо-сайтами пользуются люди, достигшие определенного возраста. Это бизнес-правило (подтверждение возраста) возникает по требованию этических комитетов заказчика, хотя и несколько противоречит маркетинговым целям и требованиям по usability.
    • Внешние интерфейсы. Это не только интерфейсы пользователя, но и протоколы взаимодействия с другими системами. Например, часто сайты связаны с CRM системами. Особенности протокола взаимодействия «сайт-CRM» также относятся к нефункциональным требованиям.
    • Атрибуты качества. Атрибуты касаются вопросов прозрачности взаимодействия с другими системами, целостности, устойчивости и т.п. К таким характеристикам относятся:
      • легкость и простота использования (usability)
      • производительность (performance)
      • удобство эксплуатации и технического обслуживания (maintainability)
      • надежность и устойчивость к сбоям (reliability)
      • взаимодействия системы с внешним миром (interfaces)
      • расширяемость (scalability)
      • требования к пользовательским и программным интерфейсам (user and software interface).

    Более подробно про атрибуты качества

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

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

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

    Все вышесказанное относится только к дисциплине «Управление требованиями» в рамках методологии RUP. В рамках ГОСТ и определения требований другие и сами требования разбиваются на совершенно другие группы.

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

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

    1. Функциональные требования. Это перечень сервисов, которые должна выполнять система, причем должно быть указано, как система реагирует на те или иные входные данные, как она ведет себя в определенных ситуациях и т.д. В некоторых случаях указывается, что система не должна делать.

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

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

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

    5.2. Пользовательские требования

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

    Вместе с тем при описании требований на естественном языке могут возникнуть различные проблемы.

    1. Отсутствие четкости изложения. Иногда нелегко изложить какую-либо мысль естественным языком четко и недвусмысленно, не сделав при этом текст многословным и трудночитаемым.

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

    3. Объединение требований. Несколько различных требований к системе могут описываться как единое пользовательское требование.

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

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

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

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

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

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

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

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

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

    Требования к программным продуктам

    IEEE Standard Glossary of Software Engineering Terminology определяет требования как:

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

    Какие требования бывают

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

    Смотрите так же:  Техосмотр и страховка стоимость

    Бизнес-требования(business requirements)

    Бизнес-требования(business requirements) содержат высокоуровневые цели организации или заказчиков системы. Как правило, их высказывают те, кто финансируют проект, покупатели системы, менеджер реальных пользователей, отдел маркетинга. В этом документе объясняется, почему организации нужна такая система, то есть описаны цели, которые организация намерена достичь с ее помощью. Мне нравится записывать бизнес-требования в форме документа об образе и границах проекта, который еще иногда называют уставом проекта (project charter) или документом рыночных требований (market requirements document). Определение границ проекта представляет собой первый этап управление общими проблемами увеличения объема работ.

    Требования пользователей (user requirements)

    Требования пользователей (user requirements) описывают цели и задачи, которые пользователям даст система. К отличным способам представления этого вида требований относятся варианты использования, сценарии и таблицы «событие — отклик». Таким образом, в этом документе указано, что клиенты смогут делать с помощью системы.

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

    Функциональные требования (functional requirements) определяют функциональность ПО, которую разработчики должны построить, чтобы пользователи смогли выполнить свои задачи в рамках бизнес-требований. Иногда они называются требованиями поведения (behavioral requirements), они содержат положения с традиционным «должен» или «должна»: «Система должна по электронной почте отправлять пользователю подтверждение о заказе».
    Функциональные требования документируются в спецификации требований к ПО (software requirements specification, SRS), где описывается так полно, как необходимо, ожидаемое поведение системы.

    Системные требования (system requirements)

    Системные требования (system requirements) — это высокоуровневые требования к продукту, которые содержат многие подсистемы. Говоря о системе, мы подразумеваем программное обеспечение или подсистемы ПО и оборудования. Люди — часть системы, поэтому определенные функции системы могут распространяться и на людей.

    Бизнес-правила (business rules)

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

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

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

    Характеристика продукта (feature)

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

    Какими характеристиками должны обладать хорошие требования?

    Характеристики качества превосходных требований:

    Полнота. Каждое требование должно полно описывать функциональность, которую следует реализовать в продукте. То есть оно должно содержать всю информацию, необходимую для разработчиков, чтобы тем удалось создать этот фрагмент функциональности. Если вы понимаете, что данных определенного рода не хватает, используйте пометку «TBD» (to be determined — необходимо определить) на полях как стан-
    дартный флаг для выделения такого места. Восполните все пробелы в каждом фрагменте требований, прежде чем приступать к конструированию этой функции.

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

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

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

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

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

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

    Какими характеристиками должны обладать спецификации требований?

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

    Полнота. Никакие требования или необходимые данные не должны быть пропущены.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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