Как правильно написать руководство пользователя

Попробовал погуглить, google:«как правильно писать руководство»,
натыкаюсь только на сайты SEO'шников или на ламерские рассуждения на каких-то унылых форумах.
Где бы почитать что-нибудь уровня П.Халмоша, его статьи «Как писать математические тексты» ?
Или за основу взять именно Халмоша?
cast DNA_Seq. Reset. ananas .

P.S. Пытаюсь писать какие-то «хроники пикирующего бомбардировщика» в процессе кодинга (сейчас на JavaScript),
хочу оформить в виде статьи-руководства. Вопрос не технический, поэтому поместил сюда.

Напиши как попало, а потом спроси пользователя.

Благодаря wiki почти не задаюсь этим вопросом - цель how-to в том, чтобы была выполнена задача. Если после прочтения задача выполнена - how-to написано нормально.

Если нет, что-то непонятно - вносятся правка. И так do while.

При выборе между «писать how-to некрасиво» или «не писать how-to вообще» выбираю всегда первое.

Ты номер ГОСТа что ли хочешь узнать?

Ответ на: комментарий от baverman 07.02.2013 3:49:52

Ты номер ГОСТа что ли хочешь узнать?

Нет. Стандарты на технологическую и программно-техническую документацию я изучил 12 лет назад, и уже пробовал их применять. Но они работают только на очень серьёзных задачах - годы development'а с серьёзной материальной и моральной поддержкой. У меня сейчас не такие условия.
Вопрос сейчас у меня про «жизненные советы» какого-нибудь опытного технического писателя (так их нынче называют, tech writers).

zgen. Напиши как попало, а потом спроси пользователя.
Обычно так и делаю. Просто хочется как-то стандартизировать этот процесс, внести порядок.
Или, думаешь, обычная «хроника» лучше и полезнее для организма ™?

Ответ на: комментарий от pacify 07.02.2013 3:56:50

Вроде технарь, а маешься дурью, как какая-нибудь ГСМная барышня.

Просто пиши и всё. Если проблемы в сути изложения, то никакие советы не помогут.

Ответ на: комментарий от baverman 07.02.2013 4:00:34

В сути изложения проблем нету. Думаю - что почитать на ночь по этой теме. Так как. от работы и кони дохнут ™
Нашёл красивый сайтик: Полезные ресурсы для технических писателей
и коммьюнити в LJ: http://ru-techwriters.livejournal.com/
Ещё есть весёлые советы от Чака Паланика. =)

Ответ на: комментарий от pacify 07.02.2013 3:56:50

Обычно так и делаю. Просто хочется как-то стандартизировать этот процесс, внести порядок.

Обычно когда 100500й документ пишешь, приходишь к какому-то внутреннему стандарту сам.

Ответ на: комментарий от zgen 07.02.2013 4:07:03

приходишь к какому-то внутреннему стандарту сам.

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

1. Дефицит специалистов.
2. Нереалистичные сроки и бюджет.
3. Реализация несоответствующей функциональности.
4. Разработка неправильного пользовательского интерфейса.
5. «Золотая сервировка», перфекционизм, ненужная оптимизация и оттачивание деталей.
6. Непрекращающийся поток изменений.
7. Нехватка информации о внешних компонентах, определяющих окружение системы или вовлечённых в интеграцию.
8. Недостатки в работах, выполняемых внешними (по отношению к проекту) ресурсами.
9. Недостаточная производительность получаемой системы.
10. «Разрыв» в квалификации специалистов разных областей знаний.
»
У меня в основном 2), 3), 6,7) (так как меняется API).

P.S. Пора список must-read список делать.

Ответ на: комментарий от zgen 07.02.2013 4:07:03

Обычно когда 100500й документ пишешь,

Беда только в том, что через год-два смотришь на свои поделки - как писатель на последний том своего произведения. И думаешь - «rm-rf или всё-таки wput»?

Нет общеизвестных фишечек. Могу лишь высказать мнение, что дочь Абрама - простит наибольшее разочарование вызовет неожиданное поведение функции, особенно когда вместо возврата валидного значения она внезапно бросает исключение или возвращает nullptr/undefined. Так же просто подводные камни стоит описать, например в функцию передаётся целочисленное время - непонятно сходу, это время в секундах или в милисекундах.

