16+
ComputerPrice
НА ГЛАВНУЮ СТАТЬИ НОВОСТИ О НАС




Яндекс цитирования


Версия для печати

Модуль поиска не установлен.

Документирование требований к ПО (часть 2)

26.06.2008

Сергей Крылов

Первую часть вы можете найти в «Компьютер Price» № 28.

Процесс документирования требований

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


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

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

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

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

 

Спецификации на естественном языке

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

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

При документировании на естественном языке необходимо руководствоваться несколькими важными правилами. Их соблюдение позволяет избежать наиболее распространенных ошибок.

 

Используйте шаблоны спецификации требований к ПО

Используйте стандартный шаблон для документирования требований к ПО. Шаблон предоставляет согласованную структуру, позволяющую фиксировать описания нужной функциональности, а также прочую информацию, касающуюся требований. Вместо того чтобы изобретать новый шаблон, модифицируйте один из существующих в соответствии со спецификой проекта. Многие компании начинают с использования шаблона спецификации требований к ПО, описанного в стандарте IEEE 830-1998 (IEEE, 1998b). Те, кто работает на российских госзаказчиков, обязательно должны ознакомиться с ГОСТом 34.602-89 и ГОСТом 19.201-78. В них указаны требования к оформлению технического задания. Если ваша компания занимается разными проектами, например, проектирует новое крупное приложение и параллельно дорабатывает версии старых программ, создайте соответствующие шаблоны для всех типов проектов. Шаблоны должны быть масштабируемыми.

 

Сопровождайте требования указанием их источников

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

 

Присваивайте требованиям уникальные идентификаторы

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

 

Указывайте количественные характеристики

Нефункциональные требования желательно сопровождать количественными характеристиками. Если речь идет о производительности системы, необходимо указать числовые значения, которых она должна достигать в определенных условиях. Требование «Система должна работать быстро» несет мало полезной информации. Требование «Cистема в базовой конфигурации должна показывать производительность 30 кадров/сек» четко указывает, к чему должны стремиться разработчики.

 

Не включайте в требования элементы дизайна

В процессе анализа требований появляется значительное число материалов, содержащих дизайн продукта. Необходимо избежать включения этой информации в спецификацию требований к ПО. Детали архитектуры и внутреннего устройства разрабатываемой системы не являются требованиями. Они разрабатываются и перерабатываются инженерами в зависимости от требований, но представляют информацию иного уровня. Требования показывают ЧТО необходимо сделать, дизайн – КАК достигнуть результата.

 

Определяйте термины в начале спецификации

Для понимания текста важно, чтобы читатель знал, что обозначает каждое слово. Поэтому в начале документа необходимо отвести место для словаря терминов. В нем должны объясняться все использованные сокращения, аббревиатуры и специальные имена. Читатель должен иметь представление о терминах до того, как углубится в изучение спецификации.

 

Используйте одинаковую форму требований

Для функциональных требований рекомендуется использовать запись в следующей форме: Триггер Объект Действие Условие.

Объект и Действие должны присутствовать обязательно. Триггер и Условие опциональны. Объект – это действующее лицо, которым может быть как элемент системы, так и внешний пользователь. Действие описывает функционал. Триггер специфицирует, что инициирует действие. Условие – это описание особенностей указанного действия. Например, «При нажатии кнопки Старт в главном окне должно появиться основное меню, если загрузка прошла без ошибок.» Здесь Триггер – «При нажатии кнопки», Объект – «в главном окне», Действие – «должно появиться основное меню», Условие – «если загрузка прошла без ошибок».

 

Используйте слово «должен»

Для того чтобы не возникало сомнений в поведении и характеристиках системы, необходимо употреблять глагол «должен» и его формы. Важно отказаться от использования других слов, являющихся более мягкими. Например, описание в будущем времени, с использованием глагола «будет» хорошо для рекламного материала, но не для руководства действиями. В требованиях, формулируемых на английском, принято употреблять слова «shall» для функциональных требований и «must» для нефункциональных. Это позволяет с первого взгляда отделять функциональную часть спецификации от нефункциональной.

 

Избегайте в требованиях негативных утверждений

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

 

Количество деталей требований может варьироваться

Один из самых сложных вопросов при описании требований на естественном языке: каков должен быть уровень детализации? Необходимо ли тщательно расписывать все нюансы продукта? Однозначного ответа на эти вопросы нет. Все зависит от проекта. Ориентируйтесь на следующие моменты:

