Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
М2-1_Тема-6_Требования к ПИ.doc
Скачиваний:
12
Добавлен:
25.11.2019
Размер:
151.04 Кб
Скачать

6.8.4. Формулирование требований

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

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

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

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

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

Требования должны быть сформулированы так, чтобы удовлетворять таким характеристикам как однозначность интерпретации, верифицируемость, модифицируемость, ясность (прослеживаемость), полезность на стадиях эксплуатации и сопровождения.

Требование обладает прослеживаемостью, если очевидны основания, вызвавшие его необходимость.

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

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

6.8.5. Определение нефункциональных требований

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

- требования к качеству выполнения функций;

- ограничения доступа;

- требования безопасности;

- обеспечение мониторинга и контролируемости;

- прочие ограничения.

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

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

Ниже перечислены примеры требований к качеству выполнения функций, которые следует предъявлять при использовании технологии SSADM:

- часы работы - время суток и дни недели, в течение которых функция поддерживается системой (с указанием особенностей для выходных и праздничных дней);

- доступность - выраженная в процентах доля общего времени работы ПИ, в течение которого функция доступна пользователям;

- оперативность - время реакции для системы реального времени, продолжительность решения задач для систем пакетной обработки;

- частота заявок - количество заявок на решение задачи в единицу времени;

- производительность - суммарный объем работы, выполняемый в единицу времени, например, число считываемых или модифицируемых записей в час;

- продолжительность или раннее время начала выполнения и позднее время завершения задания при пакетной обработке;

- надежность - среднее время наработки на отказ, среднее и максимальное время восстановления системы после сбоя.

При выявлении требований к ограничению доступа проектировщику рекомендуется сосредоточить внимание на следующих вопросах:

- каким данным нужна защита ?

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

- какие необходимы меры ограничения доступа (например, на физическом уровне, с помощью пароля, шифрование) ?

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

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

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

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