В этой статье речь пойдет о принципах и способах сбора требований от Заказчика.
Да, бесспорно, это базовая тема, возможно, многим это покажется и не интересно, мол, и так знаем..
Но, как показала практика, многие в процессе работы даже не задумываются об используемых методах сбора требований, порой упуская дополнительную возможность для получения новой полезной информации, на базе которой мы и разрабатываем наши документы!
Итак, на какие этапы можно разбить процесс сбора требований?!
По классике жанра, выделим этапы:
- Планирование;
- Сбор информации;
- Обработка и обобщение информации;
- Разработка документации.
ЭТАП «ПЛАНИРОВАНИЕ»
На входе: Чаще всего, вместе с постановкой задачи аналитику предоставляется «вводная по проекту».
На этапе планирования, необходимо выделить ключевые моменты, которые нужно для себя четко понимать:
- Для кого необходима проектируемая система;
- Цель проектируемой системы (глобально);
- Кто Заказчик;
- Вводное погружение в терминологию Заказчика;
- Представители категорий пользователей;
- Бизнес – потребности пользователей;
- Возможные требования к создаваемой системе;
- Аналогичные программные продукты.
Немного расшифруем данные понятия..
| Основные вопросы | Описание |
| Для кого необходима проектируемая система |
На текущем этапе пытаемся определить, для кого будет полезна наша проектируемая система (для руководителей, для партнеров, для инвесторов, для сотрудников компании и т.д.)Как следствие, на базе этой информации мы сможем выявить категории пользователей, которых нужно будет в дальнейшем опросить.
|
| Цель проектируемой системы (глобально) |
Определяется основная цель проектируемой задачи (для чего все это? ! для каких целей внедряем?! / анализируем?!)
|
| Кто Заказчик |
Осуществляем сбор общей информации о Заказчике (что за фирма, чем занимается, общими мазками накидываем функциональную структуру самой компании, по возможности формируем организационную структуру компании)
|
| Вводное погружение в терминологию Заказчика |
Для того, чтобы понимать Заказчика, нужно научиться его понимать (по предметной области заказчика нужно посмотреть существующую нормативную базу, ГОСТы и т.п.) Иными словами, погружаемся в предметную область.
|
| Представители категорий пользователей |
Четко выделяем перечень категорий пользователей, которых нужно будет опросить.
|
| Бизнес – потребности пользователей |
Определяем бизнес потребности пользователей в рамках нашей проектируемой системы
|
| Возможные требования к создаваемой системе |
В случае, если обследование осуществляется по конкретной системе, то лучше заранее зафиксировать возможные требования по каждому модулю системы. Если без привязки к системе, то предварительно по конкретным задачам нужно сделать перечень возможных «требований-хотелок».
|
| Аналогичные программные продукты |
Если вы внедряете систему впервые и у вас нет наработок, которые можно использовать для того чтобы зафиксировать возможные требования к создаваемой системе, то попробуйте посмотреть в интернете существующие аналогичные решения и выделите модули/функциональные блоки, которые могут быть затронуты в рамках вашей системы (по принципу прототипирования).
|
На выходе: В результате планирования формируется предварительный перечень категорий пользователей и перечень вопросов к пользователям. Желательно иметь организационную структуру компании, чтобы никого и нигде не забыть. Также на этом этапе формируется общий план осуществления сбора требований.
ЭТАП «СБОР ТРЕБОВАНИЙ»
На входе: Цель проекта, общие задачи проекта (покрываемые бизнес-функции), перечень категорий пользователей, перечень предварительных вопросов, общий план сбора требований и подготовленный аналитик.
Сбор требований может осуществляться разными способами:
- Интервью;
- Анкетирование;
- Наблюдение;
- Прототипирование;
- Изучение документов;
- Совещания.
Немного о способах по сбору требований..
| Способ сбора требований | Описание | Рекомендации |
| Интервью | Наиболее распространенная форма обследования. Эффективность данного способа зависит в основном от степени подготовленности аналитика.Позволяет установить контакт с Заказчиком. |
|
| Анкетирование | Способ наиболее распространен, когда нужно опросить большое количество пользователей.Подходит для несложных формальных вопросов, например, для выяснения наличия каких-либо документов, скажем, в филиалах, а также в принципе для обследования удаленных пользователей.Для выяснения сложных и проблемных вопросов этот способ, к сожалению, не подходит. |
|
| Наблюдение |
Когда не совсем понятно, о чем говорит пользователь, самое лучшее правило «Лучше один раз увидеть, чем сто раз услышать». Способ «Наблюдения» состоит в том, что вы просто садитесь рядом с пользователем и смотрите где и как он работает. При этом можно спрашивать примеры необходимых вам документов, отчетов и д.р. Также этот способ хорош, например, для выяснения как должны формироваться данные в отчете (для систем, которые мы не разрабатывали, но дорабатываем). |
|
| Прототипирование |
Прототипирование используется для демонстрации возможностей системы, для того чтобы подтвердить Заказчику, что да, мы можем это сделать.. Обычно, под этим понимают демонстрацию/установку демо-версии системы или реализацию кусочка проектируемой системы (опять же для демонстрации мини функционала Заказчику). В плане сбора требований, у меня немного другой подход. Прототипирование, на мой взгляд, это как раз, когда мы оцениваем какие на рынке есть аналогичные системы, какие в основном функции поддерживают, и на базе этой информации договариваемся по средствам Интервью о том как будет работать система. Также сюда подходят случаи, когда у нас система реализована на «толстом клиенте», а Заказчик говорит «хочу такое же, только web-решение».
|
|
| Изучение документов |
В рамках способа сбора требований осуществляется изучение всей возможной нормативной базы и других документов, и на базе которых мы и проектируем функционал системы
|
|
| Совещания | Совещания – это чуть расширенная версия Интервьюирования. При интервьюировании рассматриваются в основном случаи, когда мы опрашиваем одного-двух пользователей. При совещании, мы в основном слушаем и записываем, занимая более пассивную позицию. |
|
ЭТАП «ОБРАБОТКА И ОБОБЩЕНИЕ ИНФОРМАЦИИ»
На входе: наши драфты по собранной информации, предоставленные Заказчиком бланки, отчеты и другие документы, нормативно-регламентная база, анкеты и т.п.
При интервьюировании Заказчика, проведении совещаний обязательно формируется протокол встречи! Это неотъемлемый документ, про который, к сожалению, часто забывают..
А ведь именно этот документ является нашей страховкой от высказываний Заказчика «я этого не говорил», «вы все придумали» и т.п.
После составления протокола, документ подписывается обеими сторонами и является стартовой точкой для написания дальнейших документов (ТЗ, спецификации и д.р.)
Даже, если в вашей компании не принято подписывать такие документы, то рекомендую отправить протокол по электронной почте и запросить возможные замечания!
Как показала практика, именно при согласовании протокола очень часто выясняются дополнительные детали, которые были упущены в результате интервью!
А что-нибудь да обязательно могли пропустить, т.к. все предусмотреть невозможно!
Общая структура протокола встречи:
- Состав участников;
- Обсуждаемые вопросы;
- Предпринимаемые действия;
- Нерешенные вопросы;
- Запрошенные данные (сроки предоставления, ответственные).
При других способах сбора данных оформляется отчет об обследовании или аналогичные документы.
При формировании требований к разработке/доработки системы, желательно выделить приоритеты выполнения задач (с учетом пожеланий руководителей, пользователей и участников вашей проектной команды).
На выходе: протокол встречи, отчет об обследовании (прочие документы)
ЭТАП «РАЗРАБОТКА ДОКУМЕНТАЦИИ»
На входе: протокол встречи, отчет об обследовании (прочие документы)
На этом этапе осуществляется разработка наших основных документов: ТЗ, спецификаций и др.
На выходе: документы, необходимые для разработки/доработки системы.
Еще один совет, если вы занимаетесь поддержкой уже давно существующей системы и вам пришла письменная заявка на доработку системы, скажем из головного офиса (а в компании предусмотрена разветвленная филиальная сеть), то в таком случае не проектируйте никаких доработок до выяснения дополнительных вопросов.
Какие могут быть дополнительные вопросы?!
Элементарно – хотя бы выясните у базистов/программистов/ или просто у пользователей тех же филиалов, насколько функционал, на который к вам пришел запрос на доработку, используется другими пользователями! Бывает, что порой даже тот функционал, который давно уже и не должен быть использован, используется представителями филиалов!
И каждая, даже мелкая доработка, может вызвать целое цунами негодований!
Если у Вас есть дополнительные рекомендации по сбору требований, будем рады!
————
Автор: Рожкова Елена
Источники информации:
• Карл Вигерс «Разработка требований к программному обеспечению»
• Дин Леффингуэлл, Дон Уидриг «Принципы работы с требованиями к программному обеспечению»
loading...
Рожкова Елена
Ведущий специалист
Проектирование и описание бизнес процессов, сайтов, порталов и систем электронного документооборота
Загрузка ...
Добрый день!
Все статьи на сайте доступны на просмотр, возможно, Вы пытаетесь зайти на наш сайт в запрещенную область..
Если ошибка повторится при попытке просмотра Статей или Библиотеки, напишите, пожалуйста, подробный путь, по которому вы пытаетесь обратиться к ресурсу (и к какому именно ресурсу), чтобы мы могли идентифицировать возможные проблемы.
Чтобы отправить нам личное сообщение, Вы всегда можете написать нам в разделе “Контакты” или в разделе “Гостевая книга”, что находится в меню, справа.