Хотелось бы понять на базе каких источников сформулированы качества требований. Я в своей работе пользуюсь альтернативной моделью на базе "Руководства по написанию требований" от INCOSE.
@@alexanderluchkov990 Спасибо за вопрос. Для начала отмечу, что представленный список был составлен и многократно проверен на практике и для решения практических задач. В связи с этим, к счастью или к сожалению, не фиксировали всех источников (как обычно все делалось "с колес"). Однако, если заглянуть в международные стандарты (например, IEEE Recommended Practice for Software Requirements Specifications 830-1998), там можно найти практически идентичный список тому, про который говорю в ролике, также во многих источниках на просторах интернета гуляет похожая классификация. Также ни в коем случае не настаиваю на том, что это единственно верный подход :) С деятельностью и результатами INCOSE знаком (но не могу сказать, что на экспертном уровне). Насколько я понимаю, руководство, про которое Вы говорите, находится в ограниченном доступе, поэтому, в момент создания своего списка не мог его использовать (если ошибаюсь, то поделитесь ссылкой, пожалуйста). Также, если хотите можем в рамках отдельной активности обсудить два подхода, и, возможно, получится как-то оформить потом результаты этого сравнения (в fb вам заявку отправил) :)
@@digitletter если я правильно понял, то данное видео - это обобщение некоторого личного опыта. Полезная штука в целом. Почему вопрос про источники возник вообще, потому что явным образом смешаны атрибуты формулировки требования как сущности и спецификации требований как сущности (порядок требований в общем перечне по атрибуту "приоритетность"/"важность"). У меня на данный момент идёт похожая деятельность и там выделяем как критерии качества отдельного требования, так и критерии качества набора требований, спецификации требований, документа с требованиями (тех. задание например). И соответственно этому жизненные циклы для каждой из рассмотренных сущностей формируются в зависимости от обстоятельств. Про IEEE 830 в курсе. Есть его замена посвежее, ISO 29148. Помимо прочего хорошим источником считаю такой документ как ARP 4754. Дополнительно следует рассматривать правила русского языка в требованиях - есть так же проект стандарта Упрощённого технического русского языка. INCOSE Guide for writing requirements является относительно закрытым документом. Стоит 25 долларей США + НДС. Рекомендую приобрести например на организацию. Ссылку дать не могу к сожалению. Что хорошо отмечено в рассказе, что требование становится требованием тогда и только тогда, когда оно является "Согласованным между сторонами обязательством". Что хотелось бы видеть ещё, это практики работы с требованиями в зависимости от типа проекта в контексте типовых ситуаций в нашей стране. Благодарю за ответ. С уважением, Лучков А.Г.
Видео полезное, легко воспринимается. Хотелось бы больше реальных примеров. Ещё одну тему, которую можно было бы осветить подробнее - это управление изменениями требований с приведением реальных примеров из проектов. Спасибо.
Спасибо за видео! Читала Вигерса, был вынужденный перерыв и данный материал помог все быстро вспомнить и структурировать в голове (по крайней мере те главы, которых данное видео касается)
![ILLSLICK - WINTER IS COMING [Official Video]](http://i.ytimg.com/vi/dwTMeM1zIhQ/mqdefault.jpg)
Напишите в комментариях, интересна ли данная тема? Стоит ли записать еще серию роликов с разбором примеров по описанным критериям?
Хотелось бы понять на базе каких источников сформулированы качества требований. Я в своей работе пользуюсь альтернативной моделью на базе "Руководства по написанию требований" от INCOSE.
@@alexanderluchkov990 Спасибо за вопрос. Для начала отмечу, что представленный список был составлен и многократно проверен на практике и для решения практических задач. В связи с этим, к счастью или к сожалению, не фиксировали всех источников (как обычно все делалось "с колес"). Однако, если заглянуть в международные стандарты (например, IEEE Recommended Practice for
Software Requirements Specifications 830-1998), там можно найти практически идентичный список тому, про который говорю в ролике, также во многих источниках на просторах интернета гуляет похожая классификация. Также ни в коем случае не настаиваю на том, что это единственно верный подход :) С деятельностью и результатами INCOSE знаком (но не могу сказать, что на экспертном уровне). Насколько я понимаю, руководство, про которое Вы говорите, находится в ограниченном доступе, поэтому, в момент создания своего списка не мог его использовать (если ошибаюсь, то поделитесь ссылкой, пожалуйста). Также, если хотите можем в рамках отдельной активности обсудить два подхода, и, возможно, получится как-то оформить потом результаты этого сравнения (в fb вам заявку отправил) :)
@@digitletter если я правильно понял, то данное видео - это обобщение некоторого личного опыта. Полезная штука в целом. Почему вопрос про источники возник вообще, потому что явным образом смешаны атрибуты формулировки требования как сущности и спецификации требований как сущности (порядок требований в общем перечне по атрибуту "приоритетность"/"важность").
У меня на данный момент идёт похожая деятельность и там выделяем как критерии качества отдельного требования, так и критерии качества набора требований, спецификации требований, документа с требованиями (тех. задание например). И соответственно этому жизненные циклы для каждой из рассмотренных сущностей формируются в зависимости от обстоятельств.
Про IEEE 830 в курсе. Есть его замена посвежее, ISO 29148. Помимо прочего хорошим источником считаю такой документ как ARP 4754. Дополнительно следует рассматривать правила русского языка в требованиях - есть так же проект стандарта Упрощённого технического русского языка. INCOSE Guide for writing requirements является относительно закрытым документом. Стоит 25 долларей США + НДС. Рекомендую приобрести например на организацию. Ссылку дать не могу к сожалению.
Что хорошо отмечено в рассказе, что требование становится требованием тогда и только тогда, когда оно является "Согласованным между сторонами обязательством".
Что хотелось бы видеть ещё, это практики работы с требованиями в зависимости от типа проекта в контексте типовых ситуаций в нашей стране.
Благодарю за ответ. С уважением, Лучков А.Г.
Супер! Понятно, последовательно, системно! 👍
Спасибо! Кратко и понятно. Было бы интересно подробнее послушать про трассировку требований. Заранее спасибо!
про трассировку подумаю, как оформить и тоже постараюсь выпустить ролик - спасибо за запрос и отзыв!
Какой классный ролик, полезная, основная информация, без воды. Хорошая подача. спасибо!
Видео полезное, легко воспринимается. Хотелось бы больше реальных примеров. Ещё одну тему, которую можно было бы осветить подробнее - это управление изменениями требований с приведением реальных примеров из проектов. Спасибо.
Спасибо, работа с изменениями требований это отличная тема, и она есть в планах :)
Спасибо за видео! Читала Вигерса, был вынужденный перерыв и данный материал помог все быстро вспомнить и структурировать в голове (по крайней мере те главы, которых данное видео касается)
Спасибо за отзыв :)
Полезное видео, спасибо! Хочется ещё видео с разбором примеров :)
Спасибо, работаем в этом направлении.
Большое спасибо за видео, очень полезное!
Спасибо!)
Очень полезное видео! Спасибо!
Свежее выступление Михаила Максимова - Как стать архитектором, особенно если ты аналитик? th-cam.com/video/WIVsRgSeE0w/w-d-xo.html