Требования к программной системе.

Функциональные требования

описывают поведение системы и сервисы (функции), которые она выполняет

зависят от типа разрабатываемой системы и от потребностей пользователей

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

Функциональные требования

Пример

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

1.Пользователь должен иметь возможность проводить поиск необходимых ему книг и документов или по всему множеству доступных каталожных баз данных или по определенному их подмножеству.

2.Система должна предоставлять пользователю подходящее средство просмотра библиотечных документов.

3.Каждый заказ должен быть снабжен уникальным идентификатором (ORDER_ID), который копируется в формуляр пользователя для постоянного хранения.

Функциональные требования

Неточность

Problems возникают when requirements are not precisely stated

Ambiguous requirements may be interpreted in different ways by developers and users

Рассмотрим второе требование к библиотечной системе из приведенного выше списка и обратим внимание на выражение "подходящее средство просмотра документов".

User intention - special purpose viewer for each different document type

Developer interpretation - Provide a text viewer that

shows the contents of the document

Функциональные требования

Полнота и непротиворечивость

Вообще говоря требования должны быть полны и непротиворечивы.

Полнота (Complete)

Должны быть включены описания всех желаемых функций (возможностей)

Непротиворечивость (Consistent)

Не должно быть несовместимости или противоречивости в описании системных функций

На практике бывает очень трудно (если не сказать – невозможно) обеспечить полное и непротиворечивое документирование требований

Требования к программной системе

Не функциональные требования

Определяют свойства системы и ограничения, e.g. - надежность, время отклика и размер системы, пропускная способность устройств в/в, системные представления и форматы, etc.

Не только к системе, но и к процессу разработки. Process requirements may also be specified mandating a particular CASE system, programming language or development method

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

Не функциональные требования

Виды не функциональных требований

Не функциональные требования

Виды не функциональных требований

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

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

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

Не функциональные требования

Goals and requirements

Non-functional requirements may be very difficult to state precisely and imprecise requirements may be difficult to verify.

Goal

A general intention of the user such as ease of use

Goals are helpful to developers as they convey the intentions of the system users

Verifiable non-functional requirement

A statement using some measure that can be objectively tested

Не функциональные требования

Requirements measures

Требования к программной системе

Требования предметной области

Отражают условия, в которых будет эксплуатироваться система. Выведенные из предметной области приложения и описания системных характеристик и особенностей они отражают окружение (предметную область)

Могут быть сформулированы в виде новых функциональных требований или в виде ограничений на существующие

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