stringtranslate.com

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

В программной инженерии и системной инженерии функциональное требование определяет функцию системы или ее компонента, где функция описывается как резюме (или спецификация, или утверждение) поведения между входами и выходами. [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-A, Процедура анализа требований". Основы системной инженерии (PDF) . Правительство США Армия США. 2001. ISBN 978-1484120835. Архивировано из оригинала (PDF) 31 января 2017 г. . Получено 18 марта 2016 г. .
  3. ^ Loucopoulos, P. (2005). "Глава 4: Требования к проектированию". В Clarkson J, Eckert C (ред.). Улучшение процесса проектирования: обзор текущей практики . Springer-Verlag. стр. 116–139. ISBN 9781846280610.
  4. ^ ab Adams, KM (2015). "3.2 Определения функциональных и нефункциональных требований". Нефункциональные требования в системном анализе и проектировании . Springer. стр. 45–50. ISBN 9783319183442.
  5. ^ Jönsson P, Lindvall M (2006). "Глава 6: Анализ воздействия". В Aurum A, Wohlin C (ред.). Требования к проектированию и управлению программным обеспечением . Springer Science & Business Media. стр. 117–42. ISBN 9783540282440.
  6. ^ MITRE Corporate Communications and Public Affairs. «Инженерия требований: выявление, сбор и разработка требований». Руководство по системной инженерии MITRE. Корпорация MITRE. стр. 304–13. ISBN 9780615974422. Получено 15 июня 2018 г.
  7. ^ ab Stellman, Andrew; Greene, Jennifer (2005). "Глава 6: Требования к программному обеспечению". Applied Software Project Management . O'Reilly Media. стр. 97–130. ISBN 9780596553821. Получено 15 июня 2018 г.