Полученная в результате декомпозиции структура системы должна сопровождаться кратким описанием включенных в нее подсистем.
Комментарии к примеру. Приведем примерную структурную схему разрабатываемой системы и описание некоторых подсистем (рисунок 3).
 |
В состав системы входят следующие подсистемы:
1) Подсистема управления, которая отвечает за взаимодействие подсистем между собой и представлена в виде иерархического меню;
2) Подсистема составления кроссворда, в состав которой входят:
a) подсистема настройки параметров, которая отвечает за ввод (выбор) значений параметров кроссворда и проверку корректности этих значений;
b) подсистема ручного составления, которая …
c) подсистема генерирования, которая …
3) Подсистема разгадывания, которая …
4) Файловая подсистема, которая …
5) Подсистема работы со словарем, которая …
6) Подсистема визуализации, которая …
7) Справочная подсистема, которая содержит сведения о системе (руководство пользователю) и ее об ее разработчиках.
ЛАБОРАТОРНАЯ РАБОТА № 5
разработка спецификации требований
Разработка спецификации программного обеспечения является одним из фундаментальных процессов технологии разработки ПО. Этот процесс анализа, формирования, документирования и проверки функциональных возможностей и ограничений системы называется в терминологии программной инженерии «разработка требований» (спецификация требований). Он является критическим этапом в создании всех видов программных систем, что обусловлено тем, что ошибки, допущенные на этой стадии, ведут к возникновению серьезных проблем на этапах проектирования и разработки. Опыт индустрии информационных технологий однозначно показывает, что вопросы, связанные с управлением требованиями, оказывают критически-важное влияние на программные проекты, в определенной степени ‑ на сам факт возможности успешного завершения проектов. Только систематичная работа с требованиями позволяет корректным образом обеспечить моделирование задач реального мира и формулирование необходимых приемочных тестов для того, чтобы убедиться в соответствии создаваемых программных систем критериям, заданным реальными практическими потребностями.
Дадим некоторые определения.
Требования ‑ это свойства, которыми должно обладать ПО для адекватного определения функций, условий и ограничений выполнения ПО, а также объемов данных, технического обеспечения и среды функционирования [12, 13].
На практике часто применяется подход, используемый в различных методологиях разработки ПО и базирующийся на определении групп требований к продукту. Такой подход обычно включает группы (типы, категории) требований, например: программные, системные, функциональные, нефункциональные (в частности, атрибуты качества) и т.п.
Программные требования (Software Requirements) ‑ свойства программного обеспечения, которые должны быть надлежащим образом представлены в нём для решения конкретных практических задач [14]. Данная область знаний касается вопросов извлечения (сбора), анализа, специфицирования и утверждения требований к разрабатываемой ПС.
Функциональные требования задают «что» система должна делать; нефункциональные – с соблюдением «каких условий» (например, скорость отклика при выполнении заданной операции). При разработке этих требований в первую очередь необходимо учитывать потребности пользователя (заказчика). Пользовательские требования (User Requirements) – описывают цели/задачи пользователей системы, которые должны достигаться/выполняться пользователями при помощи создаваемой программной системы. Часто пользовательские требования представляют в виде сценариев (вариантов использования) Use Сase (см. лабораторную работу №5).
Среди нефункциональных требований на первый план выходят атрибуты качества и ограничения. Атрибуты качества (Quality Attributes) описывают дополнительные характеристики продукта в различных «измерениях», важных для пользователей и/или разработчиков. Атрибуты касаются вопросов портируемости, интероперабельности (прозрачности взаимодействия с другими системами), целостности, устойчивости и т.п. Данный вид требований мы будем называть спецификацией качества. Ограничения (Constraints) включают в себя формулировки условий, модифицирующих требования или наборы требований, сужая выбор возможных решений по их реализации. В частности, к ним могут относиться параметры производительности, влияющие на выбор платформы реализации и/или развертывания (протоколы, серверы приложений, баз данных, ...), которые, в свою очередь, могут относиться, например, к внешним интерфейсам.
Спецификация требований к ПО (SRS) ‑ процесс формализованного описания функциональных и нефункциональных требований, требований к характеристикам качества в соответствии со стандартом качества ISO/IEC 9126-94, которые будут отрабатываться на этапах ЖЦ ПО.
В спецификации требований отражается:
− структура ПО;
− требования к функциям, качеству и документации;
− задается в общих чертах архитектура системы и ПО, алгоритмы, логика управления и структуры данных.