Истории и Задания — различия между версиями
Gary (обсуждение | вклад) (→Варианты) |
Gary (обсуждение | вклад) (→Текст) |
||
| Строка 10: | Строка 10: | ||
===Текст=== | ===Текст=== | ||
| − | :<p><strong>Истории и Задания</strong></p><p>Для удобства разработки, общее описание продукта (product epic) разбивается на отдельные требования. Требования к продукту могут быть функциональными и нефункциональными.</p><p>Функциональные требования к продукту описывают отдельные функции (utility), то есть способности изделия выполнить ту работу, ради которой оно должно быть создано. Простыми словами, функциональность -- это то, что система может сделать.</p><p>В оперативно-гибких разработках, эти функции традиционно описываются "пользовательскими историями" в формате из трёх секций:</p><ol type="a"><li><code>Имея права (описывается пользователь или системная роль того, кто получит выгоду от функционала),</code></li><li><code>я хочу (описывается желаемый функционал),</code></li><li><code>чтобы (описывается выгода, которую функционал создаст для пользователя).</code></li></ol><p>Нефункциональные требования к изделию описывают его применимость (warranty), то есть гарантию того, что изделие может быть применено по назначению. Они описываются заданиями, которые адресуют:</p><ol type="a"><li>Доступность будущего продукта, то есть, физическую доступность и доступность восприятия. То, что продукт может делать, не означает, что сделает. В сказке "Волшебник Изумрудного Города" Элли имела серебряные башмачки Гингемы, но не знала об их волшебной силе.</li><li>Готовность продукта к использованию. Эти требования могут включать физическую готовность, а также документацию, маркировку, совместимость с другими системами, соответствие законам и отраслевым инструкциям.</li><li>Технические характеристики, как, например, рабочий ресурс, запас прочности, безопасность и стабильность работы. Технические задания (ТЗ) включают технические характеристики, но часто имеют и другие виды требований,</li><li>Удобство пользования.</li></ol><p>Нефункциональные требования описываются заданиями, так как пользовательские истории не всегда подходят. Например, Брацки Техсовет требует использование последней стабильной версии готового решения. Это требование не является функциональным. Обычный пользователь, скорее всего, не знает, что такое "последняя стабильная версия".</p><p><i>А теперь, выберите, пожалуйста, лучшее завершение следующего предложения.</i> Судя по тексту выше, :</p> | + | :<p><strong>Истории и Задания</strong></p><p>Для удобства разработки, общее описание продукта (product epic) разбивается на отдельные требования. Требования к продукту могут быть функциональными и нефункциональными.</p><p>Функциональные требования к продукту описывают отдельные функции (utility), то есть способности изделия выполнить ту работу, ради которой оно должно быть создано. Простыми словами, функциональность -- это то, что система может сделать.</p><p>В оперативно-гибких разработках, эти функции традиционно описываются "пользовательскими историями" в формате из трёх секций:</p><ol type="a"><li><code>Имея права (описывается пользователь или системная роль того, кто получит выгоду от функционала),</code></li><li><code>я хочу (описывается желаемый функционал),</code></li><li><code>чтобы (описывается выгода, которую функционал создаст для пользователя).</code></li></ol><p>Например,<blockquote><code>Не имея никаких прав, я хочу иметь возможность зарегистрироваться, чтобы записаться на "Вводны Курс".</code></blockquote></p><p>Нефункциональные требования к изделию описывают его применимость (warranty), то есть гарантию того, что изделие может быть применено по назначению. Они описываются заданиями, которые адресуют:</p><ol type="a"><li>Доступность будущего продукта, то есть, физическую доступность и доступность восприятия. То, что продукт может делать, не означает, что сделает. В сказке "Волшебник Изумрудного Города" Элли имела серебряные башмачки Гингемы, но не знала об их волшебной силе.</li><li>Готовность продукта к использованию. Эти требования могут включать физическую готовность, а также документацию, маркировку, совместимость с другими системами, соответствие законам и отраслевым инструкциям.</li><li>Технические характеристики, как, например, рабочий ресурс, запас прочности, безопасность и стабильность работы. Технические задания (ТЗ) включают технические характеристики, но часто имеют и другие виды требований,</li><li>Удобство пользования.</li></ol><p>Нефункциональные требования описываются заданиями, так как пользовательские истории не всегда подходят. Например, Брацки Техсовет требует использование последней стабильной версии готового решения. Это требование не является функциональным. Обычный пользователь, скорее всего, не знает, что такое "последняя стабильная версия".</p><p><i>А теперь, выберите, пожалуйста, лучшее завершение следующего предложения.</i> Судя по тексту выше, :</p> |
===Варианты=== | ===Варианты=== | ||
Версия 02:09, 6 марта 2021
Истории и Задания (здесь и далее по тексту -- Лектио) -- это часть урока Суть Продуктов Работ. В Брацкой Школе, уроки делятся на так называемые лектио, каждое из которых состоит из микролекции и одного или нескольких заключительных вопросов. Урок, в свою очередь, относится к практическому семинару Выбор Профессии.
Содержание
Материалы
Предшественник этого Лектио -- Описи Продуктов.
Иллюстрации
Текст
Истории и Задания
Для удобства разработки, общее описание продукта (product epic) разбивается на отдельные требования. Требования к продукту могут быть функциональными и нефункциональными.
Функциональные требования к продукту описывают отдельные функции (utility), то есть способности изделия выполнить ту работу, ради которой оно должно быть создано. Простыми словами, функциональность -- это то, что система может сделать.
В оперативно-гибких разработках, эти функции традиционно описываются "пользовательскими историями" в формате из трёх секций:
Имея права (описывается пользователь или системная роль того, кто получит выгоду от функционала),я хочу (описывается желаемый функционал),чтобы (описывается выгода, которую функционал создаст для пользователя).
Например,
Не имея никаких прав, я хочу иметь возможность зарегистрироваться, чтобы записаться на "Вводны Курс".Нефункциональные требования к изделию описывают его применимость (warranty), то есть гарантию того, что изделие может быть применено по назначению. Они описываются заданиями, которые адресуют:
- Доступность будущего продукта, то есть, физическую доступность и доступность восприятия. То, что продукт может делать, не означает, что сделает. В сказке "Волшебник Изумрудного Города" Элли имела серебряные башмачки Гингемы, но не знала об их волшебной силе.
- Готовность продукта к использованию. Эти требования могут включать физическую готовность, а также документацию, маркировку, совместимость с другими системами, соответствие законам и отраслевым инструкциям.
- Технические характеристики, как, например, рабочий ресурс, запас прочности, безопасность и стабильность работы. Технические задания (ТЗ) включают технические характеристики, но часто имеют и другие виды требований,
- Удобство пользования.
Нефункциональные требования описываются заданиями, так как пользовательские истории не всегда подходят. Например, Брацки Техсовет требует использование последней стабильной версии готового решения. Это требование не является функциональным. Обычный пользователь, скорее всего, не знает, что такое "последняя стабильная версия".
А теперь, выберите, пожалуйста, лучшее завершение следующего предложения. Судя по тексту выше, :
Варианты
- .
- Следующее лектио -- Продукты Творчества
Термины
Экзамен
Определения
Вопросы экзамена
- Чтобы создать Объем Проекта для планирования вашей работы, вам необходимо описание будущего.________________
