Функциональное требование - Functional requirement

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

Функциональные требования могут включать в себя вычисления, технические детали, манипулирование и обработку данных, а также другие конкретные функции, которые определяют, что система должна выполнять.[2] Поведенческие требования описывают все случаи, когда система использует функциональные требования, они отражены в сценарии использования. Функциональные требования поддерживаются нефункциональные требования (также известные как «требования к качеству»), которые налагают ограничения на дизайн или реализацию (например, требования к производительности, безопасности или надежности). Обычно функциональные требования выражаются в форме «система должна выполнять <требование>», а нефункциональные требования принимают форму «система должна быть <требование>».[3] План реализации функциональных требований детализирован в проекте системы, тогда как нефункциональный требования подробно описаны в архитектуре системы.[4][5]

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

В некоторых случаях аналитик требований генерирует варианты использования после сбора и проверки набора функциональных требований. Иерархия сбора и изменения функциональных требований, в общем, следующая: пользователь /акционер запрос → проанализировать → вариант использования → включить. Заинтересованные стороны делают запрос; системные инженеры пытаются обсуждать, наблюдать и понимать аспекты требования; сценарии использования, диаграммы взаимосвязей сущностей и другие модели создаются для проверки требований; и, если это задокументировано и утверждено, требование внедряется / включается.[6] Каждый вариант использования иллюстрирует поведенческие сценарии с помощью одного или нескольких функциональных требований. Однако часто аналитик начинает с выявления набора вариантов использования, из которых он может вывести функциональные требования, которые должны быть реализованы, чтобы позволить пользователю выполнить каждый вариант использования.

Процесс

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

Смотрите также

Рекомендации

  1. ^ Фултон Р., Вандермолен Р. (2017). «Глава 4: Требования - Требования к письму». Обеспечение проектирования бортового электронного оборудования: практическое руководство по RTCA / DO-254. CRC Press. С. 89–93. ISBN  9781351831420. Получено 15 июн 2018.
  2. ^ «Приложение 4-А, Процедура анализа требований». Основы системной инженерии (PDF). Правительство США Армия США. 2001 г. ISBN  978-1484120835. Архивировано из оригинал (PDF) 31 января 2017 г.. Получено 18 марта 2016.
  3. ^ Лукопулос, П. (2005). «Глава 4: Разработка требований». В Clarkson J, Eckert C (ред.). Улучшение процесса проектирования: обзор текущей практики. Springer-Verlag. С. 116–139. ISBN  9781846280610.
  4. ^ а б Адамс, К. (2015). «3.2 Определения функциональных и нефункциональных требований». Нефункциональные требования в системном анализе и проектировании. Springer. С. 45–50. ISBN  9783319183442.
  5. ^ Йонссон П., Линдвалл М. (2006). «Глава 6: Анализ воздействия». В Aurum A, Wohlin C (ред.). Разработка и управление требованиями к программному обеспечению. Springer Science & Business Media. С. 117–42. ISBN  9783540282440.
  6. ^ MITRE Корпоративные коммуникации и связи с общественностью. «Разработка требований: выявление, сбор и разработка требований». Руководство по проектированию систем MITER. Корпорация МИТЕР. С. 304–13. ISBN  9780615974422. Получено 15 июн 2018.
  7. ^ а б Стеллман, Эндрю; Грин, Дженнифер (2005). «Глава 6: Требования к программному обеспечению». Управление прикладным программным обеспечением. O'Reilly Media. С. 97–130. ISBN  9780596553821. Получено 15 июн 2018.