1.4. Участники разработки требований
Заказчики или инвесторы — те, кто платит деньги;
Пользователи (подкласс заказчиков);
Аналитики требований — самый главный человек, который балансирует требования разработчика и заказчика. Лучше брать со стороны заказчика, так как программисты могут не владеть предметной областью;
Разработчики;
Тестировщики;
Технические писатели;
Менеджер проекта;
Производственники (внедрение);
Сотрудники отдела продаж;
Сотрудники отдела технического обслуживания.
1.4.1. Аналитик требований
Синонимы: бизнес-аналитик, системный аналитик.
Требования:
умение общаться и слушать,
способность быстро обрабатывать информацию,
навыки анализа и моделирования,
способность обучаться,
лидерские качества,
организационные способности.
Кто может им быть:
бывший пользователь,
бывший разработчик или тестировщик,
бывший менеджер проекта.
1.5. Типы требований
Бизнес-требования — требования, которые формулируются в концепции. Определяют цели ПО и его основные задачи и преимущества перед другими ПО;
Требования пользователей — требования людей, которые будут эксплуатировать ПО. Как пользователь хочет использовать этот ПП, для каких задач. Формулируют сами пользователи, как они умеют и теми терминами, которые используются в их предметной области — это создает некую сложность для программистов, так как программист не всегда может знать эту предметную область. Пользователи не знают как работает программа, только знают о технологических процессах;
Функциональные требования — требования, которые формулируют программисты на основе требований пользователей. Эти требования наиболее детальные и именно на основе них осуществляется реализация ПО. В спецификацию добавляется эти требования;
Нефункциональные требования — требования, которые определяют качество ПО.;
Системные требования — требования, которые обеспечивают работоспособность ПО в данной системе на данной платформе, и, соответственно взаимодействие с посторонним ПО.
1.6. Этапы сбора и анализа требований с точки зрения rup
Определение концепции продукта. Общее видение на ПП. Определение его значимости, актуальности, его границ. Границы проекта — это то, что не будет реализовано в ПП.
Документ о концепции и границах проекта
Сбор требований пользователей
Документ о вариантах использования или набор описания пользователей того, как пользователи хотят работать с ПП, или в виде диаграмм.
Анализ требований
Модели анализа — обычно графические модели.
Спецификация требований к программному продукту. Формируется на основе моделей анализа. Содержат функциональные требования.
Проверка требований
Итог: техническое задание. Проводятся инспекции тз на предмет неправильных формулировок, двусмысленность, недоговоренности.
1.7. Процесс разработки требований
Иллюстрация того, что сказано выше. Внешний интерфейс — протоколы, драйверы.
Ограничения связаны с бизнес-правилами. Например: ограничение по режиму работы.
Бизнес-правило — свойство, которое должно отвечать некоторому стандарту, документу.
Спецификация требование к ПО в некоторых случаях называют ТЗ.
