Главная | Обратная связь | Поможем написать вашу работу!

Документирование системных требований

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

Системную спецификацию читает множество разных людей, начиная от высшего руководства компании – заказчика системы и заканчивая рядовым разработчиком системы. На рис. 5.3, взятом из статьи [204], показаны категории читателей спецификации.

Рис. 5.3. Читатели системной спецификации

Хенингер (Heninger, [160]) сформулировал шесть условий, которым должна соответствовать спецификация программной системы.

• Описывать только внешнее поведение системы.

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

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

• Служить справочным средством в процессе сопровождения системы.

• Отображать весь жизненный цикл системы.

• Предусматривать реакцию системы и группы сопровождения на непредвиденные (нештатные) ситуации.

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

Многие организации, такие, как Министерство обороны США и Институт инженеров по электротехнике и радиоэлектронике IEEE, разработали собственные стандарты документирования спецификаций. В монографии [89] описаны некоторые из этих стандартов, а также проведено их сравнение. Наиболее известный стандарт разработан IEEE и называется IEEE/ANSI 830-1993 [IEEE, 1993]. В книге [334], содержащей великолепный обзор работ по технологии разработки требований, приведено полное описание этого стандарта. Данный стандарт предполагает следующую структуру спецификации.

1. Введение

1.1. Цели документа

1.2. Назначение программного продукта

1.3. Определения, акронимы и аббревиатуры

1.4. Список литературы и других источников

1.5. Обзор спецификации

2. Общее описание

2.1. Описание программного продукта

2.2. Функции программного продукта

2.3. Пользовательские характеристики

2.4. Общие ограничения

2.5. Обоснования, предположения и допущения

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

4. Приложения

5. Указатели

Хотя стандарт IEEE не идеален, он может служить отправной точкой при написании спецификации. Конечно, при ее написании необходимо также учитывать стандарты, принятые в организации - разработчике ПО. В табл. 5.4 описаны возможные разделы спецификации, построенной на основании стандарта IEEE. Я также включил раздел о возможной эволюции системы, как рекомендует Хенингер.

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

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

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

КЛЮЧЕВЫЕ ПОНЯТИЯ

• Требования программной системы – это описание того, что система должна делать, а также ограничений, накладываемых на ее поведение и реализацию.

• Функциональные требования – описание сервисов, предоставляемых системой, и способов выполнения вычислительных операций. Требования предметной области – это функциональные требования, которые вытекают из характеристик той предметной области, где будет эксплуатироваться разрабатываемая система.

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

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

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

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

Упражнения

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

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

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

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

5.5. Запишите системные требования для системы продажи билетов с помощью языка, основанного на языке программирования Java. Обратите внимание на обработку ошибок пользователя.

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

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

5.8. Какими свойствами должен обладать язык программирования, чтобы его можно было применить для написания спецификаций интерфейсов? В этом аспекте рассмотрите возможности языков С, Java и Ada.

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

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

⇐ Предыдущая 37 38 39 40 414243 44 45 46 Следующая ⇒