1.1.2. Анализ осуществимости

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

1.1.3. Определение целей и области действия

Бизнес-цели:

• Помощь абитуриентам при поступлении в ВУЗ

• Популяризация данного программного продукта

Бизнес-требования:

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

Образ продукта:

1.1.4. Документирование образа и границ проекта

Сведения об образе и границах проекта были оформлены в виде отдельного документа (см. Приложение 2), владельцами которого являются лица, финансирующие проект.

1.2. Выявление требований

На данном этапе изначально необходимо определить круг заинтересованных лиц.

Заказчик – частная коммерческая фирма (Самойленко В.П.)

Разработчики – частная организация (Крупицкий М.В. и Мещеряков А.А.)

Пользователи – абитуриенты

Заинтересованные лица – заказчик, разработчики и пользователи

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

Подготовка вопросов:

1) Нужна ли вообще подобная программа?

2) Важно ли, чтобы система быстро реагировала на запросы пользователя?

(Если да, то насколько быстро?)

3) Допустимы ли сбои при работе программы?

4) Как вы думаете, как долго прослужит данная программа до появления лучшей?

5) Должны ли быть встроенные средства антивиручной защиты или приемлимо взаимодействие с другим продуктом?

6) Насколько важно удобство в данной системе?

7) Какие платформы должна поддрживать программа?

8) Как вы думаете, будет ли актуально повторное использование в аналогичных проектах?

9) Какой язык программирования вы бы посоветовали использовать?

10) Слышали ли вы о схожих системах?

11) Разрешаете использовать ваше имя в отчёте по опросу?

Теперь нужно провести опрос (по телефону, через интернет или, лучше всего, при личной беседе).

Выберем несколько человек для проведения опроса.

Результаты опроса можно посмотреть в Приложении 3.

На основе результатов составим черновик требований (см. там же, в Приложении 3), который отправим Заказчику. При необходимости, можно провести повторные опросы.

1.2.2. Совместные семинары

Совместные семинары также являются довольно важной методикой при выявлении требований.

При организации семинаров, основной целью которых является выявление требований, необходимо пользоваться определенными приемами, например:

• Основные правила. Участники семинара должны договориться об основных правилах проведения семинара, например: своевременно начинать и заканчивать семинар, не проводить несколько обсуждений одновременно, следить, чтобы каждый участвовал в работе, критиковать решения, а не людей их предложивших.

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

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

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

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

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

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