Стандарт ieee 830-1998

Стандарт IEEE 830-1998

(Пересмотр стандарта IEEE 830-1993)

Методика составления спецификаций требований к программному обеспечению, рекомендуемая Институтом Инженеров по Электротехнике и Радиоэлектронике (IEEE)

Организатор

Комитет по Стандартам Разработок Программного Обеспечения Компьютерного Общества IEEE

Утверждено 25 июня 1998 Совет по Стандартам IEEE-SA

Выдержка: Описывается содержание и качественные характеристики правильно составленной спецификации требований к программному обеспечению (SRS) и приводится несколько образцовых SRS. Данная рекомендуемая методика имеет своей целью установление требований к разрабатываемому программному обеспечению, но также может применяться, чтобы помочь в выборе собственных и коммерческих программных изделий. Также приведены указания по согласованию со стандартом IEEE/EIA 12207.1-1997.

Ключевые слова: контракт, заказчик, макетирование, спецификация требований к программному обеспечению, поставщик, спецификации требований к системе.

Институт Инженеров по Электротехнике и Радиоэлектронике, Инк., 345 East 47^th, New York, NY 10017-2394, USA

ISBN 0-7381-0332-2

Никакая часть данной публикации не может быть воспроизведена в любом виде на любой электронной информационно-поисковой системе или другим способом без предварительного письменного разрешения издателя

Документы по Стандартам IEEE были разработаны Обществами IEEE и Координирующими

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

Использование Стандарта IEEE является полностью добровольным. Существование Стандарта IEEE не подразумевает, что отсутствуют какие-либо другие способы создания, тестирования, измерений, приобретения, коммерческой продажи или поставки других товаров и услуг, относящихся к области действия Стандарта IEEE. Кроме того, точка зрения, выраженная при утверждении и издании стандарта, подлежит изменениям, вызванным развитием современного уровня техники и комментариями, полученными от пользователей стандарта. Каждый Стандарт IЕЕЕ подлежит проверке, по крайней мере, один раз в пять лет с целью пересмотра или повторного подтверждения. Если срок действия документа составил более пяти лет, и он не прошел повторного подтверждения, то можно обоснованно заключить, что его содержание, хотя все еще и имеет некоторую ценность, не отражает полностью текущий уровень развития техники. Пользователям рекомендуется убедиться, что они имеют последнее издание любого из Стандартов IEEE.

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

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

Комментарии по стандартам и запросы, касающиеся интерпретации, следует отправлять по адресу:

Secretary, IЕЕЕ-SA Standards Board (Секретарю Совета по Стандартам IEEE-SA)

445 Hoes Lane

P.O. Box 1331

Piscataway, NJ 08855-1331

USA

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

Разрешение на фотокопирование частей любого отдельного стандарта для внутреннего или персонального использования предоставляется Институтом Инженеров по Электротехнике и Радиоэлектронике, Инк. при условии уплаты соответствующего взноса в Центр Расчетов по Авторским Правам. По вопросам уплаты лицензионного гонорара, пожалуйста обращайтесь в Центр Расчетов по Авторским Правам, Отдел,обслуживания заказчиков, 222 Rosewood Drive, Danvers, MA 01923 США; (978) 750-8400. Разрешение на фотокопирование частей любого отдельного стандарта для использования в образовательных классах может также быть получено через Центр Расчетов по Авторским Правам.

Введение

(Это введение не является частью стандарта IEEE 830-1998, Методика составления спецификаций требований к программному обеспечению, рекомендуемая IEEE.)

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

а) Заказчикам программного обеспечения точно описать, что они хотят получить;

б) Поставщикам программного обеспечения точно понять, что хочет заказчик;

в) Отдельным лицам выполнить следующие задачи:

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

Качественно составленная SRS должна принести заказчикам, поставщикам и другим лицам некоторые определенные выгоды, а именно:

