Требования в Облаке — различия между версиями

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

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

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


Материалы

Предшественник этого Лектио -- Свойства Требований.

Иллюстрации

Текст (HTML)

Требования в Облаке

Первоначально разработчики Брацка Облака создают общее описание будущего изделия. Это описание делается на вики-странице Брацкой Правки, название которой соответствует названию изделия, которое предстоит разработать. Этой странице присваивается категория "Описание изделия для разработки".

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

Чтобы общие описания стали удобными для разработчиков, общие описания разбивают на пользовательские истории (user story). Каждая история представляет собой одну функцию или характеристику и написана с точки зрения конечного пользователя. Значительное количество историй умещается в одно предложение. Например, "координатору информационных проектов нужен формат пользовательских историй, чтобы писать задания для разработчиков." Для разработчиков эти истории указывают на то, что нужно разработать.

Более подробные технические задания (ТЗ) указывают остальное, что необходимо знать разработчикам. Эти ТЗ включают в себя существующие правила и нормы, способ передачи разработчиками своих работ и так далее.

Брацки Техсовет устанавливает общие требования к разработкам для Брацка Облака.

Все требования без исключения создаются в Брацкой Правке и открыты для широкой публики.

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

Наличие множества документов и их версий может создать путаницу. Некоторые документы и их версии могут быть противоречивы. Концепция единого источника истины (single source of truth или SSOT) направлена на решение этой проблемы. Требования только разрабатываются на Брацкой Правке, но их утвержденные версии публикуются на Брацкой Вебке.

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

Варианты

Ответ в форме эссе не подразумевает вариантов.
Следующее лектио -- Что Бизнес-Анализ Есть

Термины

Требования, SSOT, Технические задания, Пользовательские истории, Брацка Правка, Брацка Вебка

Экзамен

Определения

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

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