Главная » Аналитика » Сбор требований. Общее описание. Методы
Ноя
25

В этой статье речь пойдет о принципах и способах сбора требований от Заказчика.

Да, бесспорно, это базовая тема, возможно, многим это покажется и не интересно, мол, и так знаем..  

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

Итак, на какие этапы можно разбить процесс сбора требований?!

По классике жанра, выделим этапы:

  • Планирование;
  • Сбор информации;
  • Обработка и обобщение информации;
  • Разработка документации.

ЭТАП «ПЛАНИРОВАНИЕ»

На входе: Чаще всего, вместе с постановкой задачи аналитику предоставляется «вводная по проекту».

На этапе планирования, необходимо выделить ключевые моменты, которые  нужно для себя четко понимать:

  • Для кого необходима проектируемая система;
  • Цель проектируемой системы (глобально);
  • Кто Заказчик;
  • Вводное погружение в терминологию Заказчика;
  • Представители категорий пользователей;
  • Бизнес – потребности пользователей;
  • Возможные требования к создаваемой системе;
  • Аналогичные программные продукты.

Немного расшифруем данные понятия..

Основные вопросы Описание
Для кого необходима проектируемая система

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

Цель проектируемой системы  (глобально)

Определяется основная цель проектируемой задачи (для чего все это? ! для каких целей внедряем?! / анализируем?!)

Кто Заказчик

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

Вводное погружение в терминологию Заказчика

Для того, чтобы понимать Заказчика, нужно научиться его понимать (по предметной области заказчика  нужно посмотреть существующую нормативную базу, ГОСТы и т.п.) Иными словами, погружаемся в предметную область.

Представители категорий пользователей

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

Бизнес – потребности пользователей

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

Возможные требования к создаваемой системе

В случае, если обследование осуществляется по конкретной системе, то лучше заранее зафиксировать возможные требования по каждому модулю системы. Если без привязки к системе, то предварительно по конкретным задачам нужно сделать перечень возможных «требований-хотелок».

Аналогичные программные продукты

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

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


ЭТАП «СБОР ТРЕБОВАНИЙ»

На входе: Цель проекта, общие задачи проекта (покрываемые бизнес-функции), перечень категорий пользователей, перечень предварительных вопросов, общий план сбора требований и подготовленный аналитик.

Сбор требований может осуществляться разными способами:

  • Интервью;
  • Анкетирование;
  • Наблюдение;
  • Прототипирование;
  • Изучение документов;
  • Совещания.

Немного о способах по сбору требований..

Способ сбора требований Описание Рекомендации
Интервью Наиболее распространенная форма обследования.  Эффективность данного способа зависит в основном от степени подготовленности аналитика.Позволяет установить контакт с Заказчиком.
  • Иметь с собой шпоргалку с вопросами
  • Делать акцент на вопросах «что делаете», а не что «хотите»
  • Какие сейчас есть проблемы и как сейчас решаются?
  • Какие претензии к старой системе?
  • Выяснить входную и выходную информацию
  • Придерживаться позитивного настроя при интервьюировании
  • Бесконечно мило улыбаться =))

 

Анкетирование Способ наиболее распространен, когда нужно опросить большое количество пользователей.Подходит для несложных формальных вопросов, например, для выяснения наличия каких-либо документов, скажем, в филиалах, а также в принципе для обследования удаленных пользователей.Для выяснения сложных и проблемных вопросов этот способ, к сожалению,  не подходит.
  • Нужно понимать, что анкетирование не позволит все выяснить «по максимуму»

 

  • Очень важно правильно сформулировать вопросы в анкетах, т.к. неправильно сформулированные вопросы могут свести весь сбор требований  к нулю (например, если формулировки будут не однозначными, и каждый филиал будет подразумевать под ними «свое понятие», то все полученные в результате обследования анкеты  для нас не смогут представлять ценность, т.к. не будет понятно- кто и что имел ввиду).

 

Наблюдение

Когда не совсем понятно, о чем говорит пользователь, самое лучшее правило «Лучше один раз увидеть, чем сто раз услышать». Способ «Наблюдения» состоит в том, что вы просто садитесь рядом с пользователем и смотрите где и как он работает. При этом можно спрашивать примеры необходимых вам документов, отчетов и д.р. Также этот способ хорош, например, для выяснения как должны формироваться данные в отчете (для систем, которые мы не разрабатывали, но дорабатываем).

  • Заранее нужно выделить время на совместную работу (по времени  не самый быстрый способ сбора данных)
  • Придерживаться позитивного настроя при обсуждении
  • Бесконечно мило улыбаться =))
Прототипирование

