Чтобы уменьшить неоднозначность естественного языка для спецификации требований используют его сокращенную форму, что позволяет сохранить выразительность и понятность языка и структурировать описание требований.
Для структурированности языка используют стандартизованные шаблоны (схемы) и четко определенную (в спецификации) терминологию. Стандартные формы описания функциональных требований, например, должны содержать:
· описание объекта или функции;
· описание входных и выходных данных их источников и приемников;
· предусловия и постусловия функции;
· побочные эффекты и т.д.
Стандартные схемы (шаблоны) спецификаций будут рассмотрены в следующем разделе.
Языки описания программ
Дальнейшее уточнение описаний возможно путем ограничения и формализации действий, структур данных и управления, используемых в структурированном естественном языке.
Примером такого подхода является язык описания программ PDL (program description language). Этот язык строится по образцу языков программирования, управляющие операторы которых определяют:
· внешний синтаксис, т.е. описание структуры управления;
· внутренний синтаксис – описание структур данных и процедур их обработки – не определен и выбирается проектировщиком.
С одной стороны такой подход позволяет использовать в описании предложения, написанные на естественном языке, для повышения читаемости требования. С другой – использовать конструкции известных языков программирования и проверять синтаксис и семантику требований существующими программными средствами. Очевидно, что такой подход позволяет получить очень подробные и детальные требования, которые будут доступны для понимания ограниченному числу пользователей спецификации.
Пример 4.4.
Если использовать в описании процесса на PDL предложения, написанные на естественном языке, то описание будет достаточно простым для понимания. На рис. 4.7 приведено описание процесса «Принять программу в архив», рассмотренного в разделе 3.
Рис. 4.7
Графические нотации
Для описания требований применяются различные графические нотации. Наиболее часто используются уже рассмотренные графические средства: диаграммы потоков данных, модели конечных автоматов, диаграммы “сущность-связь”, сценарии, варианты использования, диаграммы использования, диаграммы состояний и диаграммы последовательности UML.
4.6. Документирование системных требований
Документирование системных требований завершает их разработку и заканчивается созданием единого документа – спецификации системных требований, – описывающего все функциональные и нефункциональные системные требования. В связи с тем, что системные требования – основа для проектирования системы и предназначены для разработчиков, то уровень их описания может быть значительно более подробным. Основные требования к спецификации системных требований – это ясность и прослеживаемость требований.
Вопросы для самоконтроля
Вопросы:
1. Модели потоков данных
2. Модели конечных автоматов
5. Документирование требований
Изучив тему, Вы будете знать:
§ Состав спецификации требований;
§ Рекомендации по разработке требований;
§ Стандартные шаблоны спецификации;
§ Особенности документирования требований в соответствии со стандартами России.
При освоении темы необходимо акцентировать внимание:
§ на содержание разделов спецификации требований;
§ рекомендации по написанию спецификации;
§ на использование стандартных шаблонов спецификаций;
§ на вопросы организации требований в спецификации.
5.1. Спецификация требований
На этапе анализа разрабатываются пользовательские и системные требования к программной системе, которые должны быть оформлены в виде единого документа – спецификации требований.
Спецификация требований – это собой итоговый набор расположенных по приоритетам требований, который является формальным соглашением заказчика с разработчиком системы.
Спецификация требований – основной документ, описывающий разрабатываемую систему, и она необходима различным группам заинтересованных лиц. Это клиенты и специалисты по продажам, менеджеры проекта, разработчики, пользователи и т.д.
Учитывая важность спецификации и различные группы ее читателей, к ней предъявляются противоположные требования. С одной стороны, она должна быть простой, ясной и понятной пользователю неспециалисту, а с другой, для разработчика, – точной, подробной и формальной. Для учета этих требований спецификация, обычно, состоит из двух частей, первая из которых описывает пользовательские требования, а вторая – системные требования.
5.2. Состав спецификации требований
Существует достаточно большое число шаблонов (схем) спецификации требований, отличающихся структурой или способом упорядочения требований. Но каждый из шаблонов требует включения в спецификацию следующей информации.
Введение
Этот раздел должен содержать обзор спецификации, позволяющий читателю разобраться в структуре и принципах ее построения. Здесь определяется специфицируемая далее система или подсистема, указывается ее редакция и версия; перечисляются стандарты, используемые при написании спецификации, а также все документы, на которые есть ссылки в спецификации.
Часто во введении приводят краткое описание концепции системы, перечисляют различные группы пользователей спецификации и приводится рекомендуемая последовательность чтения разделов для них.
Общее описание
В этом разделе должен быть представлен общий обзор продукта и той среды, в которой он будет применяться, предполагаемые пользователи, известные ограничения и зависимости. Обычно общее описание содержит следующую информацию.
Продукт. Здесь указывают особенности продукта или его основные функции, приводят основные группы требований и их взаимосвязь, используя, например, диаграмму потоков данных высокого уровня, диаграмму варианта использования и т.п.
Пользователи. Приводят перечисление классов предполагаемых пользователей и их характеристики.
Окружение. Описывают рабочую среду программной системы: аппаратные средства, операционные системы. Здесь же перечисляют другие программные компоненты, с которыми система должна быть совместима.
Ограничения реализации. Перечисляют все факторы, ограничивающие возможности разработчика, например:
· технологии, языки программирования, базы данных, стандарты разработки, которые следует (или не следует) использовать;
· ограничения операционной среды, аппаратуры;
· ограничения, связанные с продуктами, разработанными ранее;
· соглашения, связанные с пользовательским интерфейсом, форматом обмена данными и т.д.
Функции системы
Для каждой функции системы должно быть указано:
· название и приоритет;
· системные входные и выходные данные, или последовательности «воздействие – реакция»;
· детальные функциональные требования;
· реакция на ошибки ввода данных или неверные действия пользователя.
Внешний интерфейс
Раздел должен содержать описание логических характеристик каждого пользовательского интерфейса, например:
· ссылки на стандарты графического интерфейса, шрифтов, элементов управления и т.п.;
· конфигурация экрана, стандартные кнопки и функции навигации;
· стандарты отображения сообщений и т.д.
Здесь же описывают характеристики интерфейсов программных и аппаратных компонентов системы, протоколы их взаимодействия. Кроме этого – интерфейсы между системой и другими программными компонентами и интерфейсы передачи информации.
Нефункциональные требования
В этом разделе описывают остальные нефункциональные требования (не относящиеся к уже описанным требованиям к интерфейсу). Это могут быть требования к производительности, атрибуты качества продукта, требования к безопасности, охране труда и т.д.
Кроме перечисленной информации, в спецификацию требований часто включают словарь терминов, которые пользователю необходимо знать для понимания спецификации, список нерешенных проблем, связанных с требованиями и т.д.
5.3. Рекомендации по разработке требований
Не существует определенной методики написания идеальных требований. Качество требований определяется опытом и здравым смыслом. Хорошую спецификацию требований отличает технический стиль изложения и пользовательская терминология, а не компьютерный сленг [4]. Литература по разработке требований содержит большое число рекомендаций.
Приведем некоторые из них.
· Абзацы и предложения должны быть краткими и ясными. Следите за правильностью правописания, грамматики и пунктуации, используйте действительный залог (например, «Система выполнит …», а не «Произойдет …»).
· Используйте термины так, как они определены в словаре, не используйте синонимов и близких по значению слов. Не старайтесь заинтересовать читателя разнообразной лексикой и другими литературными приемами. Помните, что требования, изложенные неясным языком, не поддаются проверке.
· Нечеткие пользовательские требования должны быть детализированы так, чтобы стать ясными системными требованиями.
· Применяйте визуальное представление информации: списки, таблицы, графики, диаграммы и рисунки, чтобы не утомлять читателя большими объемами сплошного текста.
· Точно сформулированные требования повышают вероятность того, что ожидания клиентов будут реализованы; менее строгие формулировки дают разработчикам больше свободы для интерпретаций.
· Опишите отдельно требования, которые можно протестировать. Если удается придумать несколько вариантов тестирования, то необходимый уровень детализации достигнут. Если тесты многочисленны и разнообразны, то вероятно, несколько требований соединены вместе, разделите их на более простые.
· Нельзя тратить слишком много времени на попытки сделать требования идеальными. Ваша цель – написать требования, которые достаточно хороши, чтобы разработчики могли приступить к конструированию продукта при приемлемом уровне риска.
При документировании пользовательских требований можно пользоваться следующими рекомендациями:
1.Если требование независимое и простое, то оно может быть записано в виде нескольких простых предложений.
2.Если требование представляет собой взаимодействие (пользователя и системы), то его можно описать с помощью варианта использования.
3.Если требование определяет обработку данных, т.е. получение входных данных их обработку и генерацию выходных данных, то можно использовать диаграммы потоков данных.
4.Если требование определяет состояния системы, то для его фиксации можно применить конечный автомат.
Рекомендации для документирования системных требований:
1.Перед написанием спецификации системных требований необходимо выбрать стиль описания.
2.Для каждого требования нужно выполнить следующие работы:
· определить требование как функциональное или нефункциональное; оценить сложность функционального требования (требование большое – трудно управлять, очень маленькое – нет смысла рассматривать отдельно);
· сделать требование прослеживаемым и проверяемым (написать проверочный тест), доопределить требование для случая нештатных ситуаций;
· проверить недвусмысленность требования, назначить ему приоритет, проверить полноту и согласованность требования.
Дата: 2018-11-18, просмотров: 331.