Ответ на: комментарий от quiet_readonly 07.02.2013 8:18:35

вместо возврата валидного значения она внезапно бросает
исключение или возвращает nullptr/undefined.

Это да. Несколько затормаживает разработку. Впрочем, в Гугле всё есть ™

например в функцию передаётся целочисленное время -
непонятно сходу, это время в секундах или в милисекундах.

Эти вещи я загоняю в комменты //

chenger > Тест-кейсы преобразовывать?
Да, наверное так и следует сделать.
Кучку examples.

Как будто сам руководств не читал. Берешь десяток мануалов с субъективно хорошим стилем написания, и слизываешь с них структуру построения. И да, мануал!=HOWTO, последнее описывает решение нескольких наиболее типичных задач и по объему должно быть не более пяти страниц. А вот мануал разрастается на сотни - сначала лицензия и условия распространения,потом введение, потом подробное изложение HOWTO, потом описание функций в алфавитном порядке. В общес с HOWTO и начинай. Главное чтобы нарисовалась структура изложения, стилистика причесывается.

Руководство пользователя

Существует множество видов предоставления справочной информации пользователю – это и FAQ (frequently asked questions, часто задаваемые вопросы) и онлайн справка и руководство пользователя (user guide) и популярные сегодня подсказки (coachmarks, см. пример ниже), обучающие видео и другие.

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

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

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

Часто бывает нужно написать документ, который бы удовлетворял требованиям действующих стандартов. Это могут быть:

• IEEE Std 1063-2001, «IEEE Standard for Software User Documentation»;
• ГОСТ 19:
  • ГОСТ 19.402-78 ЕСПД. Описание программы;
  • ГОСТ 19.502-78 ЕСПД. Общее описание. Требования к содержанию и оформлению;
  • ГОСТ 19.503-79 ЕСПД. Руководство системного программиста. Требования к содержанию и оформлению;
  • ГОСТ 19.504-79 ЕСПД. Руководство программиста. Требования к содержанию и оформлению;
  • ГОСТ 19.505-79 ЕСПД. Руководство оператора. Требования к содержанию и оформлению.

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

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

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

Хорошее руководство пользователя должно содержать:

• Аннотацию. в которой приводится краткое изложение содержимого документа и его назначение. Также рекомендуется писать краткую аннотацию в начале каждого крупного раздела.
• Введение. содержащее информацию о том, как лучше всего использовать данное руководство
• Содержание
• Главы. описывающие, как использовать ПО
• Глоссарий и
• Предметный указатель

Также руководство пользователя может содержать:

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

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

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

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

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

Стиль руководства должен быть нейтрально-формальным – использование стилистически окрашенных слов отвлекает пользователя от сути.

Для составления хорошего документа пригодятся знания грамматики и немного психологии.

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

4.2 Используйте повелительное наклонение. не употребляйте вежливые обороты (please, could и т.д.) — излишняя вежливость именно здесь будет помехой.

Хорошо: Click Logout to log out current user account from the system.

Хуже: It is needed to click Logout to log out current user account from the system.

Хуже: If user wants to log out current user account from the system (s)he needs to click Logout.

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

1. Click the Create button on toolbar.
2. On the CreateProject overlay fill in all mandatory fields.
3. Click the Savebutton to save the project.

Хуже: To create project click the Create button on toolbar, on the Create Project overlay fill in all mandatory fields, click the Save button to save the project.

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

Хорошо: When user clicks the Start button, the program starts the process.

Хуже. When user clicks the Start button, the program will start the process.

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

Например, глагол «press» означает нажатие клавиши на клавиатуре, а «click» – нажатие кнопки или значка в окне программы при помощи мыши, а «hit» вообще является жаргонным словом.

Разумеется, орфографические ошибки недопустимы.

