Конфликты Требований — различия между версиями

Материал из Брацка Правки
Перейти к: навигация, поиск
(Новая страница: «Бизнес и Пользователи (здесь и далее по тексту -- ''Лектио'') -- это часть урока Суть Бизн…»)
 
(→‎Термины)
 
(не показаны 22 промежуточные версии 1 участника)
Строка 1: Строка 1:
−
[[Бизнес и Пользователи]] (здесь и далее по тексту -- ''Лектио'') -- это часть урока [[Суть Бизнес-Анализа]]. В [[Брацка Школа|Брацкой Школе]], уроки делятся на так называемые [[лектио]], каждое из которых состоит из микролекции и одного или нескольких заключительных вопросов. Урок, в свою очередь, относится к практическому семинару '''[[Выбор Профессии]]'''.
+
[[Конфликты Требований]] (здесь и далее по тексту -- ''Лектио'') -- это часть урока [[Суть Создания Заданий]]. В [[Брацка Школа|Брацкой Школе]], уроки делятся на так называемые [[лектио]], каждое из которых состоит из микролекции и одного или нескольких заключительных вопросов. Урок, в свою очередь, относится к практическому семинару '''[[Выбор Профессии]]'''.
  
  
 
==Материалы==
 
==Материалы==
−
Предшественник этого ''Лектио'' -- [[Требования к Продукту]].
+
Предшественник этого ''Лектио'' -- [[Обратные Разработки]].
  
 
===Иллюстрации===
 
===Иллюстрации===
Строка 9: Строка 9:
 
</gallery>
 
</gallery>
  
−
===Текст===
+
===Текст (HTML)===
−
:<p><strong>Бизнес и Пользователи</strong></p><p>Требования к продукту -- это та часть требований, которая относится к тому изделию или продукту, который необходимо создать. Другая часть требований относится к разработке этого изделия или продукта.</p><p>Требования к продукту создаются в результате бизнес-анализа и подразделяются на функциональные, нефункциональные и переходные:</p><ol type="a"><li>Функциональные требования к создаваемому изделию или продукту описывают способности будущего изделия выполнить ту работу, ради которой оно создаётся.</li><li><p>Нефункциональные требования или требования по применимости создаваемого изделия описывают гарантии того, что пользователи смогут воспользоваться функциями создаваемого изделия. Нефункциональные требования включают условия доступности изделия, готовности его к использованию, его рабочему ресурсу, запасу прочности, безопасности, стабильности работы и удобству пользования (usability).</p></li><li>Переходные требования описывают те характеристики и условия, которыми изделие должно обладать для того, чтобы быть доставленным к заказчику и установленным. Переходные требования могут также описывать характеристики и условия, которыми изделие должно обладать для того, чтобы быть демонтированным и утилизованным. В отношении физических товаров, эти требования как минимум будут включать условия по упаковке и транспортировке. В отношении пользовательских программ, эти требования должны включать условия по установке и удалению программ.</li></ol><p>Переходные требования могут таким образом разделяться на предэксплуатационные и послеэксплуатационные. Аналогично нефункциональным и функциональным требованиям, переходные условия и характеристики могут также категоризоваться как требования к переходной применимости и требования к переходным функциям.</p><p>Системы включают в себя несколько изделий. Например, космические аппараты включают туалеты. Туалеты не являются функциональным требованием к космическим аппаратам, так как последние могут летать и без первых. Однако космонавты без туалета не обойдутся и потому нефунциональное требование наличия действующего туалета обязательно.</p><p>Однако космический туалет сам по себе имеет также функциональные требования к тому, что туалет должен делать. Космический туалет имеет и особые нефункциональные требования, так как использование туалета в условиях невесомости имеет свои коренные отличия от использования туалета в условиях гравитации. И эти особые приспособления будут иметь свои функциональные, нефункциональные и переходные требования.</p><p><i>А теперь, выберите, пожалуйста, лучшее завершение следующего предложения.</i> Судя по тексту выше, :</p>
+
:<p><strong>Конфликты Требований</strong></p><p>Как требования к будущему продукту, так и требования к его разработке олицетворяют согласие заказчика оплачивать решение каких-то проблем или удовлетворение каких-то бизнес-потребностей. Деньги стоят за разработкой и ещё большие деньги могут стоять за разработанным продуктом.</p><p>Нельзя сказать, что процесс создания требований -- это всегда борьба за получение наибольшего куска от имеющегося пирога. Однако, как любая делёжка денег, работа над требованиями всегда несёт в себе потенциал для конфликтов.</p><p>Отношения между заказчиком и подрядчиком могут выйти из-под контроля, если стороны не определили рамки сотрудничества. Это касается как всего проекта, так и разработки требований. Хотя обе стороны обычно зантересованы в успехе и, часто, продолжении сотрудничества, у сторон всегда есть почва для разногласий.</p><p>Объём работ по требованиям обычно невозможно определить. Фиксированная сумма за разработку требований провоцирует бесконтрольное раздувание объёмов.</p><p>Вот обычный сценарий провального проекта. Чтобы получить заказ, подрядчик предложил бесплатную разработку требований. Когда выяснилось, что разработка затягивается и расходы растут, подрядчик решил начать работу по незаконченным требованиям. Когда готовое изделие принесли заказчику, тот воскликнул что-то типа: "Да это же чёрное! Я заказывал жёлтое! Мне чёрное не нужно; я не могу платить за чёрное."</p><p>Почасовая ставка за разработку требований -- это, пожалуй, лучшая практика. Для привлечения заказчика, подрядчик может теоретически предложить бесплатную разработку, но в договоре тогда необходимо оговорить часовой предел бесплатных работ.</p><p>Если интересы заказчика распределены по нескольким людям и группам, противоречия между ними также могут служить плодородной почвой для столкновений. Потому хорошие сборщики требований проводят анализ заинтересованных сторон и документируют источники требований так, чтобы можно было проследить их истоки.</p><p>Наконец, прослеживаемость требований -- это инструмент отделения требований заказчика от пожеланий отдельных участников разработок.</p><p><i>А теперь, придумайте, пожалуйста, вопрос для завершения этого лектио.</i></p>
  
 
===Варианты===
 
