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

Материал из Брацка Правки
Перейти к: навигация, поиск
(Текст: добавил недостающую букву "е" в слове)
 
(не показано 7 промежуточных версий 3 участников)
Строка 9: Строка 9:
 
</gallery>
 
</gallery>
  
===Текст===
+
===Текст (HTML)===
:<p><strong>Свойства Требований</strong></p><p>По сути, каждое требование -- это отчёт, описывающий либо простой продукт, либо деталь более сложного продукта, который надо получить, либо деталь процесса его получения. То, что хорошо для отчётов, хорошо и для требований. Качественные требования ясны, своевременны, полны, фактичны, адресны и удобны для претворения в жизнь.</p><p>Качественные требования должны также обладать несколькими дополнительными характеристиками, которыми обладают не все отчёты. Эти характеристики специфичны для требований:</p><ol type="a"><li>Прежде всего, в идеале, одно требование должно адресовать одну деталь или характеристику, которую разработчик будет создавать в результате своей работы.</li><li>К идеалу нужно стремиться, но он не всегда достижим. Если требование адресует более одной детали, крайне нежелательно совмещать требования, которые относятся в различным объектам применения. Другими словами, запросы, касаемые продукта, и запросы, касаемые проекта, должны содержаться в разных требованиях.</li><li>Так как требований обычно несколько, они могут содержать те данные, которые важны для их систематизации и расстановки приоритетов.</li><li>Каждое требование должно быть проверяемым. Более того, качественное требование включает в себя тип тестирования и, иногда, описание проверки. Если тестирование описано отдельным документом, отсылка на него как минимум должна быть включена в метаданные требования.</li></ol><p>В работе на проектах, требование -- это документ, отражающий вклад нескольких человек, например, бизнес-аналитика, координатора проекта, куратора продукта и инженера-системщика. То требование, которое идёт непосредственно разработчику, должно быть исполняемо. То есть, разработчик, получив требование, должен понимать, что ему или ей необходимо сделать.</p><p><i>А теперь, придумайте, пожалуйста, вопрос для завершения этого лектио.</i></p>
+
:<p><strong>Свойства Требований</strong></p><p>По сути, каждое требование -- это отчёт, описывающий либо будущее изделие, либо особенности изготовления какого-то изделия. Изделия варьируются от сложных систем и работ до их минимальных составляющих и деталей.</p><p>То, что хорошо для отчётов, хорошо и для требований. Качественные требования ясны, своевременны, полны, фактичны, адресны и удобны для претворения в жизнь.</p><p>Качественные требования должны также обладать несколькими дополнительными характеристиками, которыми обладают не все отчёты. Эти характеристики специфичны для требований:</p><ol type="a"><li>Прежде всего, в идеале, одно требование должно адресовать одну деталь или характеристику, которую разработчик будет создавать в результате своей работы.</li><li>К идеалу нужно стремиться, но он не всегда достижим. Если требование адресует более одной детали, крайне нежелательно совмещать требования, которые относятся в различным объектам применения. Другими словами, запросы, касаемые продукта, и запросы, касаемые проекта, должны содержаться в разных требованиях.</li><li>Так как требований обычно несколько, они могут содержать те данные, которые важны для их систематизации и расстановки приоритетов.</li><li>Каждое требование должно быть проверяемым. Более того, качественное требование включает в себя тип тестирования и, иногда, описание проверки. Если тестирование описано отдельным документом, отсылка на него как минимум должна быть включена в метаданные требования.</li></ol><p>В работе на проектах, требование -- это документ, отражающий вклад нескольких человек, например, бизнес-аналитика, координатора проекта, куратора продукта и инженера-системщика. То требование, которое идёт непосредственно разработчику, должно быть исполняемо. То есть, разработчик, получив требование, должен понимать, что ему или ей необходимо сделать.</p><p><i>А теперь, выберите, пожалуйста, лучшее завершение следующего предложения.</i>&nbsp;Судя по тексту выше, задание мамы выбросить мусор и не останавливаться по дороге будет примером: </p>
  
 
===Варианты===
 
===Варианты===
:Ответ в форме эссе не подразумевает вариантов.
+
:одного качественного требования./ двух и более требований.
  
 
:Следующее лектио -- '''[[Требования в Облаке]]'''
 
:Следующее лектио -- '''[[Требования в Облаке]]'''
  
 
===Термины===
 
===Термины===
:[[Требования]], [[Эпические продукты]], [[SSOT]]
+
:[[Требования]], [[Product epic]], [[SSOT]], [[Отчёт]]
  
 
==Экзамен==
 
==Экзамен==

Текущая версия на 12:40, 2 октября 2022

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


Материалы

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

Иллюстрации

Текст (HTML)

Свойства Требований

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

То, что хорошо для отчётов, хорошо и для требований. Качественные требования ясны, своевременны, полны, фактичны, адресны и удобны для претворения в жизнь.

Качественные требования должны также обладать несколькими дополнительными характеристиками, которыми обладают не все отчёты. Эти характеристики специфичны для требований:

  1. Прежде всего, в идеале, одно требование должно адресовать одну деталь или характеристику, которую разработчик будет создавать в результате своей работы.
  2. К идеалу нужно стремиться, но он не всегда достижим. Если требование адресует более одной детали, крайне нежелательно совмещать требования, которые относятся в различным объектам применения. Другими словами, запросы, касаемые продукта, и запросы, касаемые проекта, должны содержаться в разных требованиях.
  3. Так как требований обычно несколько, они могут содержать те данные, которые важны для их систематизации и расстановки приоритетов.
  4. Каждое требование должно быть проверяемым. Более того, качественное требование включает в себя тип тестирования и, иногда, описание проверки. Если тестирование описано отдельным документом, отсылка на него как минимум должна быть включена в метаданные требования.

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

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

Варианты

одного качественного требования./ двух и более требований.
Следующее лектио -- Требования в Облаке

Термины

Требования, Product epic, SSOT, Отчёт

Экзамен

Определения

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