Документирование требований
Аннотация: Чтобы требования, выявленные и описанные, приняли силу соглашения между Заказчиком и Разработчиком, их необходимо оформить в виде документа. Эта лекция будет посвящена документированию требований
Чтобы требования, выявленные и описанные (см. «Выявление требований» и «Классификация и специфицирование требований» ) приняли силу соглашения между Заказчиком и Разработчиком, их необходимо оформить в виде документа. В российской практике для этого обычно используется документ » Техническое задание «, ТЗ, в западной — » Software Requirements Specification «, SRS (спецификация программных требований). По сути это — один и тот же документ, поэтому далее по тексту будем употреблять термин «ТЗ», рассматривая различные шаблоны его построения — как на основе российских ГОСТ, так и западных методологий и стандартов.
SRS Согласно стандарту IEEE STD 830-1998 (http://standards.ieee.org/findstds/standard/830-1998.html), SRS — это спецификация для определенного программного изделия, программы или набора программ, которые выполняют определенные функции в специфической среде. SRS может составляться одним или более представителями поставщика, одним или более представителями заказчика, или обоими. В тексте указанного выше стандарта содержатся подробные сведения о том, как составлять SRS, а также шаблон SRS. Альтернативным источником знаний об SRS может послужить методология RUP . В русскоязычной практике данному термину приблизительно соответствует термин «Техническое задание» (ТЗ). В РФ ТЗ на создание автоматизированной системы регламентируются ГОСТ 34.602-89 [38].
Документирование требований в соответствии с ГОСТ РФ
Документирование требований регламентировано российскими ГОСТ 19.201-78 » Техническое задание , требования к содержанию и оформлению» и ГОСТ 34.602-89 » Техническое задание на создание автоматизированной системы» (ТЗ на АС ) [11.4-11.5].
Второй документ, по сути, является более проработанной версией первого, адаптированной к созданию автоматизированных информационных систем, поэтому далее рассмотрена структура ТЗ в соответствии с ГОСТ 34.602-89.
Несмотря на то, что для сферы IT 17 лет — это целая эпоха, данный документ практически не устарел: его авторам удалось разработать сбалансированные рекомендации, абстрагируясь от конкретных технических и технологических решений. Кроме того, он по -прежнему играет роль государственного стандарта РФ и при заключении контрактов с государственными предприятиями Разработчика могут обязать оформить ТЗ в соответствии с духом и буквой этого документа.
Структура ТЗ в соответствии с ГОСТ 34.602-89
В задачи лекции не входит перечисление всех правил и рекомендаций данного ГОСТ, желающие могут ознакомиться с ним непосредственно. Ниже будут перечислены разделы, предусмотренные ГОСТ и рассмотрены основные моменты, на которые следует обратить внимание.
Общие сведения — в этом разделе, помимо юридических реквизитов сторон и прочей деловой информации ГОСТ рекомендует указать источники и порядок финансирования работ.
Назначение и цели создания (развития) системы — здесь необходимо указать показатели объекта автоматизации, которые должны быть достигнуты и критерии оценки достижения этих показателей. Данным разделом на практике часто пренебрегают и совершенно напрасно — ведь именно в этом разделе закладываются высокоуровневые бизнес-требования и формулируются критерии их достижения.
Характеристика объектов автоматизации — достаточно важный раздел. Его основные «разрезы» — организационная структура, структура управления, структура расположения предприятия и его филиалов. Хорошее описание объекта автоматизации позволяет сэкономить время на определение классов пользователей, для крупных территориально-распределенных систем — заложить структуру и топологию сетевых коммуникаций.
Требования к системе — ключевой раздел настоящего документа, поэтому он будет рассмотрен ниже, более подробно.
Раздел «Состав и содержание работ по созданию системы», говоря современным языком, описывает процесс создания системы, включая выбор методологии, определяющий содержание стадий, этапов и фаз и его конкретизацию для проекта (количество этапов и итераций, их основное содержание).
Порядок контроля и приемки системы — также один из ключевых компонент ТЗ. Он распределяет роли Заказчика и Разработчика в подготовке системы к испытаниям и проведению испытаний. Здесь уместно оговорить правила проведения испытаний, сформулировать основные тестовые сценарии и критерии приемки.
Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие, опять же, аппелируя к современной терминологии, оговаривают порядок проведения реинжиниринга предприятия, который необходимо осуществить для того, чтобы добиться от внедрения АИС должного эффекта (подбор и обучение персонала, изменения в организационной структуре и т.п.).
Документ заканчивается разделами «требования к документированию» и «источники разработки», определяющими, соответственно, перечень и формы документации, подлежащей разработке и перечень уже имеющихся документов, содержащих предпосылки для разработки.
В качестве приложений ГОСТ рекомендует использовать расчет ожидаемой эффективности системы и оценку научно-технического уровня системы.
Описание требований к системе в соответствии с ГОСТ 34.602-89
ГОСТ разделяет все требования к системе на три класса:
- требования к системе в целом;
- требования к функциям (задачам), выполняемым системой;
- требования к видам обеспечения.
Среди требований к системе в целом (системные требования) указываются требования к:
- структуре системы (здесь закладываются высокоуровневые архитектурные решения, либо структурные ограничения, вводится деление на подсистемы, комплексы и модули, решаются вопросы коммуникации компонент системы и системы с внешним миром),
- режимам функционирования системы;
- персоналу (указывается численность, требуемая квалификация и режим работы);
- надежности;
- безопасности;
- эргономике и технической эстетике;
- транспортабельности для подвижных АС;
- эксплуатации, техническому обслуживанию, ремонту и хранению компонентов системы;
- защите информации от несанкционированного доступа;
- сохранности информации при авариях;
- защите от влияния внешних воздействий;
- патентной чистоте;
- стандартизации и унификации,
а также показатели назначения (параметры, характеризующие степень соответствия системы ее назначению) и дополнительные требования (распространяются на обучающие подсистемы, средства контроля работоспособности системы и др.).
Требования ГОСТ к функциям (задачам), в переводе на современный язык, подразделяются на:
- перечень функциональных требований в привязке к подсистемам и очередям автоматизации;
- временной регламент реализации функциональных требований;
- требования к качеству реализации каждого из функциональных требований (в том числе — форме представления выходной информации , характеристики необходимой точности и времени выполнения, требования одновременности выполнения группы функций, достоверности выдачи результатов);
- перечень и критерии отказов для каждого функционального требования, по которому были заданы требования по надежности.
Требования к видам обеспечения. Среди видов обеспечения ГОСТ указывает математическое, информационное, лингвистическое, программное, техническое, метрологическое, организационное, методическое.