Создать основу для соглашения между заказчиками и поставщиками по вопросу о том, какие функции должно выполнять программное изделие. Полное описание функций программного обеспечения, приведенное в SRS, поможет потенциальным пользователям определить, отвечает ли программное обеспечение их потребностям или как необходимо изменить программное обеспечение, чтобы удовлетворить эти потребности.
Уменьшить объем работ по разработке. Подготовка SRS вынуждает различные участвующие
группы организации заказчика строго рассмотреть все требования прежде, чем приступать к выполнению проекта, и сокращает последующие повторные проектирование, кодирование и тестирование. Тщательный анализ требований, указанных в SRS, может вскрыть упущения, неправильное понимание и противоречия, допущенные на стадии разработки, когда их проще исправить.
Обеспечить основу для оценки расходов и планов. Описание программы, разрабатываемой в соответствии с SRS, является практической основой для оценки затрат на проект и может использоваться для утверждения проекта на основании этих оценок.

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

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

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

В Приложении Б читатели этого документа найдут руководящие указания по использованию данной рекомендуемой методики в отношении соответствия требованиям стандартов IEEE/EIA 12207.1-1997, Руководство IEEE/EIA - Промышленная реализация ISO/IEC 12207: 1995, Стандарт Информационных Технологий - Процессы жизненного цикла программного обеспечения - Данные жизненного цикла.

Участники

Эта рекомендуемая методика была подготовлена Рабочей Группой по Гармонизации Данных Жизненного Цикла, входящей в состав Комитета по Разработке Стандартов Программного Обеспечения Компьютерного Общества ШЕЕ. На момент утверждения данной методики рабочая группа состояла из следующих членов:

Леонард Л. Трипп, Председатель

Эдвард Бирн

Пол Р. Кролл

Перри Де Вис

Робин Фрэлик

Мэрилин Гинсберг-Финнер

Джон Харас

Марк Хэнли

Деннис Лоуренс Дэвид Мэйбор Рэй Милованович Джеймс Мур Тимоти Нисен Деннис Рилинг

Терри Роут Ричард Шмидт Норман Ф. Шнейдевинд Дэвид Шультц Бэзил Шерлунд Петер Вольднер Рональд Уэйд

Следующие лица вошли в состав комитета по голосованию:

Сиед Али

Теодор К. Аткинсон

Майкл Аугустон

Роберт Е. Барри

Лео Белтраччи

X. Рональд Берлак

Ричард И. Бил

Майкл А. Блэклэдж

Сандро Болонья

Юрис Борзовс

Кэтлин Л. Бриггс

М. Скотт Бак

Майкл Калдуэлл

Джеймс Е. Кардоу

Энрико А. Карраро

Лоуренс Кэтчпол

КэйтЧан

Антонио М. Сику

Тео Кларк

Сильвайн Клермонт

Розмари Коулман

В ирджил Ли Купер

В,В, Джефф Козенс

Пол Р. Кролл

Грегори Т. Дэйч

Джеффри Дарнтон

Таз Дотри

Востиан К. Дерганк

Перри Р. Де Вис

Джеймс До

Эвелин С. Доу

Карл Эйнар Драгстедт

Шерман Игле

Кристоф Эберт

Лео Эган

Ричард Е. Фэйрли

Джон У. Фендрик

Джей Форстер

Кирби Фортенберри

Эва Фройнд

Ричард К. Фрис

Роджер Ю. Фуджи

Адель Н. Ганнам

Мэрилин Гинсберг-Финнер

Джон Гарт Глинн

Джулио Гонзалес Санц

Л. М. Гюнтер

Дэвид А. Густафсон Джон Д.. Хагар Джон Харас Роберт Т. Харли Герберт Хехт Уидьям Хэфли Манфред Хайн Марк Хайнрих Марк Хэнли Дебра Херманн Джон У. Хорх Джерри Хуллер Петер Л. Ханг Джордж Джэклин Фрэнк В. Иоргенсен Уильям С. Джанк Джордж К. Камбик Ричард Карчич Рон С. Кеннет Юдит С. Кернер Роберт Дж. Кирзик Дуэйн Л. Книрк Шайе Кёниг Томас М. Курихара Джон Б. Лэйн Дж. Деннис Лоуренс Фанг Чинг Лим Уильям М. Ливли Джеймс Дж. Лонгбакко Дитер Лук Джон Лорд Стэн Маги Дэвид Мэйбор Гарольд Мэйнс Роберт А. Мартин Томо Мацубара Майк МакЭндрю Патрик Д. МакГрэй Кристофер МакМакен Джером У. Мерски Брет Майкл Алан Миллер Селиа X. Моделл Джеймс У. Мур Павол Наврат Мирна Л. Олсон

