Проектирование ИС

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

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

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

      На  сегодня в арсенале аналитика  существуют десятки методик, языков, визуальных представлений, позволяющих  моделировать требования к системе. При создании ИС стандартом де-факто  является универсальный язык моделирования UML.

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

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

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

      Во-вторых, анализ требований должен находить ответ  на то, ЧТО делает система, абстрагируясь от деталей реализации, т.е. того, КАК она это делает. Поэтому, допустим, диаграмма взаимодействия объектов, реализующих тот или иной вариант использования, можно рассматривать скорее, как иллюстрацию внутреннего устройства системы, полезную для программиста, чем модель для заказчика.

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

  Иллюстрированные  сценарии и прототипы

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

      Рассмотрим  основные цели, требующие применения прототипов:

• прояснить неясные требования к системе;
• выбрать одно из различных концептуальных решений;
• проанализировать осуществимость.
1. Неясные требования. Часто Заказчику бывает трудно сформулировать требования к тому, что он ожидает от системы. В этом случае прототип интерфейса пользователя (User Interface, UI), оперативно созданный по результатам интервью, дает ему возможность увидеть схематичную реализацию того, как Исполнитель увидел соответствующую часть системы. Что интересно - в данном случае полезен любой исход прототипирования: если Исполнитель понял требования хорошо - польза очевидна; если не очень - польза заключается в том, что Заказчик может указать, в чем заключается непонимание, тем самым решив основную задачу - сделать неясное ясным.
2. Разные варианты решения. Любую техническую задачу можно решить различными способами. Это касается как задачи формулировки требований, так и ее реализации в UI.
3. Анализ осуществимости. Часто бывает так, что комбинация функциональных, нефункциональных требований и ограничений такова, что возникает риск невозможности их реализации. Как правило, такой риск связан с требованиями к быстродействию системы при известных ограничениях среды ее реализации. В этом случае создаются прототипы (не обязательно, связанные с UI), реализующие соответствующую часть системы, имитирующие потоки данных, поступающие на ее вход и их обработку.

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

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

      Чтобы требования, выявленные и описанные приняли силу соглашения между Заказчиком и Разработчиком, их необходимо оформить в виде документа. В российской практике для этого обычно используется документ "Техническое задание", ТЗ, в западной - "Software Requirements Specification", SRS (спецификация программных требований).

Документирование  требований в соответствие с ГОСТ РФ

      Документирование  требований регламентировано российскими  ГОСТ 19.201-78 "Техническое задание, требования к содержанию и оформлению" и ГОСТ 34.602-89 "Техническое задание на создание автоматизированной системы" (ТЗ на АС).

      Второй  документ, по сути, является более проработанной  версией первого, адаптированной к  созданию автоматизированных информационных систем, поэтому далее рассмотрена  структура ТЗ в соответствие с ГОСТ 34.602-89.

      Несмотря  на то, что для сферы IT 17 лет - это  целая эпоха, данный документ практически  не устарел: его авторам удалось  разработать сбалансированные рекомендации, абстрагируясь от конкретных технических  и технологических решений. Кроме  того, он по-прежнему играет роль государственного стандарта РФ и при заключении контрактов с государственными предприятиями Разработчика могут обязать оформить ТЗ в соответствии с духом и буквой этого документа.

Описание  требований к системе  в соответствие с ГОСТ 34.602-89

ГОСТ  разделяет все требования к системе  на три класса:

• требования к системе в целом;
• требования к функциям (задачам), выполняемым системой;
• требования к видам обеспечения.

      Среди требований к системе в целом (системные требования) указываются требования к:

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

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

      Требования ГОСТ к функциям (задачам), в переводе на современный язык, подразделяются на:

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

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

Документирование  требований на основе IEEE Standard 830-1998

1. Введение

1.1 Назначение  документа.

1.2. Поддерживаемые  соглашения.

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

1.4. Границы  проекта. Здесь содержится ссылка  на документ "Концепция", если   таковой имеется, либо краткое резюме продукта.

1.5. Ссылки.

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

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

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

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

2.4. Операционная  среда. Рассматривается среда  функционирования АИС, включая  аппаратные средства, операционные  системы, для распределенных систем - географическое расположение пользователей и серверов, топология сети.

2.5. Ограничения  проектирования и реализации. Рассмотрим  классификацию ограничений:

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

2.6 Документация  для пользователей.

2.7 Предположения и зависимости

3. Функции системы. Для каждой i-й функции составляется следующее описание.

З.i Наименование i-й функции системы.

З.i.1 Описание и приоритеты. Приводится краткое  описание функции и указывается  ее приоритет (степень важности/очередности  реализации).

З.i.2 Последовательности "воздействие - реакция". Необходимо перечислить последовательность воздействий, оказываемых на систему (действия пользователей, сигналы внешних устройств и  др.), и отклики системы, определяющие реакцию конкретной функции.

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