1. Требования к системе (сайту)

	В данном разделе следует: Определить требования к системе Декомпозировать разрабатываемую систему на подсистемы Для каждой подсистемы указать ее основные функции, входные данные, выходные данные Определить интерфейсы и информационные потоки между подсистемами Ограничить функциональные рамки системы (определить требования, которые являются приоритетными для данной разработки) Определить функциональные требования Осуществить анализ категорий пользователей с детализацией требований каждой категории пользователей Указать пользовательские требования Указать основные факторы, влияющие на продукт в целом Указать нефункциональные требования Определить аппаратные и программные ограничения
		Рекомендации по ГОСТ Что с этим делать на практике Требования к системе в целом.

ГОСТ расшифровывает перечень таких требований:

• требования к структуре и функционированию системы;

• требования к численности и квалификации персонала системы и режиму его   работы;

• показатели назначения;

• требования к надежности;

• требования безопасности;

• требования к эргономике и технической эстетике;

• требования к транспортабельности для подвижных АС;

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

• требования к защите информации от несанкционированного доступа;

• требования по сохранности информации при авариях;

• требования к защите от влияния внешних воздействий;

• требования к патентной чистоте;

• требования по стандартизации и унификации;

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

• Требования к квалификации. Возможно, разрабатываемая система потребует   переподготовки специалистов. Это могут быть как пользователи будущей системы,   так и IT-специалисты, которые будут нужны для ее поддержки. Недостаточное   внимание к данному вопросу нередко перерастает в проблемы. Если квалификация   имеющегося персонала явно недостаточна, лучше прописать требования к   организации обучения, программе обучения, срокам и т.п.

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

• Требования к стандартизации. Если существуют какие-либо стандарты   разработки, которые применимы к проекту, они могут быть включены в   требования. Как правила, такие требования инициирует IT-служба Заказчика.   Например, у компании 1С есть требования к оформлению программного кода,   проектированию интерфейса и пр.;

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

Все   остальные требования менее важны и их можно не описывать. Требования к эргономике описывать в виде общих требований очень сложно, лучше   их перенести к функциональным требованиям. Например, может быть сформулировано требование   «Получить информацию о цене товара нажав только одну кнопку». Такое требование можно отнести к конкретным функциональным требованиям, хоть и относится оно  к эргономике. Функциональные требования отражают требования к функциям (задачам), выполняемым будущей системой. Вот он, тот   самый главный и ключевой пункт, который будет определять успех. Даже если все   остальное сделать на отлично, а этот раздел на «3», то и результат по проекту   будет в лучшем случае на «3», а то и вообще проект провалится. Именно эти мы   и займемся более детально во второй практической работе. В качестве требований к видам обеспечения ГОСТ выделяет такие виды:

• Математическое

• Информационное

• Лингвистическое

• Программное

• Техническое

• Метрологическое

• Организационное

• Методическое  и другие…

На первый   взгляд может показаться, что эти требования не важны. В большинстве проектов   это действительно так. Но не всегда. Когда стоит описывать данные  требования:

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

• к системе   предъявляются требования мультиязычного интерфейса (например,   русский/английский)

• для   функционирования системы должно быть создано отдельное подразделения или   приняты на работу новые сотрудники;

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

предполагается   интеграция с каким-либо оборудованием и к нему предъявляются требования   (например, сертификации, совместимости и пр.)

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

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

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