Документирование

ГОСТ 34.602-89. Требование к функциям.

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

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

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

действие в 1-й и последующих очередях;

2)временной регламент реализации каждой функции, задачи (или

комплекса задач);

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

4)перечень и критерии отказов для каждой функции, по которой задаются требования по надежности.

Документирование

ГОСТ 34.602-89. Требования к видам обеспечения

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

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

The IEEE 830-1994 SRS Organization

3.3.Performance requirements

3.5.Software system attributes requirements

3.6. Other requirements

Документирование Руководящие принципы при подготовке раздела «Функциональные требования».

Выделите отдельные, независимые действия (задания) из документа «Обзор продукта». Каждое из них может соответствовать отдельному функциональному требованию. Иногда несколько таких заданий могут быть объединены в одно функциональное требование.

Отделите действия, которые будут выполняться, от данных, над которыми будут выполняться действия. Данные служат входными и/или выходными для функциональных требований.

Проанализируйте список действий, заданий и данные чтобы определить рамки проекта, основываясь на «Обзоре продукта».

Используйте стандартный образец, составляя документ «Функциональные требования».

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

Убедитесь, что в «Функциональные требования» не включены детали реализации, такие, как типы параметров, формат данных, детали представления и алгоритмические детали.

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

Вам не следует предполагать какой-либо контекст, связанный с функциональным требованием. Например, вы не можете предполагать, что функциональное требование FN.1 будет вызываться из функционального требования FN.23, и, следовательно, выходной параметр функционального требования FN.1 будет использован в функциональном требовании FN.23. Как говорилось ранее, каждое функциональное требование является более или менее независимым. Все они будут связаны вместе в процессе конструирования.

Каждый из элементов данных, упомянутых в разделах «Действие», «Исключение», «Замечания» должен быть объявлен либо в разделе «Входные параметры», либо в разделе «Выходные параметры», но не в двух одновременно.

Документирование Шесть условий…

Хенингер* сформулировал шесть условий, которым должна соответствовать спецификация программной системы.

Описывать только внешнее поведение системы.

Указывать ограничения, накладываемые на процесс реализации системы.

Предусматривать возможность внесения изменений в спецификацию.

Служить справочным средством в процессе сопровождения системы.

Отображать весь жизненный цикл системы.

Предусматривать реакцию системы и группы сопровождения на непредвиденные (нештатные) ситуации.

*Heninger K. L. Specifying software requirements for complex systems. New techniques and their applications // IEEE Trans, on Software Engineering. - 1980. - SE-6(1). - P. 2- 15.

ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

(Software engineering)

Учебный курс

очного обучения по специальностям 230105 «Программное обеспечение вычислительной техники и автоматизированных систем»

010503 «Математическое обеспечение и администрирование информационных систем»

Д.П.Калачев, доц., к.т.н., доц. каф. МОП ЭВМ

ТРТУ

Разработка требований. Requirements engineering process.

Цель изучения – описать процесс разработки требований:

Знать основные процессы разработки требований.

Ознакомится с основными методами формирования и анализа требований.

Понимать важность аттестации требований.

Знать, почему необходимо управление требованиями.

Содержание:

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

Формирование (выявление) и анализ.

Аттестация.

Управление.

Разработка требований.

document

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

Началом такого анализа является общее описание системы и ее назначения, а результатом анализа -

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

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

Разработка требований.

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

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

1.Что произойдет с организацией, если система не будет введена в эксплуатацию?

2.Какие текущие проблемы существуют в организации и как новая система поможет их решить?

3.Каким образом система будет способствовать целям бизнеса?

4.Требует ли разработка системы технологии, которая до этого не использовалась в организации?

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

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

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

4.На требования к системе могут влиять политические факторы. Они могут исходить от руководителей, которые предъявляют требования только для того, чтобы усилить свое влияние в организации.

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