IT-Project Management

IT-PM: Персональный блог об управлении IT-проектами

Требования — это главное и основное. Часть 1: Сбор требований

leave a comment »

О том какую роль играют требования в процессе разработки написано очень много. Но раз уж я решил затронуть эту тему, придется и мне присоединится и добавить кое-что от себя.

В любом проекте, если речь не идет о чем-нибудь очень простом, фигурируют такие документы как техническое задание (ТЗ), технические условия (ТУ), требования к изделию и т.д. От названия документа и формата изложения смысл содержимого не меняется — все эти документы содержат требования к разрабатываемому продукту. Невыполнение этих требований может привести к самым разным последствиям. Самый удачный вариант — заказчик просто не заметит отсутствие тех или иных свойств изделия. Самый скверный — откажется платить деньги на основании невыполнения того же пресловутого ТЗ. Это было вступление. Теперь по делу…

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

Источники требований

1. Требования могут быть сформулированы четко и ясно в каком-то документе (те же ТЗ и ТУ). С такими требованиями работать проще всего. Они, как правило, конкретны, четки и исключительно по делу. Иногда такие требования нуждаются в уточнении. К примеру, из требования «Передаваемые по сети данные должны шифроваться» непонятно, шифровать только значимые данные, или и служебные тоже.

2. Требования могут быть высказаны заказчиком в ходе обсуждения проекта. Искусство понять, что конкретно хочет получить заказчик – это тема отдельной статьи. Заказчик в большинстве случаев сам не знает, что конкретно ему нужно. Часто высказывает противоречивые или плохо сформулированные требования. Самое важное, на мой взгляд, стараться говорить с заказчиком на «его языке». Если он не программист не надо пытаться читать ему лекцию на тему «Managed code vs. native code». Может ему вообще неважно, на каком языке будет написан продукт. Углубляться в эту тему здесь я не буду. Замечу лишь, что у заказчика, еще на самых начальных этапах разработки полезно бывает поинтересоваться, насколько критично то, или иное требование. Это поможет спланировать реализацию функций разрабатываемого продукта от важных к менее важным.

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

В общем случае невозможно определить все требования с самого начала. Перечисленные источники – это лишь то, к чему можно обратиться на начальных стадиях разработки. Источником новых требований может стать любой документ (не говоря уже о переменчивых желаниях заказчика). По завершении некоторых задач, полезно просматривать результаты работ на предмет новых требований. К примеру, в том проекте, на котором я сейчас занят, требования собирались из следующих источников: ТЗ, модель доступа, предполагаемая архитектура, обсуждения проекта с заказчиком, use-case`ы, некоторые стандарты и ГОСТы. Больше чем уверен, что позже, с появлением новых результатов, этот список расширится.

Реклама

Written by Артур К.

Февраль 13, 2008 в 22:11

Опубликовано в Опыт управления

Tagged with ,

Добавить комментарий

Заполните поля или щелкните по значку, чтобы оставить свой комментарий:

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход / Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход / Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход / Изменить )

Google+ photo

Для комментария используется ваша учётная запись Google+. Выход / Изменить )

Connecting to %s

%d такие блоггеры, как: