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

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

Для большинства крупных проектов, однако, определение наиболее важных финансово-заинтересованных лиц является сложной проблемой. Если, например, заказчик – это государственная организация, которая оплачивает разработку приложения, то разве не являются налогоплательщики «заказчиками», поскольку на самом деле это они платят за приложение? Когда приложение разрабатывается для внутреннего использования в компании, то заказчиком является сама компания. Заказчиком субподрядчика является основной подрядчик, заказчиком коробочного приложения является множество потенциальных покупателей и т.д.

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

Заинтересованные лица – активно участвующие в проекте лица, группы или организации, которых затрагивает полученный результат и которые сами могут влиять на этот результат [4].

Пользователь – юридическое или физическое лицо, применяющее программное средство или участвующее в деятельности, прямо или косвенно зависящей от функционирования данного программного средства [10].

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

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

Опрос (интервью)

Проведение опроса состоит из трех этапов: подготовка опроса, его проведение и определение последующих действий [9, 10].

Подготовка

При подготовке опроса должны быть разработаны вопросы, выбраны опрашиваемые пользователи и спланированы контакты.

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

Обычно имеется несколько заинтересованных в разработке лиц (групп лиц), ценность системы для которых, определяется различными ее характеристиками, например:

· повышение производительности;

· повышение надежности;

· снижение себестоимости;

· легкость и простота использования и т.д.

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

Для определения групп заинтересованных лиц нужно понимать, что их можно классифицировать по различным признакам, например:

· по правам доступа к системе, например администратор и обычный пользователь;

· по частоте использования системы;

· по опыту в предметной области;

· по опыту работы с компьютерными системами и т.д.

Можно выбрать одно или, возможно, два основных заинтересованных лица, опросить их, а затем уже собрать комментарии остальных основных заинтересованных лиц.

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

· объяснить цель встречи, каким образом данный человек попал в перечень участников опроса;

· подчеркнуть, что он является тем человеком, который может дать правильные ответы на вопросы;

· указать продолжительность интервью;

· согласовать способ записи опроса и т.д.

Проведение опроса

Опрос можно провести по телефону, при помощи Internet, но наиболее эффективный способ – это личная встреча, которая позволяет создать правильную атмосферу, обеспечивающую комфорт участников.

Для создания атмосферы доверия и взаимопонимания, которая позволит задавать как общие, так и более глубокие вопросы в [10] рекомендуется:

· демонстрировать искренний интерес относительно вклада данного человека в дело разработки программного обеспечения;

· слушать, т.к. самая лучшая мотивация для опрашиваемого – полное внимание спрашивающего;

· быть откровенным и честным;

· предложить помощь в составлении отчета о проекте и т.д.

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

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

Рекомендуется [10] задавать не только вопросы, непосредственно относящиеся к бизнесу, процессу или программному продукту. Например, некоторые из таких вопросов:

· Может ли эта система причинять какие-либо проблемы?

· Существует ли необходимость решения тех проблем, которые могут быть неочевидными?

· Может ли кто-то еще решить поставленную задачу?

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