Свойства Требований — различия между версиями
Gary (обсуждение | вклад) (→Текст) |
Gary (обсуждение | вклад) (→Текст) |
||
| Строка 10: | Строка 10: | ||
===Текст=== | ===Текст=== | ||
| − | :<p><strong>Свойства Требований</strong></p><p>По сути, каждое требование -- это отчёт, описывающий либо простой продукт, либо деталь более сложного продукта, который надо получить, либо деталь процесса его получения. То, что хорошо для отчётов, хорошо и для требований. Качественные требования ясны, своевременны, полны, фактичны, адресны и удобны для претворения в жизнь.</p><p>Качественные требования должны также обладать несколькими дополнительными характеристиками, которыми обладают не все отчёты. Эти характеристики специфичны для требований:</p><ol type="a"><li>Прежде всего, в идеале, одно требование должно адресовать одну деталь или характеристику, которую разработчик будет создавать в результате своей работы.</li><li>К идеалу нужно стремиться, но он не всегда достижим. Если требование адресует более одной детали, крайне | + | :<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> |
===Варианты=== | ===Варианты=== | ||
Версия 12:16, 21 апреля 2021
Свойства Требований (здесь и далее по тексту -- Лектио) -- это часть урока Суть Требований. В Брацкой Школе, уроки делятся на так называемые лектио, каждое из которых состоит из микролекции и одного или нескольких заключительных вопросов. Урок, в свою очередь, относится к практическому семинару Выбор Профессии.
Содержание
Материалы
Предшественник этого Лектио -- Требования и Желания.
Иллюстрации
Текст
Свойства Требований
По сути, каждое требование -- это отчёт, описывающий либо простой продукт, либо деталь более сложного продукта, который надо получить, либо деталь процесса его получения. То, что хорошо для отчётов, хорошо и для требований. Качественные требования ясны, своевременны, полны, фактичны, адресны и удобны для претворения в жизнь.
Качественные требования должны также обладать несколькими дополнительными характеристиками, которыми обладают не все отчёты. Эти характеристики специфичны для требований:
- Прежде всего, в идеале, одно требование должно адресовать одну деталь или характеристику, которую разработчик будет создавать в результате своей работы.
- К идеалу нужно стремиться, но он не всегда достижим. Если требование адресует более одной детали, крайне нежелательно совмещать требования, которые относятся в различным объектам применения. Другими словами, запросы, касаемые продукта, и запросы, касаемые проекта, должны содержаться в разных требованиях.
- Так как требований обычно несколько, они могут содержать те данные, которые важны для их систематизации и расстановки приоритетов.
- Каждое требование должно быть проверяемым. Более того, качественно требование включает в себя тип тестирования и, иногда, описание проверки. Если тестирование описано отдельным документом, отсылка на него как минимум должна быть включена в метаданные требования.
Требование -- это часто документ, отражающий работу нескольких человек, например, бизнес-аналитика, координатора проекта, куратора продукта и инженера-системщика. То требование, которое идёт непосредственно разработчику, должно быть исполняемо. То есть, разработчик, получив требование, должен понимать, что ему или ей необходимо сделать.
А теперь, выберите, пожалуйста, лучшее завершение следующего предложения. Судя по тексту выше, требования нужны, чтобы:
Варианты
- разработчики создали верное изделие, а администраторы могли проверить его верность. / координаторы информационных проектов могли разработать пользовательские истории (user story). / открыть процесс разработок широкой публике. / установить единый источник истины (single source of truth).
- Следующее лектио -- Что Бизнес-Анализ Есть
