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

Материал из Брацка Правки
Перейти к: навигация, поиск
(Новая страница: «Типы Требований (здесь и далее по тексту -- ''Лектио'') -- это часть урока Суть Требований…»)
 
(Термины)
 
(не показано 46 промежуточных версий 4 участников)
Строка 9: Строка 9:
 
</gallery>
 
</gallery>
  
===Текст===
+
===Текст (HTML)===
:<p><strong>Типы Требований</strong></p><p>Требования -- это документы, которые представляют видение того, что и как необходимо разработать. Создание требований - это непростой и редко прямолинейный процесс.</p><p>Первоначально разработчики Брацка Облака создают общее описание будущего изделия. Это описание делается на вики-странице Брацкой Правки, название которой соответствует названию изделия, которое предстоит разработать. Этой странице присваивается категория "Описание изделия для разработки".</p><p>Общие описания представляют видение изделия, но они редко бывают ясными или конкретными для реализации разработчиками. Если описания нечётко будут описывать, что будущее изделие должно делать, и как его функции будут проверяться, общие описания также бесполезны для найма подрядчиков.</p><p>Чтобы общие описания стали удобными для разработчиков, общие описания разбивают на пользовательские истории (user story). Каждая история представляет собой одну функцию или характеристику и написана с точки зрения конечного пользователя. Значительное количество историй умещается в одно предложение. Например, "координатору информационных проектов нужен формат пользовательских историй, чтобы писать задания для разработчиков." Для разработчиков эти истории указывают на то, что нужно разработать.</p><p>Более подробные технические задания (ТЗ) указывают остальное, что необходимо знать разработчикам. Эти ТЗ включают в себя существующие правила и нормы, способ передачи разработчиками своих работ и так далее.</p><p>Брацки Техсовет устанавливает общие требования к разработкам для Брацка Облака.</p><p>Все требования без исключения создаются в Брацкой Правке и открыты для широкой публики.</p><p>Политика полной прозрачности служит двум целям. Во-первых, таким образом разработчики требований могут получить больше предложений и дополнений. Во-вторых, даже будущие разработчики могут видеть весь процесс разработки 24 часа в сутки 7 дней в неделю.</p><p>Наличие множества документов и их версий может создать путаницу. Некоторые документы и их версии могут быть противоречивы. Концепция единого источника истины (single source of truth или SSOT) направлена на решение этой проблемы. Требования только разрабатываются на Брацкой Правке, но их утвержденные версии публикуются на Брацкой Вебке.</p><p><i>А теперь, выберите, пожалуйста, лучшее завершение следующего предложения.</i> Судя по тексту выше, требования нужны, чтобы:</p>
+
:<p><strong>Типы Требований</strong></p><p>Требования могут быть классифицированы по большому количеству признаков. Систематизации могут принимать во внимание разницу в объектах применения, векторах действия, степенях доработки, стадиях жизни в проекте, источниках требований, а также разницу в категориях лиц, которые получат выгоду от реализации требований.</p><p>По объекту применения, требования разделяются на требования к продукту и требования к проекту его разработки.</p><ul><li><strong>Требования к изделию</strong> представляют собою описи будущего продукта и создаются в результате бизнес-анализа. Далее, эти требования подразделяются на функциональные, нефункциональные и переходные.</li><li><strong>Требования к проекту</strong> или процессу разработки могут включать требования по срокам, стоимости и другим факторам, влияющим на процесс разработки. Далее, требования к проекту могут быть отнесены к требованиям к разработке и требованиям к приёмке.</li></ul><p>По вектору действия, требования делятся на дозволения и ограничения. Ограничения суживают возможности продукта или его изготовителей, в то время как дозволения, наоборот, расширяют. "Сделать что-то" -- это пример дозволения. Сделать это определённым, определённым образом, к определённому сроку или в рамках определённого бюджета -- это примеры ограничений.</p><p>По степени своей доработки, требования могут быть отнесены к необнаруженным, найденным, находящимся в работе и разработанным.</p><p>По стадии жизни в проекте, требования классифицируются как заявленные, подтверждённые, утверждённые, задействованные в производстве, приоритетные и реализованные.</p><p>По своему происхождению, требования составляют три уровня иерархии.</p><ol type="a"><li><strong>Высшие</strong>, существенные, требования состоят из бизнес-требований и воздействующих факторов. Воздействующие факторы далее включают внешние факторы, такие как законодательство и указания уполномоченных органов, а также внутри-организационные факторы, такие как документы, ресурсы и организационную культуру исполняющего предприятия.</li><li><strong>Пользовательские</strong> требования представляют потребности пользователей для достижения организационных целей.</li><li><strong>Технические</strong> требования представляют задания разработчикам по реализации пользовательских требований.</li></ol><p>По разнице в категориях тех лиц, которые получат выгоду от реализации требований, последние могут быть причислены к бизнес-требованиям, требованиям пользователей, требованиям разработчиков и социальным требованиям.</p><p>Единых классификаций не существует и те, которые перечислены выше, даны для демонстрации их многообразия.</p><p><i>А теперь, выберите, пожалуйста, лучшее завершение следующего предложения.</i> Судя по тексту выше, классификация требований:</p>
  
 
===Варианты===
 
