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