Студопедия.Орг Главная | Случайная страница | Контакты | Мы поможем в написании вашей работы!  
 

Структура спецификаций требований



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

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

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

В табл. 4 описаны возможные разделы спецификации.

Таблица 4 – Структура спецификаций требований

Раздел Описание
Предисловие Определяется круг лиц, на которых рассчитан данный документ. Описываются предыдущие версии разрабатываемого программного продукта, а также изменения, внесенные в каждую версию. Дается обоснование для создания новой версии продукта.
Введение Подробно обосновывается необходимость создания системы. Кратко перечисляются системные функции, и объясняется, как система будет работать совместно с другими системами. Должно быть показано, как разработка системы "вписывается" в общую бизнес-стратегию компании, заказывающей программный продукт.
Глоссарий Дается описание технических терминов, используемых в документе. Не делается каких-либо предположений об уровне знаний или практическом опыте читателя документа.
Требования пользователя Описываются сервисы, предоставляемые пользователям, и нефункциональные системные требования. Это описание может быть сделано на естественном языке с использованием диаграмм, блок-схем и других форм записи, понятных заказчику программной системы. Должны быть приведены стандарты на программный продукт и процесс его разработки.
   
   
Окончание таблицы 4
Раздел Описание
Системная архитекту-ра Приводится высокоуровневое представление возможной системной архитектуры с указанием, как распределены системные функции по компонентам системы. Обязательно должны быть выделены повторно используемые (т.е. уже существующие) компоненты.
Системные требования Подробно описываются функциональные и нефункциональные требования. Если необходимо, нефункциональные требования дополняются описанием интерфейсов других систем.
Системные модели Представление нескольких системных моделей, показывающих взаимоотношения между системными компонентами и между системой и ее окружением. Это могут быть объектные модели, модели потоков данных или модели данных.
Эволюция системы Приводятся основные предположения и допущения, на которых базируется система, а также ожидаемые (прогнозируемые) изменения в аппаратных средствах, в потребностях пользователей и т.п.
Приложе-ния Приводится специализированная информация, относящаяся к разрабатываемой системе, например описание аппаратных средств или базы данных, с которыми должна работать система. При описании аппаратных средств необходимо показать минимальную и оптимальную конфигурации, при которых может работать программная система. Описание базы данных должно отображать логическую структуру данных, с которыми будет работать система, и отношения между ними.
Указатели Это может быть обычный алфавитный указатель литературы, указатель диаграмм или указатель системных функций.

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

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

Для больших документов необходимо делать оглавление и подробные указатели для поиска необходимой информации. Особое внимание надо уделять на использование словаря данных в рамках одного программного продукта.

Преимущества использования словаря данных.

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

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

Все имена, используемые в системе (имена сущностей, типов, связей, атрибутов и системных сервисов), должны быть введены в словарь данных. Большинство CASE-средств, которые применяются для моделирования систем, могут поддерживать словари данных.

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

Описание только внешнего поведения программного обеспечения.

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

Указание необходимости и возможности внесения изменений в спецификацию.

Наличие справочных средств для процесса сопровождения программного обеспечения системы.

Описание реакции программного обеспечения и группы сопровождения на нештатные ситуации.

Описание всего жизненного цикла системы, для которой создаётся программное обеспечение.

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

Таблица 5. – Категории специалистов





Дата публикования: 2015-10-09; Прочитано: 610 | Нарушение авторского права страницы | Мы поможем в написании вашей работы!



studopedia.org - Студопедия.Орг - 2014-2024 год. Студопедия не является автором материалов, которые размещены. Но предоставляет возможность бесплатного использования (0.008 с)...