4.6 Не используйте синонимы для одного и того же термина. В IT литературе на английском (или любом другом) языке есть стандартный набор глаголов, обозначающих действия (click, double-click, select, type, press и т.д.) и такой же стандартный набор названий элементов управления. Определитесь с терминологией и придерживайтесь ее в рамках всего документа.

Например, не допускайте, чтобы в одной части документа выпадающий список назывался dropdown, а в другой точно такой же элемент – combobox или dropdown list. Это путает пользователя.

4.7 Разумно используйте сокращения и исключите жаргон .

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

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

5.1 Продумайте стиль документа. Это может быть корпоративный шаблон или цветовая схема ПО или специально сделанный для документа дизайн.

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

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

5.3 Используйте пиктограммы и иллюстрации. Существует мнение, что не стоит увлекаться иллюстрациями, а также включать в текст пиктограммы (icons) в руководстве пользователя. Однако графическая информация всегда лучше воспринимается и запоминается, поэтому снимки экрана и нужные пиктограммы должны присутствовать в хорошем руководстве в достаточном, но разумном количестве.

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

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

Помните главное: документ должен помогать пользователям.

аналитик с 6-летним опытом в сфере.

Комментарии к “Руководство пользователя. Советы для составления”

Анастасия Сороковая - 23.01.2013 в 15:57 #360

Статья понравилось, все четко и по полочкам (как и должно быть в руководстве)
Единственное, статья ориентирована на англоязычные версии инструкций, а наш великий и могучий имеет все же свою специфику.
В частности, очень сложно придерживаться исключительно настоящего времени. Например как сформулировать только в настоящем фразу а-ля «При нажатии на кнопку «Отправить», адресату будет направлено уведомление (Чтобы отправить уведомомление адресату, нажмите кнопку «Отправить»)». И как быть если все же отклик на событие (нажатие кнопки, сохранение) происходит не единомоментно, а с некоторой задержкой?
Еще меня интересует объем инструкции, где та золотая середина между количеством и качеством? зачастую уже при виде предстоящих 100 стр. инструкций пользователь теряет всякий интерес.

Роман Баканович - 23.01.2013 в 16:02 #361

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

Den Tkachenko - 07.07.2014 в 16:24 #606

Такую серьезную «телегу» написала такая милая девушка )).

Спасибо за FAQ по руководству, особенно пункт 4.4 и «документ должен помогать пользователям».

Разработка и написание руководства пользователя ГОСТ

21.03.2016 1 января 2016 года вступает в силу. Читать новости 03.11.2015 Компания SWRIT рада сообщить о расширении комплекса. Читать новости 01.02.2015 Федеральным агентством по техническому регулированию и метрологии. Читать новости 09.11.2014 Компания SWRIT разработала документацию на иностранное оборудование. Читать новости 02.09.2014 Вышел новый ГОСТ 2.601-2013 «Единая система конструкторской. Читать новости

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

Очень трудно определить чёткую структуру Руководства пользователя. ГОСТ 50-34-698-90 предлагает следующую структуру документа:
введение; назначение и условия; применения; подготовка к работе; описание операций; аварийные ситуации; рекомендации по освоению.

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

С некторыми примерами руководства пользователя разработанных нашими специалистами соглавно ГОСТ Вы можете ознакомится на нашем сайте.

Если Вас необходима разработка и написание руководства пользователя удовлетворяющего всем требованиям стандартов, то обратитесь к нам по телефону +7(499)755-74-33. по электронной почте Данный адрес e-mail защищен от спам-ботов, Вам необходимо включить Javascript для его просмотра. или через форму заказа .

ГОСТ РД -90 Руководство пользователя

Ниже представлен пример (образец) документа "Руководство пользователя ", разработанного на основании методических указаний РД 50-34.698-90 .

Данный документ формируется IT-специалистом, или функциональным специалистом, или техническим писателем в ходе разработки рабочей документации на систему и её части на стадии «Рабочая документация».

Для формирования руководства пользователя в качестве примера был взят инструмент Oracle Discoverer информационно-аналитической системы «Корпоративное хранилище данных».

Ниже приведен состав руководства пользователя в соответствии с ГОСТ. Внутри каждого из разделов кратко приведены требования к содержанию и текст примера заполнения (выделен вертикальной чертой).

