Инженерия требований (Nu'yuyjnx mjyQkfgunw)
Инженерия требований ( Requirements Engineering - RE ) — это общеинженерная техническая дисциплина, которая отвечает за процессы разработки, документирования и поддержания требований. Эта дисциплина входит как в системную инженерию так и в программную инженерию.
Инженер, который занимается разработкой требований для программной или программно-аппаратной системы, называется инженер по требованиям ПО, а в случае системной инженерии часто на практике роль этого инженера может взять на себя системный инженер. В английском языке этот тип инженера называется Requirements Engineer.
Согласно модели CMMI 1.3 [1] инженерия требования на верхнем уровне имеет два больших класса процессов: разработка требований (Requirements Development) и управление требованиями (Requirements Management).
Компании (поставщики) второго уровня модели CMMI не имеют процессов разработки требований, и только управляют спецификациями требований, которые были разработаны заказчиком. Процесс управления требованиями[2] заключается в том, чтобы управлять требованиями продукта, компонент и убеждаться, что требования выравнены относительно проектных планов, фаз и рабочих продуктов.
Компании (поставщики) третьего уровня модели CMMI способны выполнять процессы разработки требований, т.е. разрабатывать требования для решения задач и проблем заказчика на основе исследования нужд заказчика, конечных пользователей, потенциальных сценариев использования, выявления ограничений, зависимостей, окружения и т.п. - другими словами, создавать продукт для решения задач и проблем заказчика, когда заказчик не является экспертом в создаваемом типе систем. Разработка требований[3] - это процесс, целью которого является выявление, анализ и создание требований заказчика, продукта и уровня компонент.
Начиная с версии 2 модели CMMI (актуальна до конца июня 2024 года), а также в самой актуальной версии 3 модели (опубликована в 2023 году), разработка требований и управление требованиями описываются вместе (Requirements Development and Management - RDM) в одном разделе. Тем не менее, с точки зрения инженерии требований принципиальных изменений в классификации поставщиков в CMMI версии 2 нет. В CMMI модели 2.0 практики разработки требований (Requirements Development) отмечены как применимы только для компаний третьего уровня, что является эквивалентным по сути, и минорным изменением относительно CMMI 1.3 с точки зрения инженерии требований.
Примечания
[править | править код]- ↑ Carnegie Mellon University and Software Engineering Institute. CMMI® for Development, Version 1.3 (PDF). Архивировано (PDF) 5 сентября 2023. Дата обращения: 5 сентября 2023.
- ↑ Carnegie Mellon University and Software Engineering Institute. CMMI® for Development, Version 1.3, Requirements Management chapter (PDF). p. 341. Архивировано (PDF) 5 сентября 2023. Дата обращения: 5 сентября 2023.
- ↑ Carnegie Mellon University and Software Engineering Institute. CMMI® for Development, Version 1.3, Requirements Development chapter (PDF). p. 325. Архивировано (PDF) 5 сентября 2023. Дата обращения: 5 сентября 2023.
На эту статью не ссылаются другие статьи Википедии. |