Сбор требований. Анализ методов сбора требований для разработки по
 Скачать 25.55 Kb.
|
|
Анализ методов сбора требований для разработки ПО Сбор требований является неотъемлемой частью должностных обязанностей любого бизнес-аналитика. Важно понимать, что от полноты и качества проработки требований многое зависит. Перед непосредственным выявлением функциональных требований к системе, необходимо ответить на главный вопрос "Зачем?".  Как показано на графике выше, область решений, для достижения цели Заказчика, уменьшается с ростом требований. Зачастую, многие проблемы возможно решить без разработки ПО, административными и регуляторными механизмами. Когда решение без разработки ПО не подходит для достижения цели, тогда и нужно извлекать функциональные требования к системе. Можно выделить 4 основных источника требований: Люди; Документы; Системы; Новые технологии; Чаще всего основным источником требований являются люди, рассмотренные ниже способы относятся именно к работе с коллегами из бизнеса. В данной статье будет затронуто 3 наиболее распространенных способа сбора требований. 1. Интервью. Несомненно, самый распространенный вариант. При организации личной встречи следует соблюсти множество условий и нюансов. Во-первых, требуется заранее подготовить план переговоров. Ключевые моменты, которые в обязательном порядке нужно обсудить. Собеседник не должен думать, что вы в пустую тратите его время. Во-вторых, особое внимание нужно обратить на комфорт. Удобное время, место. При проведении интервью нужно продумать и постараться минимизировать раздражающие факторы (Свет солнца в глаза собеседнику, комфортная температура в переговорной и т.д.). В-третьих, используйте бумагу и ручку для записей основных тезисов и ответов на вопросы (не ноутбук и не планшет). Бумага и ручка это естественные инструменты, к которым все привыкли. Тем более, многие даже любят приятный шелест бумажных листов. После проведения интервью, постарайтесь как можно раньше прислать протокол с указанием основных обсуждаемых моментов и принятых решений. 2. Наблюдение за работой людей. Данный способ применяется, когда представители Заказчика не могут внятно объяснить как они работают. Тут у Аналитика есть, как минимум, три варианта действий. Вариант первый. Можно попросить прийти на рабочее место собеседника, где он расскажет как устроена его работа в "боевой" обстановке. Вариант второй. Найти место рядом с рабочим местом человека, наблюдение за которым представляет интерес с точки зрения сбора требований. Вариант третий. Наблюдать за работой человека удаленно, с помощью камер или средств, позволяющих отслеживать деятельность на экране компьютера. Данные варианты имеют весомый недостаток - существенные трудозатраты по сравнению с интервью. Кроме того, работник может вести себя иначе в присутствии Аналитика, и вместо реальной работы демонстрировать знание должностной инструкции. 3. Временное выполнение Аналитиком работы в роли будущего пользователя (Стажировка). Конечно, данный метод больше применим тогда, когда Аналитик работает в штате организации , для которой выполняется работа по автоматизации ее деятельности. Очевидно, при таком методе происходит максимальное погружение в предметную область. Основной недостаток же данного метода - очень большие трудозатраты. Однако, есть и существенный риск - различия в образовательном и культурном уровне аналитика и пользователей. Это приводит к тому, что Аналитик начинает выполнять работу не так, как это делают будущие пользователи системы. Следовательно, есть вероятность ошибочного определения требований. Итог. Работа с требованиями - трудная часть функционала Аналитика. Это можно сравнить извлечением руды из недр земли (как сравнил когда-то Карл Вигерс). И не следует забывать про управление ожиданиями Заказчика. |