Методы описания требований

Как уже говорилось, главной проблемой формирования требований является взаимопонимание между пользователями и разработчиками. Язык UML был специально создан для обеспечения связи между участниками проекта. Некоторые аспекты языка нацелены на установку связи между потребителями и раз­работчиками; другие — на общение проектировщиков системы и разработчиков баз данных; третьи — на связи между разработчиками, создающими разные части систе­мы. Предлагая набор хорошо определенных диаграмм и точно определенные пояснения к ним, UML позволяет всем членам команды в любой момент понимать, что происходит в системе, и сводит к минимуму риск неправильного понимания. Де факто данный язык уже является стандартом при проектировании ИС.

Кроме того это язык, ориентированный на объектно–ориентированную методологию в отличие от большинства других стандартов и языков.

Более того, этот язык ориентирован не только на этап анализа (описания требований), но и на этап синтеза разработки проекта ИС.

Основные положения языка приведены в приложении А.

Спецификация требований

Учитывая, что системе будут предъявлены сотни, если не тысячи, требований (например, при разработке системы управления самоле­том Боинг 777 было 300 000 требований), очень важно организовать их. Поскольку невозможно удерживать в памяти более нескольких десятков фактов, для успешного взаимодействия различных участников процесса, необходимо обеспечить документирование требований. Требования следует записать так, чтобы они были доступны для ознакомления; это может быть документ, модель, база данных или листок на доске объявлений. Документ, содержащий упорядоченное множество требований называется спецификацией.

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

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

 

Аттестация требований

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

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

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

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

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

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

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

Управление требованиями

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

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

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

Пример простой матрицы зависимостей между требованиями показан в таблице 2.

U – сильная зависимость, R – косвенная зависимость

Таблица 2 Матрица оперативного контроля

 

	1.1	1.2	1.3	2.1	2.2	3.1
1.1		R	U			R
1.2	R				U
1.3
2.1			U
2.2		U		R
3.1			R

При изменении или удалении какого-нибудь требования надо изменить требование, связанное с ним.

 

Проектирование. 5

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

Предпроектные исследования. 7

Сбор и классификация требований. 7

Методы сбора требований. 8

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

Методы описания требований. 12

Спецификация требований. 13

Аттестация требований. 13

Управление требованиями. 14