Как стать настоящим аналитиком? Часть 2. Выявляем требования

    Доброе время суток, дорогие хабравчане! Данная статья является продолжением топика, и в ней хотелось бы начать обсуждение стадии создания требований. Если вы успешно справитесь с этой стадией процесса, вы получите отличный продукт, счастливых заказчиков и удовлетворенных разработчиков. В противном случае вам грозит непонимание, разочарование и разногласия.

    Стадию создания или разработки требований условно можно разделить на 4 этапа.
    1. Выявление требований (сбор информации).
    2. Анализ требований.
    3. Спецификация (документация) требований.
    4. Проверка требований.

    Не ждите, что все действия по выявлению, анализу, спецификации и проверке требований, вы сможете выполнить последовательно.
    Работая с пользователями, вы будете задавать вопросы, выслушивать ответы и наблюдать за их действиями (выявление требований). Затем вы обработаете полученную информацию, классифицируете по различным категориям и соотнесете потребности клиентов с возможными требованиями к ПО (анализ). Потом вы оформите информацию от клиентов и выработанные требования в виде письменных документов и диаграмм (спецификация), предложите представителям пользователей подтвердить, что написанный вами текст точен и полон, и попросите их исправить возможные ошибки (проверка). Этапы будут выполняться, чередуясь и периодически повторяясь. Этот итерационный процесс и есть процедура создания требований.



    Выявление требований — самый трудный, важный, подверженный ошибкам и требующий интенсивного общения этап разработки ПО.
    Выявление требований – это творческий процесс, и каждый использует свои инструменты для получения результата, т.е. требований. В моем багаже есть такие методы, которые я называю «Классика», т.е. это те приемы, которые срабатывают в 90% случаев. К традиционным методам выявления требований относятся использование интервью и анкет, наблюдение и изучение деловых документов. Это простые и экономичные методы. Надеюсь, опытные хабраюзеры дополнят список своими.

    Разделение пользователей на группы


    Чтобы не упустить из виду потребности отдельных пользователей необходимо:
    1. Постараться классифицировать пользователей по различным характеристикам. Например, по частоте работе с ПО, используемым функциям, уровню привилегий и навыкам работы.
    2. Выбрать активного пользователя в каждом классе пользователей. Это человек будет представлять интересы определенного класса пользователей, и принимать решения от их лица.

    ИМХО: Выбирайте не тех людей, кто болтает много, а тех, кто говорит по существу.

    Работа с пользователями для выяснения требований к продукту


    1. Анкетирование/ Интервьюирование

    Выясните у пользователей, какие задачи им требуется выполнять средствами ПО. Обсудите, как должен клиент взаимодействовать с системой для выполнения каждой такой задачи. Используйте в своей беседе следующие вопросы: Что мешает пользователю успешно выполнить задачу? Как система должна реагировать на различные ошибочные условия? Что произойдет, когда? Вам когда-нибудь требовались?, Где вы получаете?, Почему вы делаете (или не делаете)? и А кто-нибудь когда-либо?
    Правильно сформулированные вопросы заставляют собеседника задуматься, помогают сосредоточиться на конечном результате, заполняют неловкое молчание, подсказывают новый поворот разговора и помогают наладить контакт с собеседником.
    Умение задавать вопросы – это полезная технология, освоение которой может оказать неоценимую поддержку в работе. На просторах интернета много материала по данной теме, не поленитесь ее изучить!
    После каждого интервью документируйте информацию, которая обсуждалась, и попросите участников просмотреть список и внести исправления. Просмотр на ранних стадиях необходим для успешного сбора требований, поскольку только те люди, которые эти требования предоставили, могут судить, правильно ли они зафиксированы.

    2. Наблюдение

    Понаблюдайте за работой пользователя. Не поленитесь потратить на это рабочий день! С помощью данного метода можно выявить неявные требования к системе, которые пользователь не озвучил. Иногда даже выясняется, что для выполнения задач пользователям вовсе и не требуется новое ПО.

    3. Проведение совместных семинаров

    Совместные семинары по выявлению требований, где тесно сотрудничают аналитик и пользователи — отличный способ выявить нужды пользователей и составить наброски документов с требованиями.
    Главное:
    1. Вы должны вести семинар так, чтобы получить необходимый результат.
    2. Продумайте заранее, каким образом организовать взаимодействие наиболее эффективно.
    3. Необходимо вовлечь в процесс всех участников семинара.

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

    Изучение отчетов о проблемах работающих систем или аналогичной системы с целью поиска новых идей


    Для выявления требований, можно использовать информацию от службы поддержки. Изучить отчеты клиентов о проблемах и предложения о расширении функциональности. Так же можно изучить аналогичные системы (системы конкурентов), выявить их сильные и слабые стороны. Это отличные источники для поиска идей, которые можно реализовать в следующих версиях или в новом продукте.

    Повторное использование требований в разных проектах


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

    Как понять, что сбор требований завершен?


    Конкретных признаков, показывающих, что выявление требований завершено, нет. Выявить требования полностью невозможно, однако следующие признаки подскажут вам, что источники сведений уже почти иссякли:
    1. пользователи уже не могут придумать новые варианты использования.
    2. пользователи предлагают новые варианты использования, однако вы уже вывели соответствующие функциональные требования из других вариантов использования.
    3. пользователи описывают проблемы, которые уже обсуждались;
    4. предлагаемые новые функции выходят за рамки проекта;
    5. пользователи предлагают возможности, которые имеет смысл реализовать когда-то позже.

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

    Литература:

    Карл Вигерс «Разработка требований к программному обеспечению»
    Нордавинд
    44,00
    Компания
    Поделиться публикацией

    Комментарии 29

      +1
      Спасибо.

      Жду с нетерпением следующую статью.
        +1
        Прочитайте лучше самого Вигерса :)
          +1
          Руки (ноги?) никак не доходят. Теория это одно, практика другое. Жду практического опыта)
        0
        При уточнении требований, когда у нас уже есть частичная документация мы с этой документацией возвращаемся к пользователям. На практике пользователи редко понимают абстракции, сформулированные требования. Вот варианты использования ближе, ведь это по сути их пошаговые действия. Еще лучший способ это прототип и вариант использования. Прототип не обязательно должен быть написан программистами как часть будущей системы. Это может быть макет или рисунок на бумаге. Правда, чаще всего пользователь начнет обсуждать дизайн. Например такой диалог:
        Пользователь: Это кнопка лучше бы слева смотрелась?
        Аналитик: Почему?
        Ползователь: Ну тогда после нажатия на неё всплывающий тескт не закрывал эту информацию, а мне удобнее видеть и то и другое одновременно.

        Опытный аналитик сразу цепляется за слово «надо» и уже прикидывает: «это атрибут качества или функциональное требование?»
          0
          А нельзя-ли блок-схему привязать к циклу Деминга по управлению качеством:

          — Совершенствование — Планирование — Выполнение — Анализ — image

          На мой взгляд, похоже.
            0
            Почему именно управление качеством? Это классический цикл управления всем — PDCA.
              0
              Данная схема также соответствует функциональной петле Петра Кузьмича Анохина.

              Одно из описаний подхода приведено на сайте http://www.zooton.net/ind1026.html

              Оттуда же — схема реакции человеческого организма:
              Функциональная петля П.К.Анохина

              Так что у этой классики еще и физиологические основы.
                +1
                Чем дальше, тем страшнее схемы))) Цель серии статей Как стать настоящим аналитиком? это помочь разобраться в работе аналитика, поделится опытом, придать ясности неопределенным вопросам. Можете ответить, чем блок схемы, которые вы представили в этом помогут. Заранее спасибо)
                  0
                  В том то и дело, что деятельность аналитика также может быть подвергнута анализу.
                  Мои предложения по анализу человеческой деятельности — в http://integral-community.ru/forum/viewtopic.php?f=8&t=12#p68

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

                  С уважением, Алексей.
              +1
              Ваша блок-схема — это циклически повторяющийся процесс принятия решения. В статье блок-схема представлена для наглядности и показывает этапы создания требований. И если вы заметили там присутствуют обратные связи, т.к. с любого этапа можно вернутся на этап, который был раньше.
                0
                С точки зрения цикла то же можно выполнить пропуском одного или нескольких блоков.
                Зато Дейкстра был бы, наверное, более доволен.
              +2
              Хотелось бы услышать опыт о разрешении конфликтов интересов.
              Имеется ввиду конфликт интересов пользователей (руководство клиента тоже пользователи по сути).
              Прямые саботажи (кому оно надо внедрять что-то новое, еще и «мутить» будут мешать, лучше все буду запутывать) и прочие человеческие факторы?

              Хотелось бы статью на эту тему.

              Ведь банальный подход — слушай того кто выше не пройдет — выше хочет побольше контроля, часто неуместного и т.п.
                +1
                Работая с пользователями, вы будете задавать вопросы, выслушивать ответы и наблюдать за их действиями (выявление требований).

                Чтобы не упустить из виду потребности отдельных пользователей необходимо:

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


                Я правильно понял, что вы предлагаете разрабатывать систему только на основании пользовательских требований? А как же бизнес-требования? Как работа с разными заинтересованными лицами — заказчик, спонсор, владелец системы, покупатель, продавец, внедренец?
                  +2
                  Я не предлагаю разрабатывать систему на основе только пользовательский требований. Я рассматривала требования в общем, т.е. они включают в себя бизнес-требования, пользовательские требования и функциональные требования. В статье описаны общие методы, которые подойдут и для бизнес-требований. Ведь бизнес-требования включают бизнес-цели организации и представление о внешнем виде и функциональности системы. Т.е. чтобы их выявить можно спросить у заинтересованных лиц, например Зачем мы начинаем данный проект? У меня чаще бывало, что сначала собираешь со всех требования, а уж потом разносишь по типам, что это бизнес-требования, пользовательские требования или функциональные.
                    +1
                    Я считаю важным делать акцент, что сначала необходимо получить модель проблем ключевых заинтересованных лиц, а потом уже идти исследовать пользователей.

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

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

                    Совсем другая повестка встречи и содержание.
                  0
                  Рекомендация литературы убийственная — взяли и сходу самую толстую книгу порекомендовали, чтобы убиться ей, наверное :)
                    +2
                    Можете ее не читать))) Есть и другие хорошие книги по анализу, но мне нравится эта)))
                      +2
                      Мне тоже нравится. Но почему бы не порекомендовать более мягкий вход — например, с 60-100 страниц?
                      bagcheck.com/bag/1377

                      Вы знакомы со статьёй Химонина?

                      Зачем создавать такой высокий порог входа? Вам выгодна эта «элитарность» аналитиков? Не каждый, мечтающий стать аналитиком, долетит до середины Вигерса?
                        +1
                        > Не каждый, мечтающий стать аналитиком, долетит до середины Вигерса
                        Именно поэтому и появилась эта серия статей:)
                          0
                          Денис, почему же сразу «высокий порог»? Книги можно и нужно читать системно: не за один подход, так за несколько. По-моему, Вигерс очень чётко всё разложил, чтобы можно было понять основы, прочитав книгу «по диагонали».
                            0
                            «Нужно» — это из идеального мира.
                            В реальном мире 95% требований пишут менеджеры проектов, у которых нет выделенного аналитика, потому что он не рентабелен в их проектах.

                            И вот у менеджера разработка требований — это ~20% всей работы, поэтому ожидать, что он будет читать книжку в 500 страниц — не приходится.

                            Основы можно и нужно понять по более простым и коротким книгам.
                            Зачем тратить время на анализ и выискивание полезного в большом тексте, если можно прочитать короткий?
                              +1
                              Зачем тратить время на анализ и выискивание полезного в большом тексте, если можно прочитать короткий?

                              Как вариант — усваиваемость лучше.
                              Конспекты сделаны для тех, кто уже понял материал, и хочет уточнить себе детали или что-то освежить в памяти.
                              А длинные учебники — чтобы много раз с разных сторон преподнести материал, чтобы ты понял.
                                0
                                Я не против длинных учебников вообще.
                                Я против того, чтобы первый учебник по теме был — длинным учебником.

                                Ну и про усваиваемость при браузинге большого вместо чтения короткого — я не верю.
                                  0
                                  Ну вот простой пример — взял я на хабре пару статей, да и сделал себе из них конспект. Грубо говоря заголовки сохранил + некоторые мысли.
                                  Вопрос: Человечку который не имеет достаточного опыта, но который скорее всего останется на моем месте когда я сбегу с этой работы — какой вариант давать? Ссылку на статьи или мои краткие записи? Нет, всё важное я таки выписал… Но читать дам лучше эти статьи. Со всеми комментариями. Со всеми оборотами автора. Ибо как минимум месяца два у человека есть, чтобы всё переварить, и т.п.
                                  А если мне надо будет БЫСТРО ввести человека в курс дела, то я скажу «Открой папку RTFM, прочитай там всё, и заглядывай туда когда будут вопросы. Остальное уже на шишках выучишь».
                                    0
                                    Усваиваемость это не демонстрирует.

                                    Есть разные задачи, режимы и форматы:
                                    Ознакомление — обзорный материал
                                    Глубокое погружение — исследование
                                    Изучение конкретной методики — методичка
                                    Пересмотр своего опыта — модель процесса, подхода, карты понятий и явлений
                                    Справка — справочник

                                    Я настаиваю на том, кто конкретно Химонин и Леффингуэлл, а также, с мая, Корнипаев, а затем уже Кон и Коберн, будут лучшими вариантом для изучающего тему анализа и требований, чем отвратительно переведённый на русский многостраничный Вигерс.

                                    Вы Вигерса читали?
                                      0
                                      Нет, не читал.
                                      Мои аргументы были против
                                      Я против того, чтобы первый учебник по теме был — длинным учебником.

                                      Я не могу спорить с вопросом отвратительности перевода, если я его не читал.

                                      Вопрос усваиваемости это не столько вопрос размера, сколько концентрации новых знаний.

                                      Если опытный инженер вполне удовлетворится такой записью
                                      Колесо — устройство для уменьшения силы трения при перемещении предметов.
                                      Колесо — круглое. Другая форма как правило неэффективна, но бывают варианты.
                                      Технически колеса это относительно небольшие устройства закрепленные на основном транспортном средстве так, чтобы они могли свободно прокручиваться. Эффект уменьшения силы трения основан на том, что сила трения качения меньше.
                                      Недостатки — сложность конструкции, требует более качественных материалов и обработки
                                      Преимущества — значительное сокращение силы трения и как следствие экономия энергоресурсов.

                                      То неопытному лучше объяснять так:
                                      Для того, чтобы сократить количество рабов необходимых для транспортировки груза необходимо сократить усилие, требуемое для перемещения груза.
                                      Давайте представим себе, что нам нужно переместить сто тысяч огромных камней.
                                      Очевидно, что количество рабов необходимое для перемещения каждого камня зависит от веса камня.
                                      Однако мы не можем уменьшить камень — тогда нам понадобится больше камней, так что выигрыш будет сомнительным.
                                      Давайте подумаем — что мешает камню двигаться?
                                      Оказывается, что это так называемая сила трения.
                                      Да, не удивляйтесь — камень просто трется о дорогу, и это мешает ему двигаться быстрее.
                                      Сила трения зависит от многих факторов — от веса камня, от его размера, от площади контакта с дорогой, от качества дороги, от гладкости камня, и еще от многих факторов.
                                      Еще наши предки заметили, что более гладкий камень легче тянуть, что если поливать дорогу перед камнем водой, то тянуть будет легче, что можно подложить под камень мягкие шкуры, и множество других хитростей.
                                      Однако революционным было открытие, что сила трения качения намного меньше — в самом деле, если толкать бревно так чтобы оно катилось, то это будет сделать намного легче, чем толкать его перпендикулярно. Хотя казалось бы — площадь соприкосновения с дорогой одинакова, вес одинаков и т.п.
                                      О причинах такого удивительного феномена мы узнаем в следующей главе. А сейчас мы научимся этим пользоваться.
                                      Давайте подложим пять-шесть бревен под наш камень. Так толкать камень становится значительно проще.
                                      Однако камень перемещается по бревнам, и их приходится постоянно переставлять с зада на перед.
                                      Как это можно еще улучшить?
                                      Представьте себе, что мы подкладываем под камень не целые бревна, а только короткие куски по краям камня.
                                      Катить такую конструкцию ничуть не тяжелее чем предыдущую, но она чертовски нестабильна, чурки все время норовят выкатится…
                                      Давайте соединим противоположные чурки длинной палкой.
                                      А эти палки соединим между собой другими палками, но таким образом, чтобы палки соединяющие чурки могли свободно крутиться в местах соединения.
                                      Наша конструкция стала чуть менее быстрой, за счет силы трения в местах соединения, зато намного более стабильной. И как бонус — мы можем закрепить на поперечных палках настил, который не будет крутится, а значит
                                      положив на него наш камень, нам не придется что-то перекладывать и т.п.
                                      Так вот, дорогие читатели — те чурки, на которых катится наша конструкция называются колесами.
                                        0
                                        Это вы демонстрируете различные стили изложения.
                                        Второй стиль, более пространный и наглядный — это не то, чем отличается Вигерс.

                                        Мой опыт показывает, что в среднем, при одинаковом стиле изложения, вероятность прочтения книги обратно пропорциональна квадрату от её объёма.
                                          0
                                          Кстати, ваши комментарии хорошо иллюстрируют мои тезисы — анализом интересуетесь, вопросы по теме задаёте узкие, предметные (про конфликт требований ЗЛ), т.е. в теме не новичок, а Вигерса не читали.
                                            0
                                            Может, устарел уже маэстро? ;-) Посмотрим, что будет после выхода очередного издания его толмуда, над которым он сейчас работает в соавторстве. (Разумеется, переведённый на русский вариант если и появится появится, то через много лет.)

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

                      Самое читаемое