Структурированный естественный язык

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

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

· описание объекта или функции;

· описание входных и выходных данных их источников и приемников;

· предусловия и постусловия функции;

· побочные эффекты и т.д.

Стандартные схемы (шаблоны) спецификаций будут рассмотрены в следующем разделе.

Языки описания программ

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

Примером такого подхода является язык описания программ PDL (program description language). Этот язык строится по образцу языков программирования, управляющие операторы которых определяют:

· внешний синтаксис, т.е. описание структуры управления;

· внутренний синтаксис – описание структур данных и процедур их обработки – не определен и выбирается проектировщиком.

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

Пример 4.4.

Если использовать в описании процесса на PDL предложения, написанные на естественном языке, то описание будет достаточно простым для понимания. На рис. 4.7 приведено описание процесса «Принять программу в архив», рассмотренного в разделе 3.

Рис. 4.7

Графические нотации

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

4.6. Документирование системных требований

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

Вопросы для самоконтроля

1. Для кого преимущественно создаются системные требования?

2. У типичной программы есть несколько требований. Какая важная проблема существует при создании и работе с требованиями?

3. Какие категории системных требований должны быть описаны в спецификации?

4. Какими желательными свойствами должны обладать системные требования?

5. Чем характеризуются системные модели, используемые на этапе анализа?

6. Как выбирать тип модели для уточнения пользовательских требований?

7. Как методика прототипирования (экспериментального и эволюционного) связана с видом прототипа?

8. Какие средства существуют для описания системных требований?

5. Документирование требований

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

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

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

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

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

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

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

Введение

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

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

Общее описание

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

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

Пользователи. Приводят перечисление классов предполагаемых пользователей и их характеристики.

Окружение. Описывают рабочую среду программной системы: аппаратные средства, операционные системы. Здесь же перечисляют другие программные компоненты, с которыми система должна быть совместима.

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

· технологии, языки программирования, базы данных, стандарты разработки, которые следует (или не следует) использовать;

· ограничения операционной среды, аппаратуры;

· ограничения, связанные с продуктами, разработанными ранее;

· соглашения, связанные с пользовательским интерфейсом, форматом обмена данными и т.д.

Функции системы

Для каждой функции системы должно быть указано:

· название и приоритет;

· системные входные и выходные данные, или последовательности «воздействие – реакция»;

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

· реакция на ошибки ввода данных или неверные действия пользователя.

Внешний интерфейс

Раздел должен содержать описание логических характеристик каждого пользовательского интерфейса, например:

· ссылки на стандарты графического интерфейса, шрифтов, элементов управления и т.п.;

· конфигурация экрана, стандартные кнопки и функции навигации;

· стандарты отображения сообщений и т.д.

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

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

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

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

5.3. Рекомендации по разработке требований

Не существует определенной методики написания идеальных требований. Качество требований определяется опытом и здравым смыслом. Хорошую спецификацию требований отличает технический стиль изложения и пользовательская терминология, а не компьютерный сленг [4]. Литература по разработке требований содержит большое число рекомендаций.

Приведем некоторые из них.

· Абзацы и предложения должны быть краткими и ясными. Следите за правильностью правописания, грамматики и пунктуации, используйте действительный залог (например, «Система выполнит …», а не «Произойдет …»).

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

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

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

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

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

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

При документировании пользовательских требований можно пользоваться следующими рекомендациями:

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

2. Если требование представляет собой взаимодействие (пользователя и системы), то его можно описать с помощью варианта использования.

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

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

Рекомендации для документирования системных требований:

1. Перед написанием спецификации системных требований необходимо выбрать стиль описания.

2. Для каждого требования нужно выполнить следующие работы:

· определить требование как функциональное или нефункциональное; оценить сложность функционального требования (требование большое – трудно управлять, очень маленькое – нет смысла рассматривать отдельно);

· сделать требование прослеживаемым и проверяемым (написать проверочный тест), доопределить требование для случая нештатных ситуаций;

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