1. Если готовится новая версия уже известного продукта, или продукт имеет широкораспространенный аналог, то вместо описания можно использовать ссылки на сходные части аналога.

2. Для опытной команды многими деталями можно пренебречь.

3. Недопонимание требований при реализации одних частей системы является критическим, других – нет. Поэтому детализация зависит от тех рисков, которые связаны с частями системы.

4. Если команда расположена в одном помещении и может свободно общаться, то важность деталей спецификации ниже, чем в случае, когда команда интернациональна и географически распределена на тысячи километров.

 

Спецификации с использованием Planguage

Многих проблем естественных языков удается избежать, если для записи требований использовать структурированные языки. Одним из таких языков является Planguage (Planning + Language), предложенный Томом Гилбом.

Использование Planguage позволяет:

– избегать упущений в требованиях;

– избегать двусмысленностей;

– обозначать реализуемость и тестируемость требований;

– повторно использовать требования или их части;

– управлять приоритетами;

– принимать обоснованные решения.

Planguage состоит из двух наборов ключевых слов – один для описания функциональных требований, другой – нефункциональных. Каждое требование представляет из себя запись в форме: <ключевое слово 1><описание>…<ключевое слово N><описание>

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

 

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

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

Tag (таг) – уникальный, неизменный идентификатор

Gist (суть) – название требования, раскрывающее его сущность

Requirement (требование) – описание требования со всеми необходимыми деталями

Rationale (обоснование) – обоснование необходимости требования

Priority (приоритет) – приоритет требования

Stakeholders (участники) – заинтересованные лица, для которых важно требование

Owner (владелец) – лицо, ответственное за имплементацию требования

Author (автор) – лицо, записавшее требование

Revision (версия) – версия требования

Date (дата) – дата записи последней версии

Assumptions (предположения) – все предположения о проблемах, которые связаны с требованием

Risks (риски) – все, что может негативно сказаться на результате имплементации требования

Defined (определения) – определение термина

Ниже приведен пример требования записанного на Planguage.

 

Ключевое слово

Описание

Tag

REQ1000

Gist

Создать новый документ

Requirement

При выборе пункта меню File/New в папке новых документов создается новый документ с именем New Document N, где N уникальный номер документа, не совпадающий с уже присутствующими в папке.

Rationale

Необходимо иметь возможность создавать новые документы

Priority

Наивысший

Revision

1.0

Author

Иванов И.И.

Date

15 марта 2007

Assumptions

Без этого требования нормальное функционирование продукта невозможно

 

Таблица 1

 

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

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

Ambition (назначение) – описание цели требования

Scale (шкала) – шкала, используемая для количественной характеристики требования

Meter (измеритель) – процесс или устройство, используемые для установления количественной характеристики

Minimum (минимум) – минимальное допустимое значение количественной характеристики

Target (цель) – значение количественной характеристики, при котором требование считается реализованным хорошо

Outstanding (достижение) – наилучшее значение количественной характеристики, которое может быть достигнуто, если все будет реализовано наилучшим образом

Wish (идеал) – значение количественной характеристики, к которому надо стремиться, но достигнуть которого практически невозможно

Past (прошлое) – предыдущий результат, который можно использовать для сравнения с текущим.

Trend (тенденция) – массив исторических данных по развитию требования

Record (рекорд) – лучший достигнутый результат в индустрии

Ниже приведен пример нефункционального требования записанного на Planguage.

 

Ключевое слово

Описание

Tag

REQ EDITOR LAUNCH TIME

Gist

Время подготовки редактора для полноценной работы

Requirement

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

Ambition

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

Priority

Высокий

Revision

1.0

Author

Иванов И.И.

Date

16 марта 2007

Assumptions

Без выполнения этого требования возможны проблемы со сбытом продукта.

Scale

Секунды

Meter

Тест на время запуска редактора

Minimum

60 сек в мин. конфигурации

Target

45 сек в мин. конфигурации

Record

Продукт конкурентов показывает на тесте 57 сек.

 

Таблица 2

 

Формальные спецификации

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

Существует значительное число различных нотаций для записи четко формализованных требований. Наиболее известные – Z, VDM, LOTOS, B.

 

Z

Z является формальной нотацией, базирующейся на предикативной логике первого порядка и на теории Зермело-Франкеля (Zermelo-Fraenkel). Она была разработана Исследовательской группой по программированию Оксфордского университета в конце 70-х годов прошлого века. С тех пор Z активно используется промышленными предприятиями Европы и Америки (например IBM и British Telecom) при проектировании высокоточных систем. В 2002 году Z была стандартизована ISO, что усилило интерес к технологии со стороны индустриальных гигантов.

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

