Разработки Требований
Разработки Требований (здесь и далее по тексту -- Лектио) -- это часть урока Суть Создания Заданий. В Брацкой Школе, уроки делятся на так называемые лектио, каждое из которых состоит из микролекции и одного или нескольких заключительных вопросов. Урок, в свою очередь, относится к практическому семинару Выбор Профессии.
Содержание
Материалы
Предшественник этого Лектио -- Методы Сбора.
Иллюстрации
Текст
Разработки Требований
Буквально, разработка требований -- это разработка, продуктом которой являются требования. То, что справедливо для разработок вообще, справедливо для разработок требований.
Потребителями требований являются как разработчики, так и заказчик. Требования говорят разработчикам что и как надо сделать. Заказчик проверяет соответствует ли созданный продукт и его создание требованиям.
Полезность требований складывается из их функциональности и применимости. Функциональность требований -- это описание того, что надо сделать и, иногда, как надо делать. Применимость требований -- это их доступность, готовность к использованию и удобство пользования.
Требования создаются собственными силами или заказываются. Если не сам руководитель, то кто-то из руководства проектом обычно разрабатывает требования к разработке. Бизнес-аналитики разрабатывают требования к продукту. При создании сложных систем, бизнес-аналитики работают с системными инженерами, которые предлагают технические решения. В простых проектах, руководитель может выступать и в роли бизнес-аналитика, и в роли системного инженера.
Любое требование должно быть утверждено заказчиком или уполномоченным заказчиком лицом. Обычно куратор проекта утверждает сроки, объём и бюджет разработок, а куратор продукта -- его опись.
А теперь, выберите, пожалуйста, лучшее завершение следующего предложения. Судя по тексту выше, требования нужны, чтобы:
Управление требованиями или Планирование! Давайте сначала рассмотрим важность анализа заинтересованных сторон и управления заинтересованными сторонами. Вы начинаете объяснять концепцию наличия разных типов заинтересованных сторон, которые вовлечены в проект, и что каждый играет свою роль. Вы пытаетесь охватить метод анализа заинтересованных сторон, называемый моделью RACI, и я думаю, что, возможно, столкнулся с этим несколько лет назад в другой роли. Я вижу, что взаимодействие с заинтересованными сторонами и анализ являются очень важной частью бизнес-анализа, и принимаю это во внимание в общем смысле. Опять же, мне пришлось бы оставить понимание техник и различных аспектов и подходов к построению отношений на другой день.
Варианты
- разработчики создали верное изделие, а администраторы могли проверить его верность. / координаторы информационных проектов могли разработать пользовательские истории (user story). / открыть процесс разработок широкой публике. / установить единый источник истины (single source of truth).
- Следующее лектио -- Обратные Разработки
