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