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