Около корпоративной архитектуры

Функциональный компонент «Требование» Requirement Functional Component

Простыми словами

Компонент — система записи по всем требованиям: ведёт их жизненный цикл и состояние и держит прослеживаемость каждого требования до исходного источника — спроса, ИТ- или бизнес-стандарта, политики, заказчика — и дальше до исходников и тест-кейсов. Отвечает на вопрос «не потерялось ли требование между планированием, разработкой и приёмкой», причём стандарт прямо распространяет его работу за границы ИТ-инициативы: собирать, уточнять, определять объём и отслеживать продвижение требований нужно и до её начала, и после её завершения. Из требований он выводит продуктовые и программные бэклоги — очереди для развития ИТ-услуг. Отличать от Portfolio Demand Functional Component потока S2P: тот принимает и группирует спрос, а этот раскладывает спрос в требования и отвечает за их прослеживаемость.

Примеры

Работа не кончается вместе с инициативой

«Shall collect, refine, scope, and track progress of Requirements even before and after an IT Initiative has concluded.»

IT4IT Reference Architecture, Version 2.1, разд. 6.4.2 — функциональные критерии

Бэклоги выводятся из требований

«Shall derive product or program backlogs which will ultimately serve as queues for enhancing IT services.»

Требования вкладываются друг в друга

«Shall allow hierarchical relationships between Requirements.»

IT4IT Reference Architecture, Version 2.1, разд. 6.4.2 — критерии архитектуры данных

Определение из первоисточника

дословная выписка
Manage Requirements through the lifecycle of a service. Service-level requirements are captured as Requirements. Collect, refine, scope, and track progress of Requirements even before and after an IT Initiative has concluded. Maintain traceability of each Requirement to the original source (demand, IT or business standard or policy, and/or requestor) and to appropriate Source and/or Test Cases throughout the service lifecycle. Derive product or program backlogs which will ultimately serve as queues for enhancing IT services.

машинный перевод

Управлять требованиями на протяжении жизненного цикла услуги. Требования уровня услуги фиксируются как Requirements. Собирать, уточнять, определять объём и отслеживать продвижение требований — в том числе до начала и после завершения ИТ-инициативы. Поддерживать прослеживаемость каждого требования до исходного источника (спрос, ИТ- или бизнес-стандарт либо политика, заказчик) и до соответствующего исходного кода и тест-кейсов на всём жизненном цикле услуги. Выводить продуктовые или программные бэклоги, которые в итоге служат очередями на улучшение ИТ-услуг.

ИсточникThe Open Group IT4IT™ Reference Architecture, Version 2.1. The Open Group, 30.01.2017, C171, US ISBN 1-937218-84-3

Основные параметры

Атрибуты этой сущности по справочнику источника.

Функциональные критерии стандарта: Shall be the system of record (authoritative source) for all Requirements. Shall manage the lifecycle of the Requirement. Shall manage the state of a Requirement. Shall manage Requirements through the lifecycle of a service. Shall capture service-level Requirements. Shall collect, refine, scope, and track progress of Requirements even before and after an IT Initiative has concluded. Shall maintain traceability of each Requirement to the original source (demand, IT or business standard or policy, and/or requestor) and to appropriate source and/or Test Cases throughout the service lifecycle. Shall derive product or program backlogs which will ultimately serve as queues for enhancing IT services. Can manage the data flow to provide Requirement information to the Service Design functional component if a Service Design functional component exists. Shall allow a Requirement to be traced to one or more Test Cases designed to test this Requirement if a Test functional component exists. Shall allow one or more Requirements to be associated to one or more policies that these Requirements originate from if a Policy functional component exists. Shall allow one or more Requirements to be traced to one or more Sources if a Source data object exists. Объекты данных компонента: Requirement.

Связанные понятия

Поддерживающая функция «Знания и совместная работа»Портал взаимодействия и опыта Функциональный компонент «Архитектура предприятия»Функциональный компонент «Возврат затрат / показ затрат»Функциональный компонент «Дефект»Функциональный компонент «Диагностика и устранение»Функциональный компонент «Инцидент»Функциональный компонент «Исполнение заявки»

Служебные сведения

Вид документа: Функциональный компонент
Место в подходе: Requirement to Deploy (R2D) Value Stream
Редакция: The Open Group IT4IT™ Reference Architecture, Version 2.1 (2017, C171)

14 дней бесплатно

Опишите архитектуру своей компании в Storm

Реестр процессов, архитектурное рабочее пространство, связи между системами и процессами — те самые артефакты, только про вашу организацию.

Попробовать бесплатно Без банковской карты

Это же в StormРеестр процессов Имитационное моделирование Архитектура систем и интеграций