Индрадеб П. Пал Алекс Полак Петер Т. Пун

Лоуренс С. Пржибильский Кеннет Р. Птак Аннет Д. Рэйли Деннис Риллинг Эндрю П. Сэйдж Гельмут Сандмайер Стефен Р. Шах Ханс Шафер Норман Шнейдевинд Дэвид Дж. Шультц Лиза А. Селмон Роберт У. Шиллато Дэвид М. Зиверт Карл А. Сингер Джеймс М. Сивак Ричард С. Скай Нэнси М. Смит Мэлфорд Е. Смир Гарри М. Снид Алфред Р. Сорковитц Дональд У. Сова Лука Споторно Джулиа Стэсни Фред Дж. Страусе Кристин Браун Страйсик Тору Такешита Ричард X. Тайер Букер Томас Патриция Треллу Теодор Дж. Урбанович Гленн Д. Венэблс Удо Вогес Дэвид Д. Уолден Долорес Уэллас Уильям М. Уолш Джон У. Уолс Камил С. Уайт-Партайн Скотт А. Витмайр П. А. Вольфганг Пол Р. Уорк Натали К. Йопконка Януш Залевски Джеральдин Зиммерман Петер Ф. Золль

На момент утверждения данной методики 25 июня 1998 года в состав Совета по Стандартам IEEE входили:

Ричард Дж. Холлеман, Председатель Дональд Н. Хэйрман Вице-председатель

Юдит Горман, Секретарь

Сатиш А. Аггарвал Клайд Р. Кэмп Джеймс Т. Карло Гари Р. Энгман Гарольд И. Эпстайн Джей Форстер* Томас Ф. Гаррити Рубен Д. Гарзон

Джеймс X. Гарни Джим, Д Исаак Лоуэлл Г. Джонсон Роберт Кенелли И. Г. "Аль" Кинер Джозеф Л. Копфингер* Стефан Р. Ламберт Джим Логотетис Дональд К. Логри

Л. Брюс МакКланг Луи-Франк По Рональд К. Петерсен Джеральд X. Петерсон Джон Б. Рози Гари С. Робинсон Ганс И. Вайнрих Дональд У. Зипс

*3аслуженный член в отставке

Валери И. Зеленти Редактор Проекта Стандартов IEEE

Содержание

1.Краткий обзор 1

1.1 Область действия 1

Публикации 2
Определения 2
Критерии получения качественной SRS 3

Сущность SRS 3
Среда SRS 3
Характеристики качественной SRS 4
Совместная подготовка SRS 8
Развитие SRS 8
Макетирование 9
Встраивание структуры в SRS 9
Встраивание требований проекта в SRS 10

5. Разделы SRS 10

Введение (Раздел 1 SRS)…………………………………………………………………….……..11
Общее описание (Раздел 2 SRS) 12
Специфические требования (Раздел 3 SRS) 15
Дополнительная информация 19

Приложение А (информационное) Шаблоны SRS 21

Приложение Б (информационное) Указания по соответствию стандарту

IEEE/EIA 12207/1-1997 ..... 27

Методика составления спецификаций требований к программному обеспечению, рекомендуемая IEEE

1. Краткий обзор

Данная методика описывает рекомендуемые принципы составления спецификации требований к программному обеспечению. Она разделена на пять разделов. Раздел 1 указывает область действия этой методики. В разделе 2 перечисляются ссылки на другие стандарты. В разделе 3 даны определения используемых терминов. Раздел 4 предоставляет предварительную информацию для составления качественной SRS. В разделе 5 обсуждается каждая из необходимых частей SRS. Данная методика имеет два приложения; в одном из них приведены альтернативные шаблоны формата, а в другом обеспечиваются указания по обеспечению соответствия со стандартом IEЕЕ/ЕIА 12207.1-1997.

1.1 Область действия

Этот документ представляет рекомендуемую методику составления спецификаций требований к программному обеспечению. В нем описываются содержание и качественные характеристики правильно составленной спецификации требований к программному обеспечению (SRS) и представлено несколько типовых образцов SRS.

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

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

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

Данная методика не определяет какой-либо конкретный метод, терминологию или инструмент для подготовки SRS.