Разделы руководства пользователя:

В разделе "Введение" указывают:

1. область применения;
2. краткое описание возможностей;
3. уровень подготовки пользователя;
4. перечень эксплуатационной документации, с которой необходимо ознакомиться пользователю.

Требования настоящего документа применяются при:

• предварительных комплексных испытаниях;
• опытной эксплуатации;
• приемочных испытаниях;
• промышленной эксплуатации.

Информационно-аналитическая система Корпоративное Хранилище Данных (ИАС КХД) предназначена для оптимизации технологии принятия тактических и стратегических управленческих решений конечными бизнес-пользователями на основе информации о всех аспектах финансово-хозяйственной деятельности Компании.

ИАС КХД предоставляет возможность работы с регламентированной и нерегламентированной отчетностью.

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

• формирование табличных и кросс-табличных отчетов;
• построение различных диаграмм;
• экспорт и импорт результатов анализа;
• печать результатов анализа;
• распространение результатов анализа.

Пользователь ИАС КХД должен иметь опыт работы с ОС MS Windows (95/98/NT/2000/XP), навык работы с ПО Internet Explorer, Oracle Discoverer, а также обладать следующими знаниями:

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

Квалификация пользователя должна позволять:

• формировать отчеты в Oracle Discoverer Plus;
• осуществлять анализ данных.

• Информационно-аналитическая система «Корпоративное хранилище данных». ПАСПОРТ;
• Информационно-аналитическая система «Корпоративное хранилище данных». ОБЩЕЕ ОПИСАНИЕ СИСТЕМЫ.

В разделе "Назначение и условия применения" указывают:

1. виды деятельности, функции, для автоматизации которых предназначено данное средство автоматизации;
2. условия, при соблюдении (выполнении, наступлении) которых обеспечивается применение средства автоматизации в соответствии с назначением (например, вид ЭВМ и конфигурация технических средств, операционная среда и общесистемные программные средства, входная информация, носители данных, база данных, требования к подготовке специалистов и т. п.).

Oracle Discoverer Plus в составе ИАС КХД предназначен для автоматизации подготовки, настройки отчетных форм по показателям деятельности, а также для углубленного исследования данных на основе корпоративной информации хранилища данных.

Работа с Oracle Discoverer Plus в составе ИАС КХД возможна всегда, когда есть необходимость в получении информации для анализа, контроля, мониторинга и принятия решений на ее основе.

Работа с Oracle Discoverer Plus в составе ИАС КХД доступна всем пользователям с установленными правами доступа.

В разделе "Подготовка к работе" указывают:

1. состав и содержание дистрибутивного носителя данных;
2. порядок загрузки данных и программ;
3. порядок проверки работоспособности.

Для работы с ИАС КХД необходимо следующее программное обеспечение:

1. Internet Explorer (входит в состав операционной системы Windows);
2. Oracle JInitiator устанавливается автоматически при первом обращении пользователя к ИАС КХД.

Перед началом работы с ИАС КХД на рабочем месте пользователя необходимо выполнить следующие действия:

1. Необходимо зайти на сайт ИАС КХД ias-dwh.ru.
2. Во время загрузки в появившемся окне "Предупреждение о безопасности", которое будет содержать следующее: 'Хотите установить и выполнить "Oracle JInitiator". ' Нажимаем на кнопку "Да".
3. После чего запуститься установка Oracle JInitiator на Ваш компьютер. Выбираем кнопку Next и затем OK.

Для проверки доступности ИАС КХД с рабочего места пользователя необходимо выполнить следующие действия:

1. Открыть Internet Explorer, для этого необходимо кликнуть по ярлыку «Internet Explorer» на рабочем столе или вызвать из меню «Пуск».
2. Ввести в адресную строку Internet Explorer адрес: ias-dwh.ru и нажать «Переход».
3. В форме аутентификации ввести пользовательский логин и пароль. Нажать кнопку «Далее».
4. Убедиться, что в окне открылось приложение Oracle Discoverer Plus.

