Заметки по работе с требованиями | Давайте разбираться
Вставка
- Опубліковано 28 тра 2024
- Одна из ключевых компетенций бизнес/системного аналитика в ИТ - это управление требованиями к программному обеспечению, информационной системе или цифровому продукту на все этапах жизненного цикла, начиная с выявления и фиксации, заканчивая тестированием и оценкой результатов.
В видео поговорим про фазы и этапы работы с требованиями, критерии "хороших" качественных требований с примерами, полезные приемы и лайфхаки. А еще из ролика вы узнаете почему важно быть доктором, а не фармацевтом.
Тайм-коды:
00:00 Почему важно правильно работать с требованиями?
01:06 - Типы требований (бизнес-требования, требования заинтересованных сторон и пользовательские требования, функциональные, нефункциональные, переходные требования
02:00 - Фазы работы с требованиями
03:06 - Процесс работы с требованиями на проактивной фазе
05:03 - Процесс работы с требованиями на реактивной фазе
06:26 - Критерии «хороших» требований - как писать требования?
06:35 - Полнота
07:38 - Ясность
08:43 - Корректность
09:35 - Согласованность
10:20 - Верифицируемость (тестирование требований)
11:06 - Необходимость и полезность при эксплуатации
11:50 - Осуществимость
12:37 - Трассированность (связанность)
13:58 - Упорядоченность по важности
14:38 - Аналитик: доктор или фармацевт?
15:36 - Полезные советы по работе с требованиями
18:32 - Подведение итога и выгоды от качественно и своевременно проработанных требований.
Статья про методы сбора требований: habr.com/ru/company/simbirsof...
Техника «5 Почему?»: ru.wikipedia.org/wiki/%D0%9F%... - Наука та технологія
Напишите в комментариях, интересна ли данная тема? Стоит ли записать еще серию роликов с разбором примеров по описанным критериям?
Хотелось бы понять на базе каких источников сформулированы качества требований. Я в своей работе пользуюсь альтернативной моделью на базе "Руководства по написанию требований" от 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 долларей США + НДС. Рекомендую приобрести например на организацию. Ссылку дать не могу к сожалению.
Что хорошо отмечено в рассказе, что требование становится требованием тогда и только тогда, когда оно является "Согласованным между сторонами обязательством".
Что хотелось бы видеть ещё, это практики работы с требованиями в зависимости от типа проекта в контексте типовых ситуаций в нашей стране.
Благодарю за ответ. С уважением, Лучков А.Г.
Супер! Понятно, последовательно, системно! 👍
Какой классный ролик, полезная, основная информация, без воды. Хорошая подача. спасибо!
Видео полезное, легко воспринимается. Хотелось бы больше реальных примеров. Ещё одну тему, которую можно было бы осветить подробнее - это управление изменениями требований с приведением реальных примеров из проектов. Спасибо.
Спасибо, работа с изменениями требований это отличная тема, и она есть в планах :)
Полезное видео, спасибо! Хочется ещё видео с разбором примеров :)
Спасибо, работаем в этом направлении.
Очень полезное видео! Спасибо!
Спасибо! Кратко и понятно. Было бы интересно подробнее послушать про трассировку требований. Заранее спасибо!
про трассировку подумаю, как оформить и тоже постараюсь выпустить ролик - спасибо за запрос и отзыв!
Большое спасибо за видео, очень полезное!
Спасибо!)
Спасибо за видео! Читала Вигерса, был вынужденный перерыв и данный материал помог все быстро вспомнить и структурировать в голове (по крайней мере те главы, которых данное видео касается)
Спасибо за отзыв :)
Свежее выступление Михаила Максимова - Как стать архитектором, особенно если ты аналитик? ua-cam.com/video/WIVsRgSeE0w/v-deo.html