Управление требованиями
Требования и их типы. Деятельность, связанная с разработкой требований
Требование — это единичная задокументированная физическая или функциональная потребность, которую стремится удовлетворить конкретная конструкция, продукт или процесс.
Можно сказать, что требования относятся к двум областям:
- Требования к продукту предписывают свойства системы или продукта.
- Требования к процессу предписывают действия, которые должны выполняться развивающейся организацией. Например, требования к процессам могут определять методологии, которым необходимо следовать, и ограничения, которым должна подчиняться организация.
Типы требований
Требования обычно классифицируются по типам, созданным на разных этапах развития, при этом таксономия зависит от используемой общей модели. Например, следующая схема была разработана Международным институтом бизнес-анализа в их Своде знаний по бизнес-анализу.
Архитектурные требования
Архитектурные требования объясняют, что должно быть сделано, определяя необходимую интеграцию структуры и поведения систем, т. е. системную архитектуру системы. В программной инженерии они называются архитектурно значимыми требованиями, которые определяются как те требования, которые оказывают измеримое влияние на архитектуру программной системы.
Бизнес-требования
Высокоуровневые формулировки целей, задач или потребностей организации. Обычно они описывают возможности, которые организация хочет реализовать, или проблемы, которые они хотят решить. Часто указывается в бизнес-кейсе.
Требования к пользователям (заинтересованным сторонам)
Заявления среднего уровня о потребностях конкретной заинтересованной стороны или группы заинтересованных сторон. Обычно они описывают, как кто-то хочет взаимодействовать с предполагаемым решением. Часто выступает в качестве промежуточной точки между высокоуровневыми бизнес-требованиями и более подробными требованиями к решению.
Функциональные требования (требования к решению)
Обычно подробные описания возможностей, поведения и сведений, которые потребуются решению. Примеры включают форматирование текста, вычисление числа, модуляцию сигнала. Их также иногда называют возможностями.
Требования к качеству обслуживания (нефункциональные)
Обычно подробные описания условий, при которых решение должно оставаться эффективным, качеств, которыми должно обладать решение, или ограничений, в которых оно должно работать. Примеры: надежность, тестируемость, ремонтопригодность, доступность. Они также известны как характеристики, ограничения или недостатки.
Требования к реализации (переходу)
Как правило, подробные описания возможностей или поведения требуются только для того, чтобы обеспечить переход от текущего состояния предприятия к желаемому будущему состоянию, но после этого это больше не потребуется. Примеры включают набор персонала, смену ролей, обучение, миграцию данных из одной системы в другую.
Нормативные требования
Требования, определенные законами (федеральными, государственными, муниципальными или региональными), контрактами (условиями) или политиками (на уровне компании, департамента или проекта).
Управление требованиями включает в себя:
- Анализ и выявления целей и ограничений организации.
- Поддержку планирования требований, интеграцию требований и организации для работы с ними (атрибуты для требований), а также связи с другой информацией, поставляемой в соответствии с требованиями, и изменения для них.
Деятельность, связанная с разработкой требований
В соответствии с ISO/IEC TR 24766:2009 виды деятельности, связанные с разработкой требований, широко варьируются в зависимости от типа разрабатываемой системы и конкретной практики (практик) организации. Они могут включать:
- Постановка требований или выявление требований — разработчики и заинтересованные стороны встречаются; Последних спрашивают об их потребностях и желаниях в отношении программного продукта.
- Анализ требований и согласование — выявляются требования (в том числе новые, если разработка является итеративной) и разрешаются конфликты с заинтересованными сторонами. Как письменные, так и графические инструменты (последние обычно используются на этапе проектирования, но некоторые находят их полезными и на этом этапе) успешно используются в качестве вспомогательных средств. Примеры письменных инструментов анализа: сценарии использования и пользовательские истории.
- Системное моделирование — Некоторые инженерные области (или конкретные ситуации) требуют, чтобы продукт был полностью спроектирован и смоделирован до начала его строительства или изготовления. Поэтому этап проектирования должен быть выполнен заранее. Например, чертежи здания должны быть разработаны до того, как какой-либо контракт может быть утвержден и подписан.
- Спецификация требований — требования документируются в формальном артефакте, называемом спецификацией требований (RS), который станет официальным только после проверки. При необходимости RS может содержать как письменную, так и графическую (модели) информацию. Пример: Спецификация требований к программному обеспечению (SRS).
- Проверка требований — проверка того, что задокументированные требования и модели согласованы и соответствуют потребностям заинтересованных сторон. Только в том случае, если окончательный проект проходит процесс утверждения, РС становится официальным.
- Управление требованиями — Управление всеми действиями, связанными с требованиями, с момента создания, надзор по мере разработки системы и даже до ее ввода в эксплуатацию (например, изменения, расширения и т. д.)
Иногда они представляются в виде хронологических этапов, хотя на практике эти виды деятельности в значительной степени переплетаются.
Управление требованиями. Прослеживаемость требований
Управление требованиями — это процесс документирования, анализа, отслеживания, определения приоритетов и согласования требований, а затем контроля изменений и информирования соответствующих заинтересованных сторон. Это непрерывный процесс на протяжении всего проекта. Требование — это возможность, которой должен соответствовать результат проекта (продукт или услуга).
Управление требованиями включает в себя общение между членами проектной команды и заинтересованными сторонами, а также корректировку изменений требований на протяжении всего проекта. Чтобы один класс требований не перекрывал другой, решающее значение имеет постоянное общение между членами команды разработчиков. Например, при разработке программного обеспечения для внутренних приложений у бизнеса настолько сильные потребности, что он может игнорировать требования пользователей или полагать, что при создании сценариев использования учитываются требования пользователей.
Прослеживаемость требований связана с документированием срока действия требования. Должна быть возможность проследить происхождение каждого требования, и поэтому каждое изменение, внесенное в требование, должно быть задокументировано для достижения прослеживаемости. Даже использование требования после того, как реализованные функции были развернуты и использованы, должно быть прослеживаемым.
Требования поступают из разных источников, таких как деловой человек, заказывающий продукт, менеджер по маркетингу и фактический пользователь. У всех этих людей разные требования к продукту. Используя прослеживаемость требований, реализованная функция может быть прослежена до человека или группы, которые хотели ее получить во время выявления требований. Это может, например, быть использовано в процессе разработки для определения приоритетов требования, определяя, насколько ценно требование для конкретного пользователя. Его также можно использовать после развертывания, когда пользовательские исследования показывают, что функция не используется, чтобы понять, почему она потребовалась в первую очередь.
Установленная прослеживаемость используется при управлении требованиями для отчетности о выполнении интересов компании и заинтересованных сторон с точки зрения соответствия, полноты, охвата и согласованности. Прослеживаемость также поддерживает управление изменениями как часть управления требованиями в понимании влияния изменений через требования или другие связанные элементы (например, функциональное воздействие через отношения к функциональной архитектуре) и облегчает внедрение этих изменений.
Инструменты для поддержки управления требованиями
Инструменты разработки требований обычно представляют собой программные продукты, облегчающие процессы ВИЭ и позволяющие более систематически и формализовано обрабатывать требования, управлять изменениями и прослеживать.
Руководство PMI «Управление требованиями: практическое руководство» рекомендует определять инструмент требований в начале проекта, поскольку прослеживаемость может стать сложной, и что переключение инструмента в среднесрочной перспективе может представлять проблему.
Приобретение инструмента для поддержки управления требованиями не является тривиальным вопросом, и его необходимо проводить в рамках более широкой инициативы по совершенствованию процессов. Уже давно сложилось мнение, что инструмент, однажды приобретенный и установленный в проекте, может удовлетворить все его потребности, связанные с управлением требованиями. Однако покупка или разработка инструмента для поддержки управления требованиями может быть дорогостоящим решением. Организации могут быть обременены дорогостоящими контрактами на поддержку, непропорциональные усилия могут быть неправильно направлены на обучение использованию инструмента и его настройку для удовлетворения конкретных потребностей, а также неправильное использование, которое может привести к ошибочным решениям. Организации должны следовать поэтапному процессу, чтобы принимать решения об инструментах для удовлетворения своих конкретных потребностей в более широком контексте своего процесса разработки и инструментов.
Отдельные вопросы управления требованиями
Рекомендуемая литература
- Каррильо де Хеа, Хуан М.; Николас, Хоакин; Алеман, Хосе Л. Фернандес; Товаль, Амбросио; Эберт, Кристоф; Бискайно, Аврора (июль 2011 г.). «Инструменты разработки требований». Программное обеспечение IEEE. 28 (4): 86–91. doi:10.1109/MS.2011.81. ISSN 0740-7459. S2CID 1921630.
- Нусейбе, Б.; Истербрук, С. (2000). Разработка требований: дорожная карта (PDF). ICSE’00. Материалы конференции, посвященной будущему программной инженерии. С. 35–46. CiteSeerX 10.1.1.131.3116. DOI:10.1145/336512.336523. ISBN 1-58113-253-0.
- Янг, Ральф Р. (2001). Эффективные методы работы с требованиями. Аддисон-Уэсли. ISBN 978-0-201-70912-4.
Статьи в журнале по теме Управление требованиями
Посмотреть еще в категории: Управление процессами
- Управление активами
- Управление программами
- Управление эффективностью
- Управление безопасностью
- Управление маркетингом
- Управление финансами
- Управление персоналом
- Управление рисками
- Управление производством
- Управление отношениями
- Управление качеством
- Стратегическое управление
- Управление коммуникациями
- Юридическое управление
- Управление перевозками
- Управление рабочим процессом
- Управление закупками (поставкам)