Методы первичного сбора требований. Модели системы. Языки специфики требований. Оценка требований

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

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

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

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

1. Описание функции или объекта.
2. Описание входных данных и их источники.
3. Описание выходных данных с указанием пункта их назначения.
4. Указание, что необходимо для выполнения функции.
5. Если это спецификация функции, необходимо описание предварительных условий (предусловий), которые должны выполняться перед вызовом функции, и описание заключительного условия (постусловия), которое должно быть выполнено после завершения выполнения функции.
6. Описание побочных эффектов (если они есть).

 

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

Создание  спецификаций с помощью PDL

Для уменьшения присущей естественному язык) нечеткости понятий при описании системных  требований используется специальный  язык описания программ (program description language — PDL). Этот язык подобен таким языкам программирования, как Java и Ada, но более  абстрактен. Достоинством применения PDL для создания спецификации является то, что в такой спецификации можно  проверить синтаксис и семантику  существующими программными средствами. Эти проверки позволяют удалить ошибки и несогласованность в описании требований.

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

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

 

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

Вместе с  тем подход к построению спецификаций, основанный на PDL, имеет свои недостатки:

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

 

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

Сценарии.

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

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

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

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

 

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

Сценарии событий

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

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

Варианты использования

Варианты использования (use-case) — это методика формирования требований, основанная на сценариях. Они стали основой нотаций в языке моделирования UML при описании объектных моделей систем. В самой простой форме в варианте использования определены действующие лица (в UML они называются актерами), т.е. пользователи, вовлеченные во взаимодействие, и имена типов взаимодействия. Множество вариантов использования охватывает все возможные взаимодействия, которые будут отражены в системных требованиях

Иногда неясно, является ли вариант использования сценарием  или «совокупностью сценариев» где  каждый сценарий является "нитью", проходящей через вариант использования. В последнем случае возможны сценарии для нормального взаимодействия плюс сценарии для каждого возможного исключительного случая.

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

Язык моделирования UML фактически является стандартом для объектно-ориентированного представления вариантов использования, применяемых при формировании требований.

Диаграммы потоков данных

Некоторые требования естественно  описаны потоками данных между обрабатывающими элементами. В диаграмме потоков данных узлы, отмеченные кругами или прямоугольниками, представляют обрабатывающие единицы. Стрелки между ними, подписанные типами данных, обозначают потоки данных. Хранилища данных — места, где хранятся данные, такие как базы данных — отмечены горизонтальными линиями с именем хранилища между ними. Внешние объекты, такие как пользователь и принтеры, представлены прямоугольниками.

Предположим, например, что  наш заказчик пытается объяснить  тип банковского приложения, который ему нужен, начиная с депозитов на счет. Функциями депозита могут быть получить депозит от пользователя, проверить операцию по депозиту, чтобы убедиться в ее законности. Эти функции представлены кругами на рис. 2. Далее, тип данных, передаваемых между этими функциями, отмечен на рисунке — номер счета и размер депозита. Пользователь также участвует, и это должно быть отмечено на диаграмме

 

 

 

 

Рис.2.Диаграмма потоков  данных: объяснение символов

 

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

Стандарты, используемые для символов, различаются: например, для обрабатывающих элементов часто используются прямоугольники вместо кругов.

Диаграммы переходов  состояний

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

 

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

МОДЕЛИ  СИСТЕМ

Назначение, недостатки, типы.

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

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

1. Внешнее представление, когда моделируется окружение или рабочая среда системы.
2. Описание поведения системы, когда моделируется ее поведение.
3. Описание структуры системы, когда моделируется системная архитектура или структуры данных, обрабатываемых системой.

Такие структурные методы, как структурный анализ систем и объектно-ориентированный анализ, обеспечивают основу для детального моделирования системы как части процесса постановки и анализа требований. Большинство структурных методов работают с определенными типами системных моделей. Эти методы обычно определяют процесс, который используются для построения моделей, и набор правил, которые применяются к этим моделям. Для поддержки структурных методов существуют различные CASE-средства, включающие редакторы моделей, автоматизированную систему документирования и инструменты проверки моделей.

Однако методы структурного анализа имеют ряд недостатков:

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