3) Анализ осуществимости.

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

2. Классификация прототипов.

Рассмотрим классификацию прототипов:

- горизонтальные и вертикальные;

- одноразовые и эволюционирующие;

- бумажные и электронные.

2.1) Горизонтальный прототип – или поведенческий прототип, - моделирует интерфейс пользовательского приложения, не затрагивая логику обработки и БД.

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

2.2) Вертикальный прототип – или структурный прототип, - не ограничивается интерфейсом пользователя, он реализует вертикальный «срез» системы, затрагивая все уровни реализации. При создании такого рода прототипов рекомендуется использовать те языки и среды реализации, что и при изготовлении целевой системы.

Основная цель – анализ применимости, проверка архитектуры концепции.

2.3) Одноразовый прототип – или исследовательский, - предназначен для создания быстрого прототипа с использованием технологии RAD.

Ключевым моментом является скорость создания.

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

Код прототипа перерастает в код приложения.

2.5) Бумажный – альтернатива при ограничении разработчика в ресурсах. Наброски интерфейса на бумаге позволяют быстро создать прототип.

2.6) Раскадровка – промежуточный вариант между электронным и бумажным вариантами. Представляет собой электронную презентацию.

Тема9: Документирование требований

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

1. Документирование требований в соответствие в гост

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

1. Структура в соответствии с гост 34.602-89

Перечислим основные разделы:

1. Общие сведения

2. Назначение и цели создания

3. Характеристика объектов автоматизации

4. Требования к системе – ключевой раздел настоящего документа, поэтому он будет рассмотрен ниже, более подробно

5. Состав и содержание работ по созданию системы

6. Порядок контроля разработки и приемки

7) Требования к составу и содержанию работ по подготовке объекта автоматизации ко вводу информационной системы в действие

8) Требования к документированию

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

Приложение: расчет ожидаемой эффективности системы и оценка научно-технического уровня системы.

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

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

1)Требования к системе в целом

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

3)Требования к видам обеспечения.

Рассмотрим их детальнее:

1)Требования к системе в целом (системные требования)

Содержат требования к:

-структуре системы

-режимам функционирования системы

-персоналу(указывается численность, требуемая квалификация и режим работы)

-надежности

-безопасности

-эргономике и технической эстетике

-эксплуатации, техническому обслуживанию , ремонту и хранению компонентов системы

-защите информации от несанкционированного доступа

-сохранности информации при авариях

-защите от влияния внешних воздействий

-патентной чистоте

-стандартизации и унификации

Дополнительно задаются:

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

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

2) Требования к функциям (задачам) подразделяются на:

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

- временной регламент реализации функциональных требований

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

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

3)Требования к видам обеспечения.

Среди видов обеспечения ГОСТ указывает:

-математическое

-информационное

-лингвистическое

-программное

-техническое

-метрологическое

-организационное

-методическое