Описание функциональных требований проекта

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

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

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

- круглые столы и мозговые штурмы (привести протоколы проведения мероприятий);

- интервьюирования специалистов;

- согласования промежуточных моделей и сценариев.

Практически всегда используется большое количество нотаций для представления результатов as-is: группа диаграмм IDEF, различные виды диаграмм UML, бизнес-моделирование BPMN и др. Желательно кратко обосновать выбор тех или иных средств.

· Описание бизнес-логики и функциональных требований.

Постановка задачи на разработку информационного продукта или на адаптацию и внедрение существующего многотиражной системы обязательно подразумевает максимально полное и однозначное описание функциональных требований. Рекомендуется разбить их на блоки по важности: абсолютно необходимая функциональность, желательная функциональность, возможная функциональность и исключенные из рассмотрения функции (модель MoSCoW – Mast Have, Should Have, Could Have и Would’t Have). Обобщенно такой набор требований считается бизнес-логикой проектируемой системы.

Наиболее важные направления бизнес-логики:

- Сценарные модели и схемы взаимодействия с разрабатываемой системой бизнес-пользователей.

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

- Требования к хранилищам данных и серверной логике (максимально полное описание баз данных в ERD-формате, требования к целостности данных, распределение функциональности между «клиентом» и «сервером», необходимость и спецификация организации витрин данных (Data Marts) и т.д.).

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

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

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

При описании общей логики функциональности рекомендуется использовать UseCase и SwimLane (SADT).

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

· Анализ нефункциональных требований.

Существенным элементом бизнес-логики являются нефункциональные требования:

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

- Требования к операционной среде (локальная, сетевая, Интернет) и пропускной способности каналов связи с серверами.

- Требования к точности вычислений.

- Требования к оперативной и долговременной памяти.

- Требования к технической безопасности и надежности системы (наработки на отказ, необходимость резервирования данных и т.д.).

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

· Анализ проектных ограничений.

Рекомендуется описать факторы, которые ограничивают возможности проектирования и программирования. Ограничения могут быть:

- определенные технологии, средства, языки программирования и базы данных, которые следует использовать или избегать;

- ограничения, налагаемые операционной средой продукта, например типы и версии установленных Web-браузеров;

- обязательные соглашения или стандарты разработки (в частности, требования к организации, планированию и управлению проектом);

- совместимость с продуктами, выпущенными ранее;

- ограничения, связанные с оборудованием, ограничения памяти или процессора, размер, вес, материалы или затраты.

2.3. Цели и бизнес-требования проекта, описание критериев успеха:

· Технико-экономическое обоснование проекта (ТЭО).

Задача ТЭО – обосновать перспективы развития бизнеса после внедрения предлагаемых проектом информационных технологий. Возможно как качественное описание результатов, так и оценка финансового результата. Рекомендуется методология BSC (Balanced Scorecard, метод сбалансированных показателей) и KPI (Key Performance Indicators, метод ключевых показателей).

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

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

Финансовые цели:

- Освоить Х% рынка за Y месяцев;

- Увеличить сектор рынка в стране X на Y% за Z месяцев;

- Достигнуть объема продаж X единиц или дохода, равного $Y, за Z месяцев;

- Получить Х% прибыли или дохода по инвестициям в течение Y месяцев;

- Достигнуть положительного баланса по этому продукту в течение Y месяцев;

- Сэкономить $Х в год, которые в настоящий момент расходуются на обслуживание системы;

- Уменьшить затраты на поддержку на Х% за Z месяцев;

- Получить не более X звонков в службу обслуживания по каждой единице товара и Y звонков по гарантии каждой единицы товара в течение Z месяцев после выпуска товара;

- Увеличить валовую прибыль для существующего бизнеса с Х до Y%.

Нефинансовые цели:

- Достигнуть показателя удовлетворения покупателей, равного по крайней мере X, в течение Y месяцев со времени выпуска товара

- Увеличить производительность обработки транзакций на Х% и снизить уровень ошибок данных до величины не более Y%

- Достигнуть определенного времени для достижения доминирующего положения на рынке

- Разработать надежную платформу для семьи связанных продуктов

- Разработать специальную базовую технологическую основу для организации

- Получить X положительных отзывов в отраслевых журналов к определенной дате

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

- Соответствовать определенным федеральным и государственным постановлениям

- Уменьшить время обработки до X часов на Y% звонков покупателей в службу поддержки

· Календарно-ресурсное планирование проекта (включая управление командой).

Рекомендуется в качестве базового документа для планирования и управления проектом составить и проанализировать ресурсно-календарный план в формате диаграммы Ганта или сетевого графика (оптимальный инструмент – Ms Project). Особый интерес представляют события-вехи проекта, которые желательно охарактеризовать в терминах отчетных промежуточных документов и артефактов. Также рекомендуется описать критерии достижения конкретных вех.

Обязательными рабочими документами дипломного проекта, которые также должны быть приведены в данном разделе и которые во многом могут быть получены из программы Ms Project, являются:

- матрица ролевых кластеров участников проекта (даже для случаев, когда на проекте один исполнитель эта матрица будет не пустой – автор ВКР в разных фазах участвует в разных ролях);

- бюджет проекта.

При описании управления проектом рекомендуется использовать один из стандартов PMBOK, SWEBOK, MSF.

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

Основными документами данного раздела, как правило, являются:

- главная таблица рисков;

- паспорта основных рисков (включая планы мероприятий по предотвращению важнейших рисков и по устранению последствий).