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

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

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

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

    Основная проблема сбора требований, на мой взгляд, в формулировках, которые использованы в статьях Википедии и профессиональной литературе.
    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

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

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

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

    В случае 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: Все написанное является моим частным мнением, которое я готов обсуждать в комментариях.
    • +7
    • 17.1k
    • 9
    Share post
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More
    Ads

    Comments 9

      +1
      В данном случае много зависит от опыта заказчика( ведь если у него не было опыта заказа какого либо ПО, то это вообще предмет отдельной статьи), его масштаба (малый бизнес, средний или крупный) и опытности тех кто его задачи будет решать. Самый простой пример, клиент говорит, хочу акцию, вопрос она нужна одна или их будет много? ну пока одну, через 2 недели он хочет еще 1, через месяц их стало 7, текущая реализация не могла выполнить эти требования без снижения производительности. А основная проблема была в том, что заказчик не знал своих требований изначально и лучшим решением было поставить в условия предоплаты, оплаты по часам, разбивать работу на этапы и в случае если ожидания и луны не сошлись то все переделывается за счет заказчика ( за исключением реальных багов) и все становится на свои места и думать начинают и требования адекватные появляются после 2-3 переделок. Т.к дешевле потерять клиента, чем потом переделывать клиентскую дурость в течении N (часов, дней, месяцев) за копейки из-за юридических граблей.
        +2
        Требование — это не функция системы, а описание задачи или проблемы, которую хочет решить конкретный человек.

        Вот мне лично эта фраза прям понравилась. Мне кажется, что написать требования и не написать юзкейсы — зря потратить время. Юзкейсы обязательно надо показать заказчику, чтобы он прослезился и сказал: «Да, именно так я и хочу чтобы оно работало».
          0
          Не вижу противоречия:) Просто use cases должен писать менеджер по продукту или аналитик, желательно сразу с wire frames или дизайн-макетами, а уже потом показывать Заказчику. Опять же я не встречал Заказчиков, которые могли качественно проверить use case, не видя макетов экранов.
            0
            Я имею ввиду, что юзкейсы (с макетами или хотябы без них) очень сильно помогают утрясти собственно сами требования. Без низ риск накосячить гораздо выше. Можно сказать, они как раз и помогают «продать» требования заказчику, так как показывают ему, как будет работать еще не разработанный продукт.
              0
              Ну да, тоже согласен:) Что не отменяет необходимости иметь список того «Зачем» нужна система, а не только того «Как она должна работать».
                0
                А, Вы наверное подумали, что я предлагаю от требований отказаться? Не-не-не, требования — это мастхэв номер 1, и спорить даже не буду. :) Нет требований — нет проекта.
            0
            В семантике юзкейсов существуют «абстрактные юзкейсы» с взаимосвязями типа «реализация», которые именно что соответствуют основным «бизнес/маркетинг» задачам, для которых обозначены конкретные юзкесы, которые реализуются уже в сценариях.

            На верхнем уровне такой иерархи можно поместить абстрактный юзкейс типа «общение пользователей» или «рассказать о себе» с реализациями типа «директ сообщения», «заполнение профиля», «комментарии к профилю». И всё это на одной схеме.
            0

            Очень интересный и свежий взгляд на данную тему. Обязательно постараюсь применить на проекте!)

              0
              Спасибо:)

            Only users with full accounts can post comments. Log in, please.