- PVSM.RU - https://www.pvsm.ru -

Анализ требований

image

Анализ требований — часть процесса разработки программного обеспечения, включающая в себя сбор требований к программному обеспечению (ПО), их систематизацию, выявление взаимосвязей, а также документирование.
https://ru.wikipedia.org/wiki/анализ_требований [1]

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

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

На мой взгляд, для того чтобы избежать этой ситуации, надо всего-лишь посмотреть на процесс под другим углом…

Основная проблема сбора требований, на мой взгляд, в формулировках, которые использованы в статьях Википедии и профессиональной литературе.

Requirement is a singular documented physical and functional need that a particular design, product or process must be able to perform.
https://en.wikipedia.org/wiki/Requirement [2]

Требования к программному обеспечению — совокупность утверждений относительно атрибутов, свойств или качеств программной системы, подлежащей реализации.
https://ru.wikipedia.org/wiki/Требования_к_программному_обеспечению [3]

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

Далее они общаются с пользователями и заказчиками, составляют массив запутанной, противоречивой и неконсистентной информации, наполняют сарказмом Интернет и проектируют систему, отталкиваясь от своего субъективного понимания задачи.

Результаты подобного подхода в полной мере проявляются только на этапе приемки или запуска продукта, в форме фразы, которую минимум однажды слышал каждый из нас — “Мы хотели совсем не это, вы плохо выполнили свою работу”.

В случае waterfall процессов риски отчасти закрываются тем, что Заказчик согласовывает проектную документацию и мы можем сказать “Сами виноваты!”, но что это меняет, по сути?

На мой взгляд в определениях требований упущена ключевая деталь:

Требование это не “a need that a particular product must be able to perform”, требование это “an expectation of particular person, that a particular product should be able to perform”.

В новом контексте появляется множество идей по изменению процесса анализа требований, лично я считаю важнейшими следующий три:

Во-первых: Требование — это не функция системы, а описание задачи или проблемы, которую хочет решить конкретный человек.

Попытка вместе с заказчиком проектировать сценарии работы системы с большой вероятностью приведет к некачественному результату. Лучший способ понять требование, сделать все наоборот — Проявить эмпатию, погрузиться в терминологию, задачи и процессы заказчика. Именно после этого появится возможность применить к этому свой опыт и знания, и предложить Заказчику консистентное и эффективное решение.

Во-вторых: Так как требования это желания нескольких людей, то анализ требований начинается с выявления лиц, чьи желания система должна учитывать.

Выявление всех заинтересованных лиц и независимый опрос каждого, это работа, которую чаще всего игнорируют, причем сопротивление оказывают как раз заказчики и спонсоры проекта, из-за непонимания необходимости данной работы.

Безусловно, нужно поддерживать баланс между трудоемкостью и качеством результатов, но причиной большинства провалов стартапов и внедрений корпоративных систем, является именно то, что мнение заказчиков и создателей о том, что надо пользователям не совпало с реальностью.

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

Требования — это ожидания. Ожидания не фиксируют, ожиданиями управляют.

Недостаточно собрать и подписать требования, надо их “продать” всем заинтересованным лицам, таким образом, чтобы они помнили о том — что они хотят, иначе в процессе всего проекта придется бороться с хаотичными изменениями функциональности и внезапными поворотами.

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

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

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

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

PS: Все написанное является моим частным мнением, которое я готов обсуждать в комментариях.

Автор: Александр Мокрышев

Источник [4]


Сайт-источник PVSM.RU: https://www.pvsm.ru

Путь до страницы источника: https://www.pvsm.ru/interfejsy/266655

Ссылки в тексте:

[1] https://ru.wikipedia.org/wiki/анализ_требований: https://ru.wikipedia.org/wiki/%D0%90%D0%BD%D0%B0%D0%BB%D0%B8%D0%B7_%D1%82%D1%80%D0%B5%D0%B1%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B9

[2] https://en.wikipedia.org/wiki/Requirement: https://en.wikipedia.org/wiki/Requirement

[3] https://ru.wikipedia.org/wiki/Требования_к_программному_обеспечению: https://ru.wikipedia.org/wiki/%D0%A2%D1%80%D0%B5%D0%B1%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D1%8F_%D0%BA_%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%BD%D0%BE%D0%BC%D1%83_%D0%BE%D0%B1%D0%B5%D1%81%D0%BF%D0%B5%D1%87%D0%B5%D0%BD%D0%B8%D1%8E

[4] Источник: https://habrahabr.ru/post/340956/?utm_source=habrahabr&utm_medium=rss&utm_campaign=best