ГП
А чем является?
Size: a a a
2020 October 13
S
Сценарий, и он соотносится к требованию, для дальнешей верификации или валидации требования и его реализации. Он рядом с требованием, но он не требование.
Сценарий- это способ описания требований функционального уровня (если он описан конечно правильно).
TU
а зачем обращаться к Кумскову?
Химик и практик разработки ПО Вигерс имеет большой подтверждённый опыт работы в ИТ и собственные значимые наработки на этой основе в области инженерии требований к ПО
Химик и практик системной инженерии Левенчук имеет большой подтверждённый опыт работы в бизнесе и ИТ и собственные значимые наработки на этой основе в области системной инженерии и инженерии бизнеса
Химик-теоретик Кумсков только обучает, не участвуя в промышленных проектах разработки ПО, насколько я вижу
Химик и практик разработки ПО Вигерс имеет большой подтверждённый опыт работы в ИТ и собственные значимые наработки на этой основе в области инженерии требований к ПО
Химик и практик системной инженерии Левенчук имеет большой подтверждённый опыт работы в бизнесе и ИТ и собственные значимые наработки на этой основе в области системной инженерии и инженерии бизнеса
Химик-теоретик Кумсков только обучает, не участвуя в промышленных проектах разработки ПО, насколько я вижу
Не все видите)
F
Ваше определение включает, но не ограничивает. Если в вашей методологии так, то отлично. У вас тогда вопросов быть не должно. А в другом по другому. Можно было сразу дословно перевести и сослаться на словарь, определенного подхода.
DB
Не все видите)
расскажите, что знаете
F
А по сути почему способ описание требования к функции, может быть просто взаимодействия с функцией? Вы можете превратить Case в требование, если ваш подход это устраивает. Но Case не требование, если задача не поставлена как сделай кейс как требование. На этом я как бы все. Лезть в книги и ссылки времени нет. Могу юыть не прав, но мой опыт показывает именно такой расклад.
KS
А можно пример, а то я запутался. Никогда в стори не видел value. Его из бизнес требования получают. С учетом что не про agile (там стори и есть BR вроде). Или мы не про value, а про другую пользу?
Я не очень понял вопроса:)
Но сама структура стори предполагает наличие value.
As a WHO, I want WHAT, so that VALUE
И ниже список acceptance criteria которые позволят проверить что value получено.
Но сама структура стори предполагает наличие value.
As a WHO, I want WHAT, so that VALUE
И ниже список acceptance criteria которые позволят проверить что value получено.
DF
Value находится в глазах смотрящего (оценивающего) и довольно часто вообще ни с какими метриками не соотносится
KS
А я вот думал, что use case - это вариант использования (системы). То есть "система" подразумевается. Соответственно в ВИ должно быть какое-то взаимодействие с системой.
А user story - это просто формат записи пользовательского требования. Аналог ears на более высоком уровне
А user story - это просто формат записи пользовательского требования. Аналог ears на более высоком уровне
Да, хороший момент с взаимодействием подметил.
Взять наш пример с навигаторами и оповещением о поворотах.
Юзер стори на оповещения - вполне отличный и жизнеспособный способ описать эти требования с вполне конкретной пользой.
В то время как делать юз кейс только на оповещения не стоит, т.к. юзер не взаимодействует с приложением, только ради прослушивания оповещений. Это только часть сценария который будет охвачен юз кейсом.
Взять наш пример с навигаторами и оповещением о поворотах.
Юзер стори на оповещения - вполне отличный и жизнеспособный способ описать эти требования с вполне конкретной пользой.
В то время как делать юз кейс только на оповещения не стоит, т.к. юзер не взаимодействует с приложением, только ради прослушивания оповещений. Это только часть сценария который будет охвачен юз кейсом.
TU
Юз кейсы не требования, они линкуется к требованию. Для верификации или валидации, не помню точно.
+1
ГП
Коллеги, когда мне говорят, что что-то не является требованием, то обычно добавляют, чем же это что-то является.
Вот, например, предлагается отделять требования к системе от дизайна системы. Требования - это, что описывает желаемое поведение снаружи (чёрный ящик), а дизайн - это как она устроена внутри (белый ящик).
Когда вы дружно говорите, что юзкейс - это не требование, вы имеете в виду, что это элемент дизайна? Или имеете в виду что-то третье?
Вот, например, предлагается отделять требования к системе от дизайна системы. Требования - это, что описывает желаемое поведение снаружи (чёрный ящик), а дизайн - это как она устроена внутри (белый ящик).
Когда вы дружно говорите, что юзкейс - это не требование, вы имеете в виду, что это элемент дизайна? Или имеете в виду что-то третье?
DB
это решение по реализации пользовательского требования, которое порождает системные требования как шаги
DB
Пользовательские требования — это требования к человеко-машинной системе
Техническая система является её частью, как батарейки в радио
Техническая система является её частью, как батарейки в радио
DB
обычно первые 2 уровня не видны, сразу фигачат требования к ПО
ГП
То есть это метод преобразования одних требований в другие, так?
DB
То есть это метод преобразования одних требований в другие, так?
через проектирование, по модели сендвича из инженерии требований
ГП
Все выдохнули с облегчением: ну слава богу, Денис всё объяснил. А то мы точно знали, что юзкейсы - не требования, но не могли понять, почему. ;)
ГП
Но я всё же не очень понимаю практическую ценность этого разделения.