1.4.Сценарии
Люди (пользователи) часто лучше воспринимают и описывают примеры из реальной жизни, поэтому им проще ответить на вопрос "как работает система?", чем "что делает система?" Другими словами, пользователи легко понимают и могут оценить сценарий взаимодействия с программной системой, чем ее абстрактное описание.
Сценарий – это способ описания структуры задачи, представляющий собой повествовательный рассказ о совершаемых действиях, происходящих в данных временных рамках и в данном контексте [8].
Разработчики могут использовать информацию, полученную при обсуждении сценариев, для формулирования требований. Сценарии описывают последовательность работы пользователей с системой, поэтому они более полезны при детализации требований.
Первоначальное описание сценария может быть выполнено в процессе опроса заинтересованных лиц, формулирующих требования к системе.
1.4.1.Сценарии событий
Событийные сценарии (event scenarios) используются для документирования поведения системы, представленного определенными событиями. В большинстве случаев сценарий включает в себя:
Описание начального состояния системы.
Описание нормального протекания событий.
Описание исключительных ситуаций и способов их обработки.
Сведения о других действиях, которые можно выполнять во время реализации сценария.
Описание конечного состояния системы.
Описание сценария может быть представлено простым (или структурированным) текстом или при помощи схем сценариев, которые позволяют идентифицировать входные и выходные данные системы, управляющую информацию, внутрисистемные данные и исключительные ситуации [9].
2.Разработка системных требований
2.1.Детализация требований пользователей
Пользовательские требования должны быть понятны не только специалистам в области разработки программного обеспечения и поэтому пишутся обычно на естественном языке. Для разработчиков требуются более точные, структурированные, детальные требования (часто называемые системными требованиями), которые можно использовать для проектирования приложения. Для представления таких требований часто применяются графические представления, которые (совместно с текстовыми представлениями) позволяют построить модель или ряд моделей системы. Модели позволяют уточнять требования, анализировать и аттестовать их.
Системные требования состоят из полного списка конкретных свойств и функциональности, которую должна иметь программа, сформулированных в подробностях [10]
2.1.1.Модели потоков данных
Модели потоков данных – это простой и понятный способ описания последовательности обработки данных внутри системы. Для описания модели потоков данных используются диаграммы потоков данных (data flow diagram, DFD), во всем многообразии нотаций которых, можно выделить основные компоненты [5]:
процесс (трансформационный процесс, системная функция, обрабатывающая единица) – механизм, описывающий способ получения выходных данных из входных данных;
поток данных – определяющий перемещение данных (материалов) между процессами;
хранилище – места хранения данных (базы данных, например);
внешние сущности – объекты внешнего (по отношению к системе) мира.
Диаграммы потоков данных могут описывать системы на разных уровнях абстракции. Диаграммы высокого уровня предоставляют общий, целостный вид данных и процессов системы, диаграммы более низкого уровня иллюстрируют, как совмещаются функциональные требования для решения определенных задач.
Ценность моделей потоков данных в том, что они позволяют:
представить бизнес-процесс или операцию, выполняемую системой, в виде совокупности этапов;
проследить и документировать перемещение данных по системе, помогая понять этот процесс;
учитывая их простоту и понятность, использовать модели для общения с пользователями, занятыми в разработке требований;
описывать (при проектировании) принятые решения.
Наивысший уровень диаграммы потока данных – контекстная диаграмма – представляет систему, как единый процесс. Контекстная диаграмма содержит внешние, по отношению к системе, сущности, которые являются источниками или потребителями системных потоков данных. Выделив важнейшие процессы системы, можно разработать диаграмму потока данных уровня 0, в которой, кроме внешних сущностей и системных потоков данных, определенных в контекстной диаграмме, содержит эти процессы и те потоки данных, которыми они обмениваются. Каждый процесс из диаграммы нулевого уровня может быть детализирован в виде диаграммы следующего уровня (уровень 1), содержащего всю его функциональность. Детализация может быть продолжена до тех пор, пока процессы на диаграмме не станут содержать только простейшие операции. Функциональные требования в спецификации требований к системе должны точно определить, что происходит в ходе каждого простейшего процесса.
Пример 4.1.
На рис. 4.1 приведена контекстная диаграмма информационной системы архива, которая позволяет:
записывать в архив подлинники программ;
вносить в программы изменения;
выполнять тиражирование программ.
Рис. 4.1
С системой общаются:
разработчики, выдающие запросы на тиражирование программ и получающие копии программ;
сотрудники архива, выполняющие прием и регистрацию подлинников программ, и внесение в них изменений (ИИ – извещение об изменении);
магнитотека (хранилище) программ.
Единственный процесс «Обслужить» не раскрывает функций системы, поэтому для более детального описания необходима более детальная диаграмма (диаграмма 0-го уровня). На рис. 4.2 приведена диаграмма 0-го уровня, которая показывает процессы, выполняемые системой и потоки входных и выходных данных для процессов. Процессы на диаграмме нумеруются и могут, при необходимости, быть описаны более подробно на следующих уровнях детализации.
Рис. 4.2
При разработке диаграмм потоков данных следует придерживаться следующих общих правил:
размещать на диаграмме не более 7 – 10 процессов;
не загромождать диаграммы несущественными на данном уровне деталями;
декомпозицию потоков данных выполнять параллельно с декомпозицией процессов;
однократно определять функционально идентичные процессы и ссылаться на них, на нижних уровнях.