В случае если приложение Oracle Discoverer Plus не запускается, то следует обратиться в службу поддержки.

В разделе "Описание операций" указывают:

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

Для каждой операции обработки данных указывают:

1. наименование;
2. условия, при соблюдении которых возможно выполнение операции;
3. подготовительные действия;
4. основные действия в требуемой последовательности;
5. заключительные действия;
6. ресурсы, расходуемые на операцию.

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

Oracle Discoverer Plus в составе ИАС КХД выполняет функции и задачи, приведенные в таблице ниже:

Как писать руководство пользователя? Часть I - обобщенная структура руководства по ГОСТам 19-й системы и сравнительный ее анализ с рекомендациями IEEE

Yes, in electronic documents

For purposes of this standard, the following non-mandatory nomenclature is used for the structural parts of software user documentation. A printed document is structured into logical units called chapters, subdivided into topics, which may be subdivided into subtopics, and printed on physical units called pages.

Здорово. IEEE Std 1063-2001 предлагает «все взять и поделить» - разбить разделы руководства на главы, топики, субтопики и т.д. И наступит всем счастье.

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

Какие сведения должны быть изложены в разделе Introduction согласно IEEE Std 1063-2001? А вот какие

The introduction shall describe the intended audience, scope, and purpose for the document and include a brief overview of the software purpose, functions, and operating environment.

Что ж, замечательно. Структура подразделов Introduction начинает как-то вырисовываться.

The documentation shall include information on how it is to be used (for example, help on help), and an explanation of the notation (a description of formats and conventions-see 5.8). At least one document in a document set shall identify all documents in the set by title and intended use, including recommendations on which members of the audience should consult which sections of the documentation. In document sets comprising many volumes or products, this information may be provided in a separate "road map" or guide to the document set. Documentation may include identification and discussion of notable changes from the previous version of the document set and the software.

Весьма полезный раздел (в контексте разработки руководства пользователя). Руководство по руководству.

Documentation shall explain the conceptual background for use of the software, using such methods as a visual or verbal overview of the process or workflow; or the theory, rationale, algorithms, or general concept of operation. Explanations of the concept of operation should be adapted to the expected familiarity of the users with any specialized terminology for user tasks and software functions. Documentation shall relate each documented function to the overall process or tasks. Conceptual information may be presented in one section or immediately preceding each applicable procedure.

Концептуальная информация безусловно важна.

Task-oriented instructional mode documentation shall include instructions for routine activities that are applied to several functions:

- Software installation and de-installation, if performed by the user

- Orientation to use of the features of the graphical user interface (see 5.6)

- Access, or log-on and sign-off the software

- Navigation through the software to access and to exit from functions

- Data operations (enter, save, read, print, update, and delete)

- Methods of canceling, interrupting, and restarting operations

These common procedures should be presented once to avoid redundancy when they are used in more complex functions.

И пошла конктерика. Молодцы, буржуи!

Documentation shall explain the formats and procedures for user-entered software commands, including required parameters, optional parameters, default options, order of commands, and syntax. Documentation may be provided on the development and maintenance of macros and scripts. Reference mode documentation shall contain a reference listing of all reserved words or commands. Examples should illustrate the use of commands. Documentation shall explain how to interrupt and undo operation during execution of a command and how to restart it, if possible. Documentation shall describe how to recognize that the command has successfully executed or abnormally terminated.

Documentation should address all known problems in using the software in sufficient detail such that the users can either recover from the problems themselves or clearly report the problem to technical support personnel. Reference mode documentation shall include each error message with an identification of the problem, probable cause, and corrective actions that the user should take. A quick reference card may address error messages by referring the user to more detailed reference documentation. The documentation on resolving problems shall also include contact information for reporting problems with software or its documentation and suggesting improvements.

Но счастье оказалось неполным. Структура разделов первого уровня руководства показана в таблице явно. А дальше - «милый мой, хороший, догадайся сам» («догадайся, мол, сама»). IEEE Std 1063-2001, конечно, «provides requirements for the structure», но не предлагает явной структуры руководства пользователя до рекомендованного ГОСТ 2.105 четвертого уровня вложенности.