Ведение каталога требований
Каталог требований разрабатывают с самого начала создания системы. Это соответствует стадиям "Обоснование необходимости создания и анализ реализуемости ПИ" и "Предпроектное обследование".
До стадии "Разработка технического задания" включительно все требования должны рассматриваться как неокончательные и, возможно, подлежащие пересмотру. Корректировку требований продолжают до тех пор, пока пользователи и проектировщики не придут к единому мнению, что получено полное описание того, что требуется от разрабатываемого ПИ.
По мере продвижения проекта, в каталог требований следует постоянно добавлять ссылки на вновь разрабатываемые документы, в которых реализованы те или иные требования. Это создает возможность в любой момент проследить за их соблюдением, не дожидаясь испытаний законченной системы.
Каталог требований должен включать все существенные требования, относящиеся к функционированию и способу представления информации; определять реакции программного обеспечения на всевозможные (правильные и неправильные) виды входной информации при различных ситуациях. Все рисунки, диаграммы и таблицы должны сопровождаться подробными подписями и определениями всех терминов и шкал измерения.
Карточка каталога требований предусматривает заполнение следующих граф:
ИМЯ ТРЕБОВАНИЯ - уникальный идентификатор, состоящий из буквы T (лат); односимвольного буквенного кода группы требований, присваиваемого в пределах проекта; тире и двухсимвольного порядкового номера требования, присваиваемого в пределах группы требований.
ИСТОЧНИК - лицо, документ и т.п., являющиеся источником сведений.
ВАЖНОСТЬ - приоритет (значимость) требования с точки зрения пользователя. Возможные значения: О - обязательное, Ж - желательное, Н - необязательное. К желательным необходимо относить требования, которые должны быть реализованы в следующей версии системы, к необязательным - требования, которые могут быть реализованы и в дальнейших версиях.
ОТВЕТСТВЕННЫЙ - лицо или организация, несущие ответственность за формулирование требования и возможные корректировки.
ФУНКЦИОНАЛЬНОЕ ТРЕБОВАНИЕ - содержательная формулировка автоматизируемой функции системы.
НЕФУНКЦИОНАЛЬНЫЕ ТРЕБОВАНИЯ - содержательное описание нефункциональных требований с указанием, если возможно, целевых и допустимых значений характеристик качества, а также примечания, уточняющие смысл этих требований.
ОПИСАНИЕ ТРЕБОВАНИЯ
ЦЕЛЕВОЕ ЗНАЧЕНИЕ
ДОПУСТИМОЕ ЗНАЧЕНИЕ
ПРИМЕЧАНИЕ
ВРЕМЯ РЕАКЦИИ
ЧАСЫ РАБОТЫ
ДОСТУПНОСТЬ
ПРЕИМУЩЕСТВА - краткое описание преимуществ, ожидаемых от реализации требования.
ПРЕДЛАГАЕМОЕ РЕШЕНИЕ - решение, принятое относительно данного требования.
ССЫЛКИ НА ДОКУМЕНТЫ - идентификаторы документов, имеющих какое-либо отношение к данному требованию, например, "Схема информационных потоков".
ССЫЛКИ НА ТРЕБОВАНИЯ - если различные требования влияют друг на друга или находятся в противоречии, их снабжают перекрестными ссылками, чтобы при корректировке одного требования можно было бы оценить влияние этого изменения на другое требование.
РЕЗОЛЮЦИЯ - здесь делают пометки о том, каким образом требование будет реализовано (например, помещают ссылку на "Описание функции"); если принято решение отказаться от реализации данного требования (например, на стадии выбора варианта автоматизации), то здесь указывают причины, чтобы сохранить возможность пересмотра этого решения.
При составлении описания существующей системы необходимо рассматривать требования, реализованные в этой системе и желательные требования. Для реализованных требований необходимо дополнительно указывать ограничения, налагаемые оборудованием и желательные значения параметров качества, если существующие параметры не удовлетворяют пользователей.
Для функциональных требований в графе ССЫЛКИ НА ТРЕБОВАНИЯ записывают номера нефункциональных требований по качеству выполнения рассматриваемой функции.
Требования могут быть общесистемными, к задачам, к видам обеспечения.
Формулирование требований
В связи с тем, что требования формулируют на естественном языке, одного "Каталога требований" недостаточно для точного определения требований к разрабатываемой системе. Поэтому на более поздних стадиях применяют несколько более строгих методик, в частности для определения функций и задач, а также логического и динамического моделирования данных. Все они позволяют построить подробную модель разрабатываемой системы, опираясь на соответствующие разделы "Каталога требований". Получаемый в результате пакет проектных документов - "Техническое задание" - представляет собой точное описание требований, понятное для пользователей и вполне пригодное для проектирования ПИ.
В общем случае должны быть определены назначение ПИ, выполняемые функции, характеристики пользователей, ограничения общего характера, предположения и зависимости, а также факторы, оказавшие влияние на выбор требований.
На протяжении всей разработки проектировщик должен разумно выбирать степень детализации требований, чтобы избежать неоправданного дублирования сведений, содержащихся в проектных документах, которые разрабатываются по другим методикам.
Описание требований должно задавать лишь внешнее поведение системы, не навязывая каких-либо реализаций. Вместе с тем в требованиях должны быть определены ограничения на реализацию при использовании интерфейса с аппаратурой и самой аппаратуры.
Особое внимание следует уделять обоснованию требований устойчивости структурных компонентов ПИ ко всякого рода искажающим воздействиям (сбоям в датчиках информации, ошибкам операторов, сбоям в каналах связи и вычислительных устройствах).
Требования должны быть сформулированы так, чтобы удовлетворять таким характеристикам как однозначность интерпретации, верифицируемость, модифицируемость, ясность (прослеживаемость), полезность на стадиях эксплуатации и сопровождения.
Требование обладает прослеживаемостью, если очевидны основания, вызвавшие его необходимость.
Очень важно, чтобы требования были представлены в измеримой форме. Например, в состав требования к качеству выполнения функции следует включать желаемое значение показателя качества и диапазон допустимых отклонений. Это помогает уменьшить неопределенность и дает возможность проверить, насколько система удовлетворяет сформулированным требованиям. Таким образом, определение требований способствует разработке критериев, используемых в дальнейшем при отладке и приемо-сдаточных испытаниях системы.
Следует иметь в виду, что даже довольно субъективные требования можно сделать измеримыми, хотя это не всегда очевидно. Например, к автоматизированной системе сберегательного банка можно предъявить требование: "Повысить степень удовлетворения вкладчиков". На первый взгляд, оно не является измеримым, но возможен такой критерий - число поступивших жалоб в течение одного месяца. Применение этого критерия в дальнейшем позволит заказчику оценить, в какой степени система удовлетворяет рассматриваемому требованию.