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

Комитетами Совета по Стандартам Ассоциации Стандартов 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 может потребоваться разрешение, или за проведение запросов по юридической обоснованности или области действия этих патентов.

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

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

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

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

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

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

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

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

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

Авторское право © 1998 IEEE. Все права сохранены. iii

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

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

Эдвард Бирн

Пол Р. Кролл

Перри Де Вис

Робин Фрэлик

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

Джон Харас

Марк Хэнли

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

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

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

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

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

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

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

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

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

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

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

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

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

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

vi Авторское право © 1998 IEEE. Все права сохранены.

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

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

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

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

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

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

Авторское право © 1998 IEEE. Все права сохранены.

Стандарт 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ЕЕ по разработкам спецификаций системных требований.<sup>8

1</sup> Публикации 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.

2 Авторское право © 1998 IEEЕ. Все права сохранены.

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

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

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

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

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

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

б) Среда SRS;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Авторское право © 1998 IEEE. Все права сохранены.

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

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