Стандарт IEEE 830-1998 Методика составления спецификаций требований к программному обеспечению

(Пересмотр стандарта IEEE 830-1993)

2. Публикации

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

ASTM Е1340-96, Руководство по стандартам по быстрому макетированию компьютеризованных систем.¹

Стандарт IEEE 610.12-1990, Глоссарий стандартов IEEE по терминологии разработок программного обеспечения.²

Стандарт IEEE 730-1998, Стандарт IEЕЕ по планам обеспечения качества программных средств.

Стандарт IEEE 730.1-1995, Руководство IEЕЕ по планированию обеспечения качества программных средств.

Стандарт IEEE 828-1998, Стандарт IEЕЕ по проектам управления конфигурацией программного обеспечения³

Стандарт IEEE 982.1-1988, Словарь стандартов IEЕЕ по критериям создания надежного программного обеспечения.

Стандарт IEEE 982.2-1988, РуководствоIEЕЕ по использованию словаря стандартов IEЕЕ по критериям создания надежного программного обеспечения.

Стандарт IEЕЕ 1002-1987 (Повторно подтвержден в 1992), Классификация и систематизация Стандартов IEЕЕ для стандартов разработок программного обеспечения.

Стандарт IEЕЕ 1012-1998, Стандарт IEEE по аттестации и верификации программного обеспечения.

Стандарт IEЕЕ 1012а-1998, СтандартIEЕЕ по аттестации и верификации программного обеспечения: План содержания к стандарту IEEE/EIA 12207.1-1997.⁴

Стандарт IEЕЕ 1016-1998, Методика составления описаний разработок программного обеспечения, рекомендуемая IEЕЕ.⁵

Стандарт IEЕЕ 1028-1997, Стандарт IEЕЕ по анализу программного обеспечения..

СтандартIEЕЕ 1042-1987 (Повторно подтвержден в 1993 году), Руководство IEЕЕ по управлению конфигурацией программного обеспечения.

IEEE P1058/D2.1, Эскиз стандарта по планам управления проектами программного обеспечения, от 5 августа 1998.⁶

Стандарт IEЕЕ 1058а-1998, Стандарт IEЕЕ по планам управления проектами программного обеспечения: План содержания к стандарту IEEE/EIA 12207.1-1977.⁷

Стандарт IEЕЕ 1074-1997, Стандарт IEЕЕ по разработке процессов жизненного цикла программного обеспечения.

Стандарт IEЕЕ 1233, Издание 1998 года, Руководство IEЕЕ по разработкам спецификаций системных требований.⁸

¹ Публикации ASTM можно получить в Американском Обществе Тестирования и Материалов, 100 Ватт Harbor Drive, West Conshohocken. PA 19428-2959, USA.

² Публикации IEEE можно получить в Институте Инженеров по Электротехнике и Радиоэлектронике, 445 Hoes Lane, P..O, Box 1331. Piscataway, NJ 08855-1331, USA.

³ По мере выхода этого стандарта в печать, стандарты IEEE 828-1998; IEEE 1012a-1998; IEEE 1016-1998 и IEEE 1233 1998 года издания утверждаются, но еще не издаются. Тем не менее, эскизы стандартов можно получить в IEEE. Ожидаемая дата публикации - осень 1998. За информацией о состоянии обращайтесь в Отдел Стандартов IEEE по телефону 1 (732) 562-3800.

⁴ См. сноску 3.

⁵ См. сноску 3.

⁶ После утверждения стандарта IEEE P1058 Советом по Стандартам IEEE-SA, этот стандарт будет объединен со стандартом IEEE 1058a-1998 и опубликован как стандарт IEEE 1058, 1998 года издания. Утверждение ожидается 8 декабря 1998.

⁷ По мере выхода этого стандарта в печать, стандарт IEEE 1058a-!998 утверждается, но еще не издается. Тем не менее, эскиз стандарта можно получить в IEEE. Ожидаемая дата публикации - декабрь 1998. За информацией о состоянии обращайтесь в Отдел Стандартов IEEE по телефону 1 (732) 562-3800. См. Сноску 6.

⁸ См. Сноску 3.

рекомендуемая Институтом Инженеров по Электротехнике и Радиоэлектронике (IEEE) Стандарт IEEE 830-1998

