Проверяемость и прослеживаемость.

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

1.3. Особенности разработки требований к программным
системам

Разработка требований – это первый из основных процессов создания программных систем. Этот процесс состоит из следующих основных этапов (см. рис. 1.2).

 

Рис. 1.2

1. Анализ предметной области.

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

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

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

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

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

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

К особенностям разработки требований относятся:

1. Сложность процесса.

2. Итеративность процесса.

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

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

Сценарии

Люди (пользователи) часто лучше воспринимают и описывают примеры из реальной жизни, поэтому им проще ответить на вопрос "как работает система?", чем "что делает система?" Другими словами, пользователи легко понимают и могут оценить сценарий взаимодействия с программной системой, чем ее абстрактное описание.

Сценарий – это способ описания структуры задачи, представляющий собой повествовательный рассказ о совершаемых действиях, происходящих в данных временных рамках и в данном контексте [8].

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

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

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

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

· Описание начального состояния системы.

· Описание нормального протекания событий.

· Описание исключительных ситуаций и способов их обработки.

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

· Описание конечного состояния системы.

Описание сценария может быть представлено простым (или структурированным) текстом или при помощи схем сценариев, которые позволяют идентифицировать входные и выходные данные системы, управляющую информацию, внутрисистемные данные и исключительные ситуации [9].

2. Разработка системных требований

2.1. Детализация требований пользователей

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

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

Модели потоков данных

Модели потоков данных – это простой и понятный способ описания последовательности обработки данных внутри системы. Для описания модели потоков данных используются диаграммы потоков данных (data flow diagram, DFD), во всем многообразии нотаций которых, можно выделить основные компоненты [5]:

· процесс (трансформационный процесс, системная функция, обрабатывающая единица) – механизм, описывающий способ получения выходных данных из входных данных;

· поток данных – определяющий перемещение данных (материалов) между процессами;

· хранилище – места хранения данных (базы данных, например);

· внешние сущности – объекты внешнего (по отношению к системе) мира.

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

Ценность моделей потоков данных в том, что они позволяют:

· представить бизнес-процесс или операцию, выполняемую системой, в виде совокупности этапов;

· проследить и документировать перемещение данных по системе, помогая понять этот процесс;

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

· описывать (при проектировании) принятые решения.

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

Пример 4.1.

На рис. 4.1 приведена контекстная диаграмма информационной системы архива, которая позволяет:

· записывать в архив подлинники программ;

· вносить в программы изменения;

· выполнять тиражирование программ.

Рис. 4.1

С системой общаются:

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

· сотрудники архива, выполняющие прием и регистрацию подлинников программ, и внесение в них изменений (ИИ – извещение об изменении);

· магнитотека (хранилище) программ.

Единственный процесс «Обслужить» не раскрывает функций системы, поэтому для более детального описания необходима более детальная диаграмма (диаграмма 0-го уровня). На рис. 4.2 приведена диаграмма 0-го уровня, которая показывает процессы, выполняемые системой и потоки входных и выходных данных для процессов. Процессы на диаграмме нумеруются и могут, при необходимости, быть описаны более подробно на следующих уровнях детализации.

 

Рис. 4.2

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

· размещать на диаграмме не более 7 – 10 процессов;

· не загромождать диаграммы несущественными на данном уровне деталями;

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

· однократно определять функционально идентичные процессы и ссылаться на них, на нижних уровнях.

Модели конечных автоматов

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

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

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

Пример 4.2.

На рис. 4.3 приведена диаграмма конечного автомата, описывающего процесс «Принять программу в архив».

Рис. 4.3

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

Прототипы

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

2.2.1. Роль прототипов при разработке требований

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

Прототип полезен в решения следующих задач:

1. Разработка требований.

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

2. Проверка требований.

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

3. Разработка взаимодействия с пользователем.

Прототип позволяет реализовать различные варианты взаимодействия, исследовать альтернативные решения и выбрать оптимальный вариант.

4. Спецификация системных требований.

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

Виды прототипов

Горизонтальные прототипы

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

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

Вертикальные прототипы

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

Разработка прототипов

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