Классификация требований к программному изделию

advertisement
ЛЕКЦИЯ 2
Тема 2.2 Требования к программному изделию (4 часа)
1. Цель фазы. Основной вид деятельности в фазе. Ответственный за
определение требований. Разработка логической модели программного
изделия Классификация требований к программному изделию.
2. Атрибуты требований к программному изделию. Документ Требования к
программному изделию.
1. Цель фазы. Основной вид деятельности в фазе. Ответственный за
определение требований.
Фаза определения требований к программному изделию – фаза "анализа
проблемы".
Цель фазы – разработка полной, непротиворечивой и корректной
совокупности требований к программному обеспечению на основе
всестороннего изучения требований пользователя.
Ответственный за выработку требований - разработчик. Для участия
в этой фазе привлекаются пользователи, инженеры-программисты, специалисты
по техническим средствам, обслуживающий персонал. Ответственным за
выполнение работы назначается системный аналитик. Руководитель проекта
организует взаимные консультации и обсуждения, результатом которых
должны быть четкие и непротиворечивые формулировки требований.
Результат фазы – документ Требования к программному изделию
(ДТПИ), который определяет, что должен делать программный продукт, как
будет осуществляться проверка правильности и полноты выполняемых
функций и на этапах проектирования, и при проверке конечного продукта.
Работы выполняются в соответствии с планом, разработанным на предыдущем
этапе.
Основная деятельность – трансформация требований пользователя в
требования к программному изделию и составление подробного описания того,
что должно выполнять программное изделие.
Главная задача на этом этапе – согласование представлений и
требований пользователя (заказчика) и разработчика программного изделия.
Выработка требований к программному изделию может потребовать
создание прототипа для проверки пояснения или уточнения требований и их
согласования с заказчиком. На этой фазе разрабатываются планы работ для
следующей фазы. В отечественной практике рассматриваемая фаза завершается
созданием Технического задания на программное изделие.
Разработка логической модели программного изделия
Разработчик
должен
сконструировать
логическую
модель
проектируемого программного изделия, независимую от последующей
физической реализации, которая должна отражать требования пользователя. Эта
модель служит для выработки совокупности требований к программному
обеспечению.
Логическая модель должна удовлетворять следующим правилам:
1. Каждая функция в модели
отражает единственную и четко
определенную цель. Имена функций определяют, что должно быть
сделано, а не как сделано.
2. Функции соответствуют уровню иерархии, на котором они
представлены в модели.
3. Связи между функциями (функциональными блоками модели)
минимизируют.
4. Каждая функция может разделиться не более чем на 7 подфункций
следующего уровня.
5. В модели не должна присутствовать информация, связанная с
последующей реализацией изделия например, такие понятия, как
модуль файл, запись и т.д.
6. Для каждой функции приводятся входные данные.
7. Каждой функции соответствует список выходных данных (выходных
отчетов).
Классификация требований к программному изделию
Требования к ПИ систематизируются в соответствии с классификацией,
содержат следующие категории:
1. Функциональные требования определяют, что должно делать ПИ, и
выводятся непосредственно из логической модели, которая вытекает
из требований пользователя. Для
количественного выражения
некоторые из функциональных требований могут включать атрибуты
эксплуатационных характеристик (например, производительность,
емкость).
2. Эксплуатационные требования определяют значения измеряемых
переменных, характеризующих работу программного изделия.
Представляются в виде отдельных требований или количественных
атрибутов функциональных требований.
Например, количественные требования записывать: "время
ответа должно быть не более х сек"
3. Требования к интерфейсам описывают элементы технических
средств, программного обеспечения, баз данных, с которыми должен
взаимодействовать программный продукт. Требования к интерфейсам
с техническими средствами определяют необходимую их
конфигурацию. Требования к программному обеспечению могут
включать требования к типу и версии операционной системы,
прикладным пакетам, типу СУБД.
Требования к внешним интерфейсам могут обусловить использование
конкретного
сетевого
протокола
передачи
информации,
определенного языка описания документов и т.п.
Требования к интерфейсам можно проиллюстрировать с помощью
специальных структурных схем, описывающих взаимодействие
программного изделия с окружающей обстановкой.
4. Операционные требования регламентируют, как будет работать
система, как она будет связываться с операторами или
пользователями программного изделия.
Требования должны включать все интерфейсы пользователя и
требования к человеко-машинному взаимодействию.
Например, форматы экранов, содержание сообщений об ошибках,
справочная информация, выдаваемая в качестве подсказок
пользователю.
5. Требования к ресурсам устанавливают верхние пределы для
характеристики технических средств (скорость процессора, емкость
внешней и оперативной памяти)
6. Требования на верификацию программного изделия и на приемное
тестирование
описывают,
как
проверяется
корректность
принимаемых решений на каждом этапе ЖЦПИ, могут включать
требования к моделированию окружающей обстановки, интерфейсов
программного изделия.
Требования к приемному тестированию определяют условия
проведения аттестации разработанного программного изделия.
7. Требования к защите информации включают требования к
обеспечению конфиденциальности и целостности информации:
команды блокировки, системы паролей, защита от вирусов,
ограничение доступа к данным и запрещение отдельных операций с
данными для разных категорий пользователей.
8. Требования к качеству охватывают специфические атрибуты
программного изделия, которые гарантируют, что функционирование
изделия будет соответствовать поставленным целям. Показатели
качества должны быть выражены в количественных величинах.
Показатели: надежность программного изделия, пригодность его к
сопровождению, безопасность, описываются отдельно.
9. Требования надежности определяются либо значением допустимого
среднего времени между отказами, либо значениями минимального
времени между отказами.
10.Требования на пригодность к сопровождению – требования
простоты исправления ошибок (при отказах), легкости адаптации к
конкретным операционным условиям и простоты модернизации
программного изделия при изменении требований пользователя и при
совершенствовании программного
изделия в процессе его
эксплуатации.
По возможности требования представляются количественными
показателями (время исправления отказа, коэффициент готовности).
Требования могут включать ряд ограничений, отражающих
возможность организации, занятой сопровождением.
11.Требование к безопасности – ряд дополнительных требований к
программному изделию, которые обусловлены опасностью отказов
программного изделия.
12.Требования к документации дополняют требования, содержащиеся
в стандартах на документацию.
Download