(Пересмотр стандарта IEEE 830-1993)

3. Определения

В целом, определения терминов, используемых в данной рекомендуемой методике, соответствует определениям, приведенным в стандарте IEEE 610.12-1990. Определения, данные ниже, являются ключевыми терминами, поскольку они используются в данной методике.

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

3.4 пользователь: лицо или лица, которые работают с изделием или непосредственно взаимодействуют с ним. Пользователь(-и) и заказчик(-и) часто не являются одним и тем же лицом(- ми).

4. Критерии создания качественной SRS

В этом разделе представлена предварительная информация, которую необходимо рассмотреть при составлении SRS. Она включает следующее:

а) Сущность SRS;

б) Среда SRS;

в) Характеристики качественной SRS;

г) Совместная подготовка SRS;

д) Развитие SRS;

е) Макетирование;

ж) Внедрение структуры в SRS;

з) Внедрение требований проекта в SRS.

4.1 Сущность SRS

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

Основными вопросами, которые должны рассматривать составитель (-ли) SRS, являются следующие:

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

б) Внешние интерфейсы. Как программное обеспечение взаимодействуют с пользователями, аппаратными средствами системы, другими аппаратными средствами и другим программным обеспечением?

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

г)- Атрибуты. Каковы мобильность, правильность, удобство сопровождения, защищенность программного обеспечения и другие критерии?

д) Проектные ограничения, налагаемые на реализацию изделия. Существуют ли требуемые стандарты на эффективном языке реализации, политика по сохранению целостности баз данных, ограничения ресурсов, операционная среда(-ы) и т.д.?

Составителю(-ям) SRS следует избегать размещения в SRS требований к разработке или проекту. Рекомендуемое содержание SRS см. в Приложении 5.

Стандарт IEEE 830-1998 Методика составления спецификаций требований к программному обеспечению

(Пересмотр стандарта IEEE 830-1993)

4.2 Среда SRS

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

Стандарт IEEE 1074-1997 описывает стадии жизненного цикла программного обеспечения и соответствующие входные данные для каждой стадии. Другие стандарты, такие как перечисленные в Разделе 2, относятся к другим частям жизненного цикла программного обеспечения и могут дополнять требования к программному обеспечению.

Так как SRS играет определенную роль в процессе разработки программного обеспечения, составителю (-ям) SRS следует проявлять осторожность, чтобы не выйти за пределы этой роли. Это означает, что SRS:

а) Должна правильно определять все требования к программному обеспечению. Причиной существования какого-либо требования к программному обеспечению может являться характер решаемой задачи или особая характеристика проекта.

б) Не должна описывать детали разработки или реализации. Они должны быть описаны на этапе разработки проекта.

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

Следовательно, правильно составленная SRS ограничивает диапазон допустимых проектов, но не определяет какой-либо конкретный проект.

4.3 Характеристики правильно составленной SRS

SRS должна быть:

а) Корректной;

б) Однозначной;

в) Полной;

г) Непротиворечивой;

д) Упорядоченной по ее значимости и/или устойчивости;

е) Проверяемой;

ж) Модифицируемой;

з) Отслеживаемой.

4.3.1 Корректность

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

Не существует какого-либо средства или процедуры, которые гарантирует корректность. SRS должна сравниваться с любой качественной применимой спецификацией, такой как спецификация требований к системе, с другой документацией проекта и с другими применимыми стандартами, и должна гарантировать согласованность. В качестве альтернативы заказчик или пользователь может определить, правильно ли SRS отражает фактические потребности. Отслеживаемость делает эту процедуру более простой и менее подверженной ошибкам (см. 4.3.8).

4.3.2 Однозначность

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

рекомендуемая Институтом Инженеров по Электротехнике и Радиоэлектронике (IEEE) Стандарт IEEE 830-1998

(Пересмотр стандарта IEEE 830-1993)

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

SRS является важной частью процесса составления требований или жизненного цикла программного обеспечения и используется в разработке, реализации, мониторинге проекта, верификации и проверке правильности, а также в обучении, как описано в стандарте IEEE 1074-1997. SRS должна быть однозначной как для тех, кто составляет ее, так и для тех, кто ее использует. Однако, эти группы часто не имеют одинаковую квалификацию и, следовательно, не имеют тенденции к описанию требований к программному обеспечению одним и тем же образом. Способы представления требований, которые улучшают спецификацию требований для разработчика, могут оказаться неэффективными в том, что они уменьшают их понимание пользователем, и наоборот.