===Варианты===
:разработчики создали верное изделие, а администраторы могли проверить его верность. / координаторы информационных проектов могли разработать пользовательские истории (user story). / открыть процесс разработок широкой публике. / установить единый источник истины (single source of truth).
+
:проста и понятна. / зависит либо от природы конечного результата, либо от типа пользователей. / разделяет их на бизнес-требования, воздействующие факторы, пользовательские требования и требования технические. / зависит от организационной культуры той организации, которая эту классификацию применяет.
  
:Следующее лектио -- '''[[Что Бизнес-Анализ Есть]]'''
+
:Следующее лектио -- '''[[Требования и Желания]]'''
  
 
===Термины===
 
===Термины===
:[[Требования]], [[Эпические продукты]], [[SSOT]]
+
:[[Требования]], [[Высшие требования]], [[Пользовательские требования]], [[Технические требования]]
  
 
==Экзамен==
 
==Экзамен==

Текущая версия на 15:09, 27 сентября 2022

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


Материалы

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

Иллюстрации

Текст (HTML)

Типы Требований

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

По объекту применения, требования разделяются на требования к продукту и требования к проекту его разработки.

  • Требования к изделию представляют собою описи будущего продукта и создаются в результате бизнес-анализа. Далее, эти требования подразделяются на функциональные, нефункциональные и переходные.
  • Требования к проекту или процессу разработки могут включать требования по срокам, стоимости и другим факторам, влияющим на процесс разработки. Далее, требования к проекту могут быть отнесены к требованиям к разработке и требованиям к приёмке.

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

По степени своей доработки, требования могут быть отнесены к необнаруженным, найденным, находящимся в работе и разработанным.

По стадии жизни в проекте, требования классифицируются как заявленные, подтверждённые, утверждённые, задействованные в производстве, приоритетные и реализованные.

По своему происхождению, требования составляют три уровня иерархии.

  1. Высшие, существенные, требования состоят из бизнес-требований и воздействующих факторов. Воздействующие факторы далее включают внешние факторы, такие как законодательство и указания уполномоченных органов, а также внутри-организационные факторы, такие как документы, ресурсы и организационную культуру исполняющего предприятия.
  2. Пользовательские требования представляют потребности пользователей для достижения организационных целей.
  3. Технические требования представляют задания разработчикам по реализации пользовательских требований.

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

Единых классификаций не существует и те, которые перечислены выше, даны для демонстрации их многообразия.

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

Варианты

проста и понятна. / зависит либо от природы конечного результата, либо от типа пользователей. / разделяет их на бизнес-требования, воздействующие факторы, пользовательские требования и требования технические. / зависит от организационной культуры той организации, которая эту классификацию применяет.
Следующее лектио -- Требования и Желания

Термины

Требования, Высшие требования, Пользовательские требования, Технические требования

Экзамен

Определения

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