Прототипирование используется для демонстрации возможностей системы, для того чтобы подтвердить Заказчику, что да, мы можем это сделать.. Обычно, под этим понимают демонстрацию/установку демо-версии системы или реализацию кусочка проектируемой системы (опять же для демонстрации мини функционала Заказчику). В плане сбора требований, у меня немного другой подход. Прототипирование, на мой взгляд, это как раз, когда мы оцениваем какие на рынке есть аналогичные системы, какие в основном функции поддерживают,  и на базе этой информации договариваемся по средствам Интервью о том как будет работать система. Также сюда подходят случаи, когда у нас система реализована на «толстом клиенте», а Заказчик говорит «хочу такое же, только web-решение».

  • В классическом понимании «Прототипирования» мы, аналитики, здесь практически не участвуем, в основном все делают технические специалисты (архитекторы и программисты)
  • В случае, если мы все же нужны, то с нас «копирование функционала» в текстовой интерпретации..
Изучение документов

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

 
Совещания Совещания – это чуть расширенная версия Интервьюирования. При интервьюировании рассматриваются в основном случаи, когда мы опрашиваем одного-двух пользователей. При совещании, мы в основном слушаем и записываем, занимая более пассивную позицию.
  • Лучше возьмите с собой диктофон (естественно, включать его можно только с разрешением Заказчика)
  • Старайтесь ничего не упустить и все записывайте
  • В случае, если есть вопросы, которые вы в корни не понимаете, лучше уточните сразу на совещании



ЭТАП «ОБРАБОТКА И ОБОБЩЕНИЕ ИНФОРМАЦИИ»

На входе: наши драфты по собранной информации, предоставленные Заказчиком бланки, отчеты и другие документы, нормативно-регламентная база, анкеты и т.п.

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

А ведь именно этот документ является нашей страховкой от высказываний Заказчика «я этого не говорил», «вы все придумали» и т.п.

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

Даже, если в вашей компании не принято подписывать такие документы, то рекомендую отправить протокол по электронной почте и запросить возможные замечания!

Как показала практика, именно при согласовании протокола очень часто выясняются дополнительные детали, которые были упущены в результате интервью!

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

Общая структура протокола встречи:

  • Состав участников;
  • Обсуждаемые вопросы;
  • Предпринимаемые действия;
  • Не решенные вопросы;
  • Запрошенные данные (сроки предоставления, ответственные).

При других способах сбора данных оформляется отчет об обследовании или аналогичные документы.

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

 

На выходе: протокол встречи, отчет об обследовании (прочие документы)


ЭТАП «РАЗРАБОТКА ДОКУМЕНТАЦИИ»

На входе протокол встречи, отчет об обследовании (прочие документы)

На этом этапе осуществляется разработка наших основных документов: ТЗ, спецификаций и др.

 

На выходе:  документы, необходимые для разработки/доработки системы.

 

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

 

Какие могут быть дополнительные вопросы?!

Элементарно – хотя бы выясните у базистов/программистов/ или просто у  пользователей тех же филиалов, насколько функционал, на который к вам пришел запрос на доработку, используется другими пользователями! Бывает, что порой даже тот функционал, который давно уже и не должен быть использован, используется представителями филиалов!

И каждая, даже мелкая доработка, может вызвать целое цунами негодований!

 

Если у Вас есть дополнительные рекомендации по сбору требований, будем рады!

 

————

Автор: Рожкова Елена
Источники информации:
• Карл Вигерс «Разработка требований к программному обеспечению»
• Дин Леффингуэлл, Дон Уидриг «Принципы работы с требованиями к программному обеспечению»

Дорогие читатели, если Вы нашли ошибку в тексте, пожалуйста, сообщите мне об этом, выделив ошибку и нажав комбинацию Shift + Enter или же нажмите сюда, чтобы сообщить нам.

GD Star Rating
loading...
Сбор требований. Общее описание. Методы, 4.7 out of 5 based on 3 ratings

Поделиться в соц. сетях

Опубликовать в Google Plus
Опубликовать в LiveJournal
Опубликовать в Мой Мир
Опубликовать в Одноклассники

Один комментарий к статье “Сбор требований. Общее описание. Методы”

  1. Декабрь 16th, 2010 at 11:52 | #1

    Добрый день!
    Все статьи на сайте доступны на просмотр, возможно, Вы пытаетесь зайти на наш сайт в запрещенную область..
    Если ошибка повторится при попытке просмотра Статей или Библиотеки, напишите, пожалуйста, подробный путь, по которому вы пытаетесь обратиться к ресурсу (и к какому именно ресурсу), чтобы мы могли идентифицировать возможные проблемы.
    Чтобы отправить нам личное сообщение, Вы всегда можете написать нам в разделе “Контакты” или в разделе “Гостевая книга”, что находится в меню, справа.

Добавить ответ