Відмінності між версіями «Властивості Вимог»

Матеріал з Брацка Правка
Перейти до: навігація, пошук
(Текст)
 
(Не показані 19 проміжних версій 5 користувачів)
Рядок 1: Рядок 1:
[[Свойства Требований]] (здесь и далее по тексту -- ''Лектио'') -- это часть урока [[Суть Требований]]. В [[Брацка Школа|Брацкой Школе]], уроки делятся на так называемые [[лектио]], каждое из которых состоит из микролекции и одного или нескольких заключительных вопросов. Урок, в свою очередь, относится к практическому семинару '''[[Выбор Профессии]]'''.
+
[[Властивості Вимог]] (тут і далі по тексту -- ''Лектіо'') -- це частина уроку [[Суть Требований|Суть Вимог]]. У [[Брацка Школа|Брацькій Школі]], уроки діляться на так звані [[лектио|лектіо]], кожне з яких складається з мікролекції та одного або декількох заключних питань. Урок, своєю чергою, належить до курсу '''[[Выбор Профессии|Вибір Професії]]'''
  
  
Рядок 9: Рядок 9:
 
</gallery>
 
</gallery>
  
===Текст===
+
===Текст (HTML)===
:<p><strong>Свойства Требований</strong></p><p>По сути, каждое требование -- это отчёт, представляющий деталь того, что надо получить, или как надо получить. То, что хорошо для отчётов, хорошо и для требований. Хорошие требования ясны, своевременны, полны, фактичны, адресны и удобны для претворения в жизнь.</p><p>Хорошие требования должны также обладать несколькими дополнительными характеристиками, которые специфичны для требований.</p><ol type="a">Прежде всего, в идеале, одно требование должно адресовать одну деталь или характеристику, которую разработчик будет создавать в результате своей работы.</li><li>К идеалу нужно стремиться, но он не всегда достижим. Если требование адресует более одной детали, крайне желательно не совмещать требования, которые относятся в различным объектам применения. Более конкретно, не следует совмещать запросы, касаемые продукта, и запросы, касаемые проекта, в одном требовании.</li><li>Так как требований обычно несколько, они могут содержать те данные, которые важны для их систематизации и расстановки приоритетов.</li><li>Наконец, каждое требование должно быть проверяемым. Более того, метаданные качественного требования включают в себя тип тестирования и, иногда, описание проверки.</li></ol><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>
  
===Варианты===
+
===Варіанти===
:разработчики создали верное изделие, а администраторы могли проверить его верность. / координаторы информационных проектов могли разработать пользовательские истории (user story). / открыть процесс разработок широкой публике. / установить единый источник истины (single source of truth).
+
:однієї якісної вимоги./ двох і більше вимог.
  
:Следующее лектио -- '''[[Что Бизнес-Анализ Есть]]'''
+
:Следующее лектио -- '''[[Требования в Облаке]]'''
  
 
===Термины===
 
===Термины===
:[[Требования]], [[Эпические продукты]], [[SSOT]]
+
:[[Требования]], [[Product epic]], [[SSOT]], [[Отчёт]]
  
 
==Экзамен==
 
==Экзамен==

Поточна версія на 13:38, 27 листопада 2022

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


Материалы

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

Иллюстрации

Текст (HTML)

Властивості Вимог

По суті, кожна вимога -- це звіт, що описує або майбутній виріб, або особливості виготовлення якогось виробу. Вироби варіюються від складних систем та робіт до їх мінімальних складових та деталей.

Те, що добре для звітів, добре і для вимог. Якісні вимоги ясні, своєчасні, повні, фактичні, адресні та зручні для втілення в життя.

Якісні вимоги повинні також мати кілька додаткових характеристик, які мають не всі звіти. Ці характеристики специфічні для вимог:

  1. Передусім, в ідеалі, одна вимога повинна адресувати одну деталь або характеристику, яку розробник буде створювати в результаті своєї роботи.
  2. До ідеалу потрібно прагнути, але він не завжди досяжний. Якщо вимога адресує більше однієї деталі, вкрай небажано поєднувати вимоги, які стосуються різних об'єктів застосування. Іншими словами, запити, що стосуються продукту, і запити, що стосуються проєкту, повинні міститися в різних вимогах.
  3. Оскільки вимог зазвичай декілька, вони можуть містити ті дані, які важливі для їх систематизації та розміщення пріоритетів.
  4. Кожна вимога має бути перевіреною. Більш того, якісна вимога включає тип тестування і, іноді, опис перевірки. Якщо тестування описане окремим документом, відсилання на нього як мінімум має бути включене до метаданих вимог.

У роботі на проєктах, вимога -- це документ, що відображає внесок кількох людей, наприклад, бізнес-аналітика, координатора проєкту, куратора продукту та інженера-системника. Та вимога, яка йде безпосередньо розробнику, має бути виконуваною. Тобто розробник, отримавши вимогу, повинен розуміти, що йому чи їй необхідно зробити.

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

Варіанти

однієї якісної вимоги./ двох і більше вимог.
Следующее лектио -- Требования в Облаке

Термины

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

Экзамен

Определения

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