В подразделах с 4.3.2.1 по 4.3.2.3 даются рекомендации, как избежать неоднозначности.

4.3.2.1 "Ловушки" естественного языка

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

4.3.2.2 Языки спецификаций требований

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

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

4.3.2.3 Инструменты представления требований

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

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

При использовании любого из этих подходов самым оптимальным будет придерживаться описания на естественном языке. При этом заказчики, незнакомые с перечисленными понятиями, будут в состоянии понять SRS.

4.3.3 Завершенность

SRS является полной, если и только, если она включает следующие элементы:

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

Стандарт IEEE 830-1998 Методика составления спецификаций требований к программному обеспечению

(Пересмотр стандарта IEEE 830-1993)

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

в) Полные обозначения и ссылки на все рисунки, таблицы и схемы в SRS и определение всех терминов и единиц измерения.

4.3.3.1 Использование условия TBD

Любая SRS, в которой используется фраза "должно быть определено" (условие TBD), не является полной SRS. Однако, иногда условие TBD необходимо и должно сопровождаться:

а) Описанием условий, являющихся причиной возникновения условия TBD (например, почему ответ не известен) так, чтобы ситуацию можно было разрешить;

б) Описанием того, что должно быть сделано, чтобы исключить условие TBD, кто ответственен за его устранение и когда оно должно быть устранено.

4.3.4 Непротиворечивость

Непротиворечивость обозначает внутреннюю непротиворечивость. Если SRS не согласовывается с каким-то документом более высокого уровня, таким как, например, спецификации системных требований, то она является некорректной (см. 4.3.1).

4.3.4.1 Внутренняя непротиворечивость

SRS является внутренне непротиворечивой, если и только, если никакой набор отдельных требований, описанных в ней, не находится в противоречии с ней. Тремя типами вероятных конфликтов в SRS являются следующие:

а) Могут входить в конфликт заданные характеристики реальных объектов. Например,

1) Формат отчета о выходных данных может быть описан в одном требовании в табличном виде, а в другом - в текстовом.

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

б) Между двумя заданными действиями может существовать логический или временной конфликт. Например,

Одно требование может устанавливать, что программа будет добавлять два входа, а другое может указывать, что программа будет умножать их.
Одно требование может устанавливать, что "А" должно всегда следовать за "Б", в то время как другое может требовать, чтобы события "А" и "Б" происходили одновременно.

в) Два или более требований могут описывать один и тот же реальный объект, но использовать для этого объекта различные условия. Например, запрос программы о вводе пользователем может называться "подсказкой" в одном требовании и "репликой" в другом. Использование стандартной терминологии и определений поддерживает непротиворечивость.

4.3.5 Упорядочивание по значимости и/или устойчивости

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

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

рекомендуемая Институтом Инженеров по Электротехнике и Радиоэлектронике (IEEE) Стандарт IEEE 830-1998

(Пересмотр стандарта IEEE 830-1993)

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

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

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

4.3.5.1 Степень устойчивости

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

4.3.5.2 Степень необходимости

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

а) Необходимые. Подразумевают, что программное обеспечение не будет пригодным, если эти требования не будут обеспечены согласованным образом.

б) Условные. Подразумевают, что эти требования расширяют программное изделие, но не сделают его непригодным при их отсутствии.

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

4.3.6 Проверяемость

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

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

Примером проверяемого утверждения является следующее:

Выходные данные программы должны вырабатываться в пределах 20 секунд в течение 60 % временного интервала события; и должны вырабатываться в пределах 30 секунд в течение 100 % временного интервала события.

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

Если нельзя изобрести метод, чтобы определить, отвечает ли программное обеспечение определенному требованию, то это требование следует исключить или пересмотреть.

Стандарт IEEE 830-1998 Методика составления спецификаций требований к программному обеспечению

(Пересмотр стандарта IEEE 830-1993)

4.3.7 Модифицируемость

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

