Разработки Требований — различия между версиями
Gary (обсуждение | вклад) (→Текст) |
Sonya (обсуждение | вклад) (→Термины) |
||
| (не показаны 22 промежуточные версии 1 участника) | |||
| Строка 1: | Строка 1: | ||
| − | [[Разработки Требований]] (здесь и далее по тексту -- ''Лектио'') -- это часть урока [[Суть | + | [[Разработки Требований]] (здесь и далее по тексту -- ''Лектио'') -- это часть урока [[Суть Создания Заданий]]. В [[Брацка Школа|Брацкой Школе]], уроки делятся на так называемые [[лектио]], каждое из которых состоит из микролекции и одного или нескольких заключительных вопросов. Урок, в свою очередь, относится к практическому семинару '''[[Выбор Профессии]]'''. |
==Материалы== | ==Материалы== | ||
| − | Предшественник этого ''Лектио'' -- [[ | + | Предшественник этого ''Лектио'' -- [[Иерархия Требований]]. |
===Иллюстрации=== | ===Иллюстрации=== | ||
| Строка 9: | Строка 9: | ||
</gallery> | </gallery> | ||
| − | ===Текст=== | + | ===Текст (HTML)=== |
| − | :<p><strong>Разработки Требований</strong></p><p></p><p><i>А теперь, | + | :<p><strong>Разработки Требований</strong></p><p>В буквальном смысле, разработка требований -- это разработка, продуктом которой являются требования. То, что справедливо для разработок вообще, справедливо для разработок требований.</p><p></p><p>Потребителями требований являются как разработчики, так и заказчик. Требования говорят разработчикам что и как надо сделать. Заказчик проверяет соответствует ли созданный продукт и его создание требованиям.</p><p>Полезность требований складывается из их функциональности и применимости. Функциональность требований -- это описание того, что надо сделать и, иногда, как надо делать. Применимость требований -- это их доступность, готовность к использованию и удобство пользования.</p><p>Требования создаются собственными силами или заказываются. Если не сам руководитель, то кто-то из руководства проектом обычно разрабатывает требования к разработке. Бизнес-аналитики разрабатывают требования к продукту. При создании сложных систем, бизнес-аналитики работают с системными инженерами, которые предлагают технические решения. В простых проектах, руководитель может выступать и в роли бизнес-аналитика, и в роли системного инженера.</p><p>Любое требование должно быть утверждено заказчиком или уполномоченным заказчиком лицом. Обычно куратор проекта утверждает сроки, объём и бюджет разработок, а куратор продукта -- его опись.</p><p>Разработки требований могут быть цикличны. Они должны быть цикличны если новые данные появляются периодически. Новые данные часто приходят вместе с новым прототипом или новыми наработками будущего изделия.</p><p>Разработки требований имеют и свои особенности. Если разработка требований ведётся своими силами, она редко оформляется отдельным проектом. Разработка требований всегда оперативна; плановой она не может быть из-за неопределённости. Так как объём требования не может быть заранее определён, если заказчик хочет ограничить объём работ, он или она ограничивает сроки работы над требованиями.</p><p><i>А теперь, придумайте, пожалуйста, вопрос для завершения этого лектио.</i></p> |
===Варианты=== | ===Варианты=== | ||
| − | : | + | :Ответ в форме эссе не подразумевает вариантов. |
| − | :Следующее лектио -- '''[[ | + | :Следующее лектио -- '''[[Обратные Разработки]]''' |
===Термины=== | ===Термины=== | ||
| − | :[[Требования]], [[ | + | :[[Требования]], [[Разработка]] |
==Экзамен== | ==Экзамен== | ||
Текущая версия на 15:11, 27 сентября 2022
Разработки Требований (здесь и далее по тексту -- Лектио) -- это часть урока Суть Создания Заданий. В Брацкой Школе, уроки делятся на так называемые лектио, каждое из которых состоит из микролекции и одного или нескольких заключительных вопросов. Урок, в свою очередь, относится к практическому семинару Выбор Профессии.
Содержание
Материалы
Предшественник этого Лектио -- Иерархия Требований.
Иллюстрации
Текст (HTML)
Разработки Требований
В буквальном смысле, разработка требований -- это разработка, продуктом которой являются требования. То, что справедливо для разработок вообще, справедливо для разработок требований.
Потребителями требований являются как разработчики, так и заказчик. Требования говорят разработчикам что и как надо сделать. Заказчик проверяет соответствует ли созданный продукт и его создание требованиям.
Полезность требований складывается из их функциональности и применимости. Функциональность требований -- это описание того, что надо сделать и, иногда, как надо делать. Применимость требований -- это их доступность, готовность к использованию и удобство пользования.
Требования создаются собственными силами или заказываются. Если не сам руководитель, то кто-то из руководства проектом обычно разрабатывает требования к разработке. Бизнес-аналитики разрабатывают требования к продукту. При создании сложных систем, бизнес-аналитики работают с системными инженерами, которые предлагают технические решения. В простых проектах, руководитель может выступать и в роли бизнес-аналитика, и в роли системного инженера.
Любое требование должно быть утверждено заказчиком или уполномоченным заказчиком лицом. Обычно куратор проекта утверждает сроки, объём и бюджет разработок, а куратор продукта -- его опись.
Разработки требований могут быть цикличны. Они должны быть цикличны если новые данные появляются периодически. Новые данные часто приходят вместе с новым прототипом или новыми наработками будущего изделия.
Разработки требований имеют и свои особенности. Если разработка требований ведётся своими силами, она редко оформляется отдельным проектом. Разработка требований всегда оперативна; плановой она не может быть из-за неопределённости. Так как объём требования не может быть заранее определён, если заказчик хочет ограничить объём работ, он или она ограничивает сроки работы над требованиями.
А теперь, придумайте, пожалуйста, вопрос для завершения этого лектио.
Варианты
- Ответ в форме эссе не подразумевает вариантов.
- Следующее лектио -- Обратные Разработки
