Письменные лекции по дисциплине «Разработка и анализ требований»
.pdf
●Технические писатели;
●Менеджер проекта;
●Производственники (внедрение);
●Сотрудники отдела продаж;
●Сотрудники отдела технического обслуживания.
1.4.1.Аналитик требований
Синонимы: бизнес-аналитик, системный аналитик. Требования:
●умение общаться и слушать,
●способность быстро обрабатывать информацию,
●навыки анализа и моделирования,
●способность обучаться,
●лидерские качества,
●организационные способности. Кто может им быть:
●бывший пользователь,
●бывший разработчик или тестировщик,
●бывший менеджер проекта.
1.5.Типы требований
●Бизнес-требования — требования, которые формулируются в концепции. Определяют цели ПО и его основные задачи и преимущества перед другими ПО;
●Требования пользователей — требования людей, которые будут эксплуатировать ПО. Как пользователь хочет использовать этот ПП, для каких задач. Формулируют сами пользователи, как они умеют и теми терминами, которые используются в их предметной области — это создает некую сложность для программистов, так как программист не всегда может знать эту предметную область.
Пользователи не знают как работает программа, только знают о технологических процессах;
●Функциональные требования — требования, которые формулируют программисты на основе требований пользователей. Эти требования наиболее детальные и именно на основе них осуществляется реализация ПО. В спецификацию добавляется эти требования;
●Нефункциональные требования — требования, которые определяют качество ПО.;
●Системные требования — требования, которые обеспечивают работоспособность ПО в данной системе на данной платформе, и, соответственно взаимодействие с посторонним ПО.
1.6. Этапы сбора и анализа требований с точки зрения RUP
●Определение концепции продукта. Общее видение на ПП. Определение его значимости, актуальности, его границ. Границы проекта — это то, что не будет реализовано в ПП.
Документ о концепции и границах проекта
●Сбор требований пользователей Документ о вариантах использования или набор описания
пользователей того, как пользователи хотят работать с ПП, или в виде диаграмм.
●Анализ требований Модели анализа — обычно графические модели.
Спецификация требований к программному продукту. Формируется
на основе моделей анализа. Содержат функциональные требования.
●Проверка требований Итог: техническое задание. Проводятся инспекции тз на предмет
неправильных формулировок, двусмысленность, недоговоренности.
1.7. Процесс разработки требований
Иллюстрация того, что сказано выше. Внешний интерфейс — протоколы, драйверы.
Ограничения связаны с бизнес-правилами. Например: ограничение по режиму работы.
Бизнес-правило — свойство, которое должно отвечать некоторому стандарту, документу.
Спецификация требование к ПО в некоторых случаях называют ТЗ.
1.7. Разработка концепции продукта
●Участники этапа:
бизнес-аналитик (Program Manager, Product Manager),
инвестор (заказчик).
●Цель:
выработка единого видения проекта.
●Документирование:
документ об образе решения и границах (устав ПП, Product Vision Document, Market Requirement Document).
●Содержит:
информацию о высокоуровневых требованиях и возможностях продукта, ориентировочные сроки реализации и бюджет.
●Служит для:
сделать вывод о целесообразности разработки.
1.8.Сбор бизнес-требований для продукта
●Продукт под заказ:
— Определение исходных стимулов.
— Определение целей продукта и критериев успеха.
— Определение потребностей клиента.
— Обзор конкурентов.
●Продукт для открытого рынка:
— Определение исходных стимулов.
— Обзор конкурентов.
— Определение целевого сегмента рынка.
— Определение потребностей клиентов.
— Определение целей продукта и критериев успеха.
1.9.Исходные стимулы
●Потребность рынка. То, что можно продать.
●Производственная необходимость. Освободить людей — не платить зарплаты, заменить всех роботами.
●Потребность заказчика. Захотел заказчик.
●Технический прогресс.
●Юридические ограничения и нормы. Что-то меняется в законодательстве — надо менять ПО.
1.10.Цели продукта и критерии успеха
●Финансовые Освоить __ % рынка за __ месяцев.
Достигнуть объема продаж ___ , дохода ___ за __. Сэкономить ___ на обслуживании системы за период ___.
●Нефинансовые Разработать базовую технологическую основу для организации.
Соответствовать законодательной базе. Повысить рейтинг организации.
1.11.Определение целевого сегмента рынка
Анализируя рынок, происходит решение, в котором принимается нужно ли компании разрабатывать ПО.
●Рынок домашних пользователей:
—дети,
—слабовидящие,
—обычные пользователи.
●Рынок корпоративных пользователей:
—малые компании от 1 до 250 чел. (SMB — Small and Medium Business),
—большие компании от 250 до 2500 чел.,
—корпорации более 2500 человек.
1.12.Определение потребностей клиентов
●Информация о типах пользователей. Для ПО, где разные пользователи, их роли
●Процессы (бизнес-процессы), в которых используется продукт.
●Сценарии работы пользователей. Внутри бизнеспроцессов пишется сценарии работы пользователей (как будет взаимодействовать с ПП, чтобы решить свою задачу)
●Операционная среда (удаленность пользователей, режимы работы, защита данных).
●Требования к дизайну: операционная система, взаимодействующие приложения, форматы ввода-вывода.
Итог: список основных функций программного продукта
1.13.Обзор конкурентов
●Список проблем, которые должны быть решены в продуктах данного типа (что делает продукт).
●Список конкурентов, предлагающих продукты данного типа.
●Список продуктов конкурентов для обзора.
●Документация к продуктам или сами продукты.
●Список возможностей продуктов конкурентов (как работает продукт).
●Обобщение информации по конкурентам.
Итог: функция, которая отличает наш ПП от ПП конкурента.
1.13.1. Пример списка возможностей конкурентов
Сравнительная характеристика XML-анализаторов.
1.14. Документ о концепции и границах проекта
●Бизнес-требования:
— Исходные данные. Подробное описание проблемы, с которым
встречаются пользователи, является стимулом.
—Возможности бизнеса. Решение проблемы, предложенной в исходных данных.
—Бизнес-цели и критерии успеха. Бизнес — цели должны быть проверяемыми.
—Положение о концепции. См. 1.14.1.
—Бизнес-риски. См. 1.15.
—Предположения и зависимости. Факторы, которые могут способствовать развитию ПП.
●Рамки и ограничения проекта:
—Основные функции. Высокоуровневые не детализированные функции с точки зрения пользователя. Их, скорее всего, не будет много, будут детализироваться на уровне требований пользователей. В
концепции должны быть переставлены эти функции, далее отталкиваемся от них.
—Объем первоначальной и последующих версий. Этот список функций можно поделить на любое количество версий, как удобно нам или заказчику.
—Ограничения и исключения. Исключения — это то, что не будет в проекте, то, что выходит за границы ПП. См. 1.16.
●Бизнес-контекст. Концепция окружения:
—Профили заинтересованных лиц.Люди, которые заинтересованы в развитии этого ПП, необязательно пользователи. См. 1.17.
—Приоритеты проекта.
—Особенности развертывания (операционная среда).
1.14.1. Положение о концепции Для [целевая аудитория]
Который [положение о потребностях и возможностях] Эта (этот) [имя продукта] Является [категория продукта]
Который(ая) [ключевые функции, основное преимущество] В отличие [основной конкурирующий продукт]
Наш продукт [положение об основном отличии и преимуществе нового продукта]
1.15. Бизнес-риски
Источники риска:
●Конкуренция. Знать, кто занимается выбранным направлением.
●Изменение законодательства. Могут внести изменения для любого типа ПО.
●Невыполнение обязательств партнерами. Если оборудование должно быть доставлено в некоторый срок, но этого не случилось, и вам негде протестировать код.
●Необходимость использования новых технологий. Новые технологии требуют новые знания, будут ли люди в вашей команде, которые эти новые знания уже имеют, смогут быстро получить.
●Отсутствие единого видения программного продукта у заказчиков, пользователей и разработчиков. Не получается прийти к единому мнению между заказчиками и программистами.
●Ошибки в определении требований к программному продукту. Неправильное понимание требования, неправильная формулировка. Иллюстрация, которая наглядно показывает данный риск.
1.16. Ограничения проекта и их выявление
●Экономические:
— Какие финансовые ограничения следует учесть?
— Существуют вопросы лицензирования?
●Технические:
— Существуют ограничения на технологии?
— Допустимо использование новых технологий?
●Системные:
— Проект создается в рамках существующей системы?
— Надо обеспечить совместимость с существующей системой?
●Эксплуатационные:
— Существуют юридические ограничения?
— Существуют требования к безопасности?
1.17.Профили заинтересованных лиц
●Заинтересованное лицо.
●Основная ценность программного продукта.
●Отношение к программному продукту.
●Основные интересы.
●Ограничения.
1.18.Пример бизнес-требований разных групп пользователей
●Разработчики терминала:
— Получение прибыли от продажи терминала.
— Привлечение к бренду розничных компаний и магазинов.
●Магазин:
— Максимальное получение прибыли от торговых площадей.
— Привлечение новых покупателей.
— Минимальные расходы на обслуживание терминала.
●Покупатели:
— Уменьшение затрат времени на покупку.
— Простой для понимания процесс совершения покупки.
1.19.Приоритеты проекта
●Функции. Описаны в концепции.
●Качество. Качество реализации ПП.
●Сроки, которые устанавливает заказчик.
●Расходы. Финансовые и нефинансовые.
●Персонал. Его работоспособность и квалифицированность.
Все это определяет успех проекта. Для каждого из этих факторов определяют 3 уровня обязательности, которые, соответственно, в одном случае пренебречь этим факторов, а с другой стороны учитывать эти факторы максимально полно.:
●Ограничения. Высокой жесткости — должно быть выполнено.
●Движущая сила. Средней жесткости.