а) Имела связанную и легкую в использовании структуру с оглавлением, алфавитным указателем и явно выраженными перекрестными ссылками;

б) Не была избыточной (то есть, одно и то же требование не должно появляться в SRS более чем в одном месте);

в) Выражала каждое требование раздельно, не смешивая его с другими требованиями.

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

4.3.8 Отслеживаемость

SRS является отслеживаемой, если четко прослеживается источник каждого из ее требований и если она облегчает обращение к каждому из требований при дальнейшей разработке или модернизации документации. Рекомендуются следующие два типа отслеживаемости:

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

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

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

4.4 Совместная подготовка SRS

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

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

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

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

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

рекомендуемая Институтом Инженеров по Электротехнике и Радиоэлектронике (IEEE) Стандарт IEEE 830-1998

(Пересмотр стандарта IEEE 830-1993)

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

4.5 Развитие SRS

По мере разработки программного изделия может возникнуть необходимость в развитии SRS. Может оказаться невозможным определить некоторые детали во время начала разработки проекта (например, может оказаться невозможным определить все форматы экрана для интерактивной программы на стадии выработки требований). В результате в SRS обнаруживаются неточности, недостатки и погрешности, являющиеся результатом дополнительных изменений.

Двумя главными критериями в этом процессе являются следующие:

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

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

Обеспечить точную и полную проверку изменений;
Обеспечить анализ текущих и замененных частей SRS..

4.6 Макетирование

Макетирование часто используется на этапе выработки требований проекта. Существуют многие инструментальные средства, которые позволяют очень быстро и легко создать прототип, проявляющий некоторые характеристики системы. См. также ASTM Е1340-96.

Прототипы удобны по следующим причинам:

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

б) Прототип отображает непредвиденные аспекты поведения систем. Таким образом, он генерирует не только ответы, но также и новые вопросы. Это помогает сосредоточиться на SRS.

в) SRS, базирующаяся на прототипе, имеет тенденцию подвергаться меньшим изменениям во время разработки, сокращая, таким образом ее длительность.

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

4.7 Встраивание структуры в SRS

Любое требование определяет внешне видимую функцию или атрибут системы. Структура описывает специфический подкомпонент системы и/или его интерфейс с другими подкомпонентами. Составитель (-ли) SRS должны ясно осознавать разницу между идентификацией требуемых ограничений структуры и проектированием специфической структуры. Следует заметить, что каждое требование в SRS ограничивает варианты структуры. Тем не менее, это не означает, что каждое требование является структурой.

Стандарт IEEE 830-1998 Методика составления спецификаций требований к программному обеспечению

(Пересмотр стандарта IEEE 830-1993)

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

а) Разбиение разделов программного обеспечения на модули;

б) Присваивание функций модулям;

в) Описание потока данных или управления между модулями;

г) Выбор структур данных.

4.7.1 Необходимые требования к структуре

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

а) Сохранении некоторых функций в отдельных модулях;

б) Разрешении только ограниченной связи между некоторыми областями программы;

в) Проверке целостности данных для критических переменных.

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

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

4.8 Встраивание требований к проекту в SRS

SRS должна относиться к программному изделию, а не к процессу его создания.

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

а) Стоимость;

б) Графики поставки;

в) Процедуры составления отчетов;

г) Методы разработки программного обеспечения;

д) Обеспечение качества;

е) Критерии утверждения и верификации;

ж) Процедуры приемки.

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

5. Части SRS

В этом разделе обсуждается каждая из необходимых частей SRS. Эти части показаны на рисунке 1 в виде эскиза, который может служить примером для составления SRS..

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

рекомендуемая Институтом Инженеров по Электротехнике и Радиоэлектронике (IEEE)

Стандарт IEEE 830-1998

(Пересмотр стандарта

IEEE 830-1993)

Содержание

1..Введение

Назначение
Область действия
Определения, акронимы и сокращения
Публикации
Краткий обзор

2. Полное описание

Перспектива изделия
Функции изделия
Характеристики пользователя
Ограничения
Допущения и зависимости

3. Специфические требования (Объяснения возможных специфических требований см. в пунктах с 5.3.1 по 5.3.8. Несколько различных способов организации этого раздела SRS см. в Приложении)

Приложения

Алфавитный указатель

следующая страница >>