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

Детализация Software Requirements (Леффингвелл)

Типы требований

Функциональные	Нефункциональные	Ограничения
требования	требования	проектирования

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

•Нефункциональные требования (Usability, Reliability, Performance, Supportability)

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

Классификация и артефакты

Vision

Stakeholder Needs

Use-case model

Features

Use Cases

Supplementary Spec.

Software

Requirements

Отображение на документы (RUP и Вигерс)

	Функциональные требования		Нефункциональные требования
	Business Requirements
	(Бизнес-требования)
	Vision Document (Концепция)
			Business Rules
			(Бизнес-правила)
	User Requirements
	(Пользовательские
	требования)		Quality Attributes
			(Атрибуты качества)
	Use-Case Document (Спецификация
	варианта использования)
			External Interfaces
			(Внешние
	System Requirements	Functional	интерфейсы)
		Requirements
	(Системные
		(Функциональные
	требования)
		требования)	Constraints
			(Ограничения)
		SRS Document (Спецификация требований)

Классификация Вигерса и RUP

•RUP отождествляет понятие «требование» только с Software

Requirements.

•Бизнес-требования и Stakeholder/User Needs – достаточно близкие понятия, относящиеся к problem domain.

•В RUP Features существуют как самостоятельная классификационная единица.

•Вигерс выделяет Пользовательские требования, отмечая, что они могут быть выражены вариантами использования (use cases).

•В RUP Software Requirements имеют более широкий «охват»,

включая как функциональные, так и нефункциональные требования.

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

Представление требований в IEEE 830

•Стандарт IEEE 830-1998 IEEE Recommended Practice for Software Requirements Specifications описывает рекомендуемые способы спецификации требований к

программному обеспечению.

•Результатом процесса спецификации требований является однозначно интерпретируемый и целостный документ-спецификация требований.

•Стандарт на документальное оформление требований, задает определенные группировки

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

Основные элементы SRS

•Стандарт определяет основные элементы, которые

должны быть отражены в Software Requirements Specifications (SRS):

–Функциональность. Ответ на вопрос «ЧТО должно делать ПО?»

–Внешние интерфейсы. Как ПО должно взаимодействовать с людьми, другим ПО или аппаратурой.

–Производительность. С какой скоростью должны производиться те или иные операции, каково время отклика и т.п.

–Атрибуты. Определяют точность, переносимость, модифицируемость, эксплуатационные качества и т.п.

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

Общая структура SRS

Соответствие типов требований (Вигерс)
и SRS IEEE 830
	5.3.1 External interfaces
	5.3.2 Functions
	5.3.3 Performance requirements
Constraints	5.3.5 Design constraints
(Ограничения)
	5.3.6 Software system attributes

Представление требований в ГОСТ

•ГОСТ 34.602 определяет состав и правила оформления документа «Техническое задание на создание (развитие или модернизацию) системы» (см. Автоматизированная система, в ГОСТ 34.003).

•Документ Техническое задание устанавливается как основной документ, определяющий «требования и порядок создания автоматизированной системы».

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

Структура документа

•ГОСТ 34.602 предлагает следующую структуру разделов документа Техническое задание:

–общие сведения;

–назначение и цели создания (развития) системы;

–характеристика объектов автоматизации;

–требования к системе;

–состав и содержание работ по созданию системы;

–порядок контроля и приемки системы;

–требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие;

–требования к документированию;

–источники разработки.

•Подраздел «Цели создания системы» и раздел «Требования к системе» имеют непосредственное отношение к отражению классификации требований.