4. Диаграмма «сущность-связь», описывающая концептуальную схему требований (Ryan and Wheatcraft, 2016).

Как проиллюстрировано на рисунке 4, заявления о потребностях и требованиях поддерживаются связанными атрибутами, которые помогают в определении потребности, наборов потребностей, требования и совокупностей требований к управлению ими. Эти атрибуты также помогают в достижении многих характеристик, определенных в этом руководстве.

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

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

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

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

преобразованы.

Заявление о требовании является результатом формального преобразования одного или нескольких источников, потребностей или требований более высокого уровня в согласованное обязательство для организации выполнять некоторую функцию или обладать определенным качеством в рамках установленных ограничений с приемлемым риском. Определение требований - это деятельность, которая посредством формального анализа требований конкретно определяет, что должен сделать объект для удовлетворения источников, потребностей или требований более высокого уровня, из которых они преобразуются, используя формальный процесс преобразования, включающий декомпозицию, вывод, разработку, диаграммы и архитектурные и аналитические/поведенческие модели.

Примечание: Термин “требования”, используемый в данном руководстве, относится к требованиям , содержащимся в наборе исходных требований к проектированию, определенных для SOI.

5. Работа с требованиями в V-образной модели жизненного цикла системы.

(SDLC) Жизненный цикл разработки программного обеспечения — это процесс, который используется для разработки программного обеспечения для проектирования, разработки и тестирования программного обеспечения. Цикл состоит из нескольких этапов — планирование и анализ потребностей, определение требований, проектирование архитектуры продукта, создание или разработка продукта, тестирование продукта, развертывание на рынке и сопровождение.

И так разберем подробней, Ви-модель —

V-модель — это тип модели SDLC, в которой процесс выполняется последовательно в V-образной форме. Модель основана на объединении фазы тестирования с каждой соответствующей стадией разработки. Разработка каждого шага напрямую связана с этапом тестирования. Следующая фаза начинается только после завершения предыдущей. Каждый этап разработки, напрямую связан с тестированием этого этапа.

Этап проектирования V-модели:

• Анализ требований — этап включает общение с заказчиком с целью выделить его требования и ожидания от проекта. Другое название этого этапа — сбор требований.

• Проектирование системы — этап включает проектирование системы и настройку оборудования и коммуникаций для разработки продукта.

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

• Разработка модулей- система разбивает на небольшие модули. Определяется детальный дизайн модулей, также известный как Low-Level Design (LLD).

Низкоуровневое проектирование (LLD) — процесс проектирования на уровне компонентов, который следует за пошаговым процессом уточнения. Предоставляет подробные сведения и определения фактической логики для каждого компонента системы.

Этапы тестирования V-модели:

• Модульное тестирование — модульного тестирования разрабатываются на этапе проектирования модуля. Эти планы модульного тестирования выполняются для устранения ошибок на уровне кода или модуля.

• Интеграционное тестирование — после завершения модульного тестирования выполняется интеграционное тестирование. При интеграционном тестировании модули интегрируются, и система тестируется. Интеграционное тестирование выполняется на этапе проектирования архитектуры. Этот тест проверяет связь модулей между собой.

• Системное тестирование — тестирование тестирует все приложение с его функциональностью, взаимозависимостью и связью. Оно проверяет функциональные и нефункциональные требования разработанного приложения.

• Пользовательское приемочное тестирование (UAT): UAT выполняется в пользовательской среде, напоминающей производственную среду. UAT проверяет, что поставленная система соответствует требованиям пользователя и готова к использованию в реальном мире.

Приемочное пользовательское тестирование (UAT – User Acceptance Testing) – тестирование, которое проводится конечными пользователями системы с целью принятия решения о внедрении.

Принципы V-модели:

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

• Целостность данных / процессов: этот принцип гласит, что успешное проектирование любого проекта требует интеграции и согласованности как данных, так и процессов. Элементы процесса должны быть идентифицированы для каждого требования.

• Масштабируемость: этот принцип гласит, что концепция V-Model обладает гибкостью, позволяющей приспособить любой ИТ-проект независимо от его размера, сложности или продолжительности.

• Перекрестные ссылки: прямая корреляция между требованиями и соответствующей деятельностью по тестированию называется перекрестными ссылками.

• Материальная документация: этот принцип гласит, что каждый проект должен создавать документ. Эта документация требуется и применяется как группой разработки проекта, так и группой поддержки. Документация используется для поддержки приложения, когда оно становится доступным в производственной среде.

Э.Халл “Инженерия требований”:

Что является критерием приёмки системы? Требования заинтересованных сторон. Таким образом, совершенно очевидно, что требования, разработанные на начальных этапах, продолжают использоваться и на завершающих этапах разработки.

В основе классической V-модели (V-Model), применяемой для наглядного описания различных стадий и этапов создания технических систем, лежит представление о взаимосвязи между проверкой соответствия и требованиями. На рис. 1.2 эта взаимосвязь показана в привязке к каждому этапу разработки.

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

максимизировать степень повторного использования имеющихся решений в различных проектах;

организовать управление группами продуктов, обладающих схожими характеристиками и свойствами;

использовать программное управление для координации деятельности;

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

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