Основная задача Z-спецификации описать ЧТО надо делать, а не КАК. Поэтому нотация Z сконструирована так, чтобы прежде всего быть выразительной и понятной, а уже затем выполнимой. Это не означает, что на Z нельзя написать выполнимую спецификацию. Просто, в отличие от алгебраических языков программирования, акцент нотации смещен в сторону человеческой, а не машинной логики.

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

Математические обозначения базируются на общепринятых понятиях предикативной логики. Например, конъюнкция записывается как p ^ q, дизъюнкция – p V q и т.п. Кроме того, используются элементы теории множеств Зермело-Франкеля. Названия множеств записываются заглавными буквами. Например A. В Z они, как правило, служат для типизации переменных. Каждая переменная Z спецификации принадлежит какому-либо типу. Для множеств в математике определено значительное число операций, таких как объединение, отображение, исключение и т.д. Известны теоремы, описывающие аспекты взаимоотношений множеств. Весь этот богатый аппарат может быть задействован в Z-спецификации.

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

 

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

Основные достоинства Z следующие:

1. Нотация позволяет создавать спецификации, которые легко читать.

2. Благодаря схематическим обозначениям легко ориентироваться в больших спецификациях.

3. Нотация широко распространена в промышленности.

4. Доступно значительное количество учебных материалов по Z.

К недостаткам Z следует отнести:

1. Трудно описывать одновременные процессы.

2. Необходимо знание математики на уровне выше среднего.

Логическим развитием рассматриваемой нотации стала Z++. Это объектно-ориентированное расширение Z, приспособленное для нужд ООП.

 

VDM (Vienna Development Method)

Метод VDM был разработан в 1973-75 гг. в Венской лаборатории корпорации IBM на основе VDL (Vienna Definition Language). В дальнейшем метод дорабатывался в различных вузах мира, включая Копенгагенский, Оксфордский и Манчестерский университеты. В дальнейшем он получил признание в таких промышленных корпорациях, как Boeing, British Aerospace, Aerospatiale, Dassault, Matra, Alcatel. В 1996 году VDM был стандартизован ISO.

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

В настоящее время в качестве нотации VDM используется язык VDM-SL. Он базируется на понятиях математической логики. VDM предписывает специфицировать системы в терминах функций, обрабатывающих данные. Таким образом, две основных составляющих VDM-SL: нотации для описания данных и нотации для описания функций.

Все типы данных основываются на 9 базовых типах.

 

bool

Булевы значения

nat

Натуральные числа (включая ноль)

nat1

Натуральные числа (исключая ноль)

int

Целые

rat

Рациональные числа

real

Действительные числа

char

Буквы

token

Неструктурированные токены

<A>

Тип, содержащий элемент <A>

Таблица 3

 

Из базовых типов можно создавать сложные типы, такие как союзы, множества, последовательности и т.п.

Особенность функций в VDM-SL заключается в том, что для поддержания высокого уровня абстракции должно быть возможно характеризовать результат выполнения функции без описания того, как получается этот результат. Основным способом добиться этого является спецификация неявных функций, в которых вместо формулы для вычисления результата приводятся логический предикат ввода и результирующие выражения, называемые постусловиями. Например, функция вычисления квадратного корня на VDM-SL будет выглядеть следующим образом:

 

SQRT(x:nat)r:real

post r*r = n

 

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

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

 

SQRTP(x:real)r:real

pre x >=0

post r*r = n and r>=0

 

В этой функции аргумент x должен быть больше или равным нулю. Иначе функция неприменима.

Основные достоинства VDM следующие:

1. Нотация позволяет создавать спецификации без указания алгоритмов выполнения.

2. Допустимо определение рекурсивных функций.

3. Нотация широко распространена в промышленности.

4. Доступно значительное количество учебных материалов по VDM.

К недостаткам VDM следует отнести:

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

2. Необходимо знание математики на уровне выше среднего.

Логическим развитием рассматриваемого метода стал VDM++. Это объектно-ориентированное расширение VDM, приспособленное для нужд ООП.

Описанные технологии применяются на фазе специфицирования требований. В следующей статье мы рассмотрим методы верификации документации.



статьи
статьи
 / 
новости
новости
 / 
контакты
контакты