===Варианты===
−
:разработчики создали верное изделие, а администраторы могли проверить его верность. / координаторы информационных проектов могли разработать пользовательские истории (user story). / открыть процесс разработок широкой публике. / установить единый источник истины (single source of truth).
+
:Ответ в форме эссе не подразумевает вариантов.
  
−
:Следующее лектио -- '''[[Результаты Аналитики]]'''
+
:Следующее лектио -- '''[[Учёт в Требованиях]]'''
  
 
===Термины===
 
===Термины===
−
:[[Требования]], [[Эпические продукты]], [[SSOT]]
+
:[[Требования]], [[Подрядчик проекта]], [[Объём работ]]
  
 
==Экзамен==
 
==Экзамен==

Текущая версия на 15:16, 27 сентября 2022

Конфликты Требований (здесь и далее по тексту -- Лектио) -- это часть урока Суть Создания Заданий. В Брацкой Школе, уроки делятся на так называемые лектио, каждое из которых состоит из микролекции и одного или нескольких заключительных вопросов. Урок, в свою очередь, относится к практическому семинару Выбор Профессии.


Материалы

Предшественник этого Лектио -- Обратные Разработки.

Иллюстрации

Текст (HTML)

Конфликты Требований

Как требования к будущему продукту, так и требования к его разработке олицетворяют согласие заказчика оплачивать решение каких-то проблем или удовлетворение каких-то бизнес-потребностей. Деньги стоят за разработкой и ещё большие деньги могут стоять за разработанным продуктом.

Нельзя сказать, что процесс создания требований -- это всегда борьба за получение наибольшего куска от имеющегося пирога. Однако, как любая делёжка денег, работа над требованиями всегда несёт в себе потенциал для конфликтов.

Отношения между заказчиком и подрядчиком могут выйти из-под контроля, если стороны не определили рамки сотрудничества. Это касается как всего проекта, так и разработки требований. Хотя обе стороны обычно зантересованы в успехе и, часто, продолжении сотрудничества, у сторон всегда есть почва для разногласий.

Объём работ по требованиям обычно невозможно определить. Фиксированная сумма за разработку требований провоцирует бесконтрольное раздувание объёмов.

Вот обычный сценарий провального проекта. Чтобы получить заказ, подрядчик предложил бесплатную разработку требований. Когда выяснилось, что разработка затягивается и расходы растут, подрядчик решил начать работу по незаконченным требованиям. Когда готовое изделие принесли заказчику, тот воскликнул что-то типа: "Да это же чёрное! Я заказывал жёлтое! Мне чёрное не нужно; я не могу платить за чёрное."

Почасовая ставка за разработку требований -- это, пожалуй, лучшая практика. Для привлечения заказчика, подрядчик может теоретически предложить бесплатную разработку, но в договоре тогда необходимо оговорить часовой предел бесплатных работ.

Если интересы заказчика распределены по нескольким людям и группам, противоречия между ними также могут служить плодородной почвой для столкновений. Потому хорошие сборщики требований проводят анализ заинтересованных сторон и документируют источники требований так, чтобы можно было проследить их истоки.

Наконец, прослеживаемость требований -- это инструмент отделения требований заказчика от пожеланий отдельных участников разработок.

А теперь, придумайте, пожалуйста, вопрос для завершения этого лектио.

Варианты

Ответ в форме эссе не подразумевает вариантов.
Следующее лектио -- Учёт в Требованиях

Термины

Требования, Подрядчик проекта, Объём работ

Экзамен

Определения

Вопросы экзамена

Источник — «https://pravka.bskol.com/w1/index.php?title=Конфликты_Требований&oldid=27564»