В дополнение к вышерассмотренному, рассмотрим теперь результаты деятельности и исполнителей действий.
Документ системных требований является выходом сбора требований и анализа деятельности и содержит потребности пользователей и заинтересованных сторон, исходя из свойств системы и совокупности ограничений. Приведем примеры требований: функциональное требование состоит в том, что пользователь может при помощи системы администрировать данные и счета клиентов, пример требования безопасности состоит в том, что данные системы должны быть доступны только уполномоченному лицу. Технологическое ограничение состоит в том, что пользователь должен иметь возможность взаимодействовать с системой через веб-браузер (обозреватель).
Документ системных требований должен охватывать следующие темы:
- введение: задача документа, масштабность проекта, пояснения используемых терминов и сокращений (т.н. словарь системы), ссылки на другие документы, описание структуры документа;
- описание продукта;
- профили пользователей и заинтересованных сторон, задачи, потребности, опыт. Описание пользователей помогает лучше понять потребности и навыки пользователей при обработке создаваемого продукта;
- ограничения: ограничения такие, как связь с существующими системами, средства разработки, инструменты, исходят от пользователей и из окружающей среды;
- предпосылки и зависимости: создание продукта может предполагать выполнения определенных условий, таких как соблюдение законодательства; третья сторона создает систему интерфейсов;
- система управления (käitluskeskkond) описывает платформы, на которых продукт должен работать, в том числе операционные системы, аппаратные платформы, процессоры баз данных, веб-серверы, серверы приложений, мониторинговые интерфейсы и т.д.;
- детальное описание функциональных и технических (безопасность, удобство использования и т.д.) требований, включая пользовательские истории и систему управления UML.
Документ требований составляется аналитиком совместно с будущими пользователями.
Документ архитектурного дизайна описывает структуру системы, системных компонентов и модулей, интерфейсов между компонентами и интерфейсы с другими системами. Описывается также физическая архитектура – аппаратные средства, и показывается, какой программный компонент на какую аппаратуру устанавливается.
Документ архитектурного дизайна должен охватывать следующие темы:
- введение: задачи документа, ссылки на другие документы, описание структуры документа;
- выбор и настройка средств разработки, сред разработки;
- кодирование, в том числе комментирование и стандарты наименования;
- интерфейсы с другими системами, форматы и методы обмена данными;
- внутренняя структура и строение продукта: покомпонентное деление системы, обязанности и роли компонентов, обмена данными между компонентами;
- предпосылки архитектурных решений, альтернативы, критерии выбора;
- требования к производительности. Изображаются таким образом, чтобы их можно было бы проверить в ходе тестирования;
- методы взаимодействия с пользователями, методы отображения ошибок;
- потребность в ресурсах, то есть, как много памяти и вычислительной мощности требует продукт и т.д.;
- гарантирование мер безопасности;
- мобильность (переносимость), т.н. возможность запуска программного обеспечения на различных платформах.
Системные требования и архитектурные решения должны иметь между собой перекрестные ссылки, то есть в случае необходимости возможно при изменении некоторого требования изменить и связанные с ним архитектурные решения и, наоборот, при изменении некоторого архитектурного решения, например, финансовых причин, найти какие требования затрагивает это решение об изменении.
Документ архитектурного дизайна составляет архитектор (разработчик структуры системы программного обеспечения), исходя из требований, приведенных в документе требований.
Руководство пользователя является документом, по которому пользователь получает обзор системы – для чего пользователь может использовать данный продукт, как использовать продукт, какие могут ошибочные ситуации и пути их разрешения. Руководство пользователя не дает обзор системы “изнутри”, но только то, что доступно пользователю.
Проектная документация рассматривает связанные с управлением проекта материалы.Руководство по установке рассматривает инсталлирование (установку, развертывание) продукта, передачу (пересылку) данных, сопровождение и администрирование, конфигурацию, порядок ведения изменений продукта.