Если у вас возникли сложности с курсовой, контрольной, дипломной, рефератом, отчетом по практике, научно-исследовательской и любой другой работой - мы готовы помочь.
Предоплата всего
Подписываем
Документ-концепция
Филипп Крачтен (Philippe Kruchten) как-то сказал: "Если бы мне разрешили разработать только один документ, модель или другой артефакт для поддержки программного проекта, я бы выбрал краткий, хорошо сформулированный документ-концепцию".
Документ-концепция сочетает в себе некоторые основные элементы доку мента маркетинговых требований и документа требований к продукту. Нам не обходимо разработать этот конкретный документ по двум причинам.
1. Каждому проекту нужен документ-концепция.
2. Это поможет нам в демонстрации процесса работы с требованиями, поскольку некоторые ключевые элементы данного процесса будут за писаны в этом документе.
Документ-концепция описывает приложение в общих чертах, а также содержит опи сания целевых рынков, пользователей системы и функций приложения. Мы неодно кратно имели возможность убедиться в его полезности, и у нас стало уже хорошей тради цией разрабатывать его при определении любого программного приложения.
Компоненты документа-концепции
Документ-концепция — это важнейший документ программного проекта, который фиксирует потребности пользователя, функции системы и другие общие требования к проекту. Сфера действия документа-концепции распространяется на два верхних, уровня пирамиды требований. Таким образом, он описывает на высоком уровне абстракции как проблему, так и решение.
Основные положения
Сфера действия документа-концепции
Документ-концепция программного продукта также служит основой для достижения со гласия между тремя основными внутренними сообществами заинтересованных лиц проекта.
1. Отделом маркетинга, который выступает в качестве доверенного лица заказчика и пользователя и отвечает за успех продукта после реализации.
2. Командой проекта, разрабатывающей приложение.
3. Руководством, которое несет ответственность за бизнес-результат попытки.
Документ-концепция является мощным средством, так как представляет все существенные аспекты продукта с различных точек зрения в краткой, абстрактной, доступной и управляемой форме. Документ-концепция крайне важен на ранних фазах проекта, и все затраты, вложен ные в процесс получения информации, принесут щедрые плоды на более поздних стадиях.
Поскольку все программные проекты выиграют от наличия документа-концепции, мы собираемся описать его более подробно. Хотя наш пример ориентирован на программ ный продукт, его достаточно легко модифицировать, чтобы он отражал содержание лю бого конкретного продукта.
Ниже представлена краткая схема документа-концепции, которая (с некоторы ми настройками) использовалась для сотен программных продуктов и приложений.
1. Введение
В данном разделе предлагается общий обзор документа - концепции.
1.1. Назначение документа-концепции
В данном документе фиксируются, анализируются и задаются высоко уровневые потребности пользователей и функции продукта.
1.2. Краткое описание продукта
Формулируется цель приложения, версии и новые предоставляемые функции.
1.3. Ссылки
Приводится полный список всех документов, упоминаемых в документе-концепции.
2. Описание пользователя
Кратко представлены общие сведения о пользователях системы.
2.1. Данные о пользователе/рынке
Кратко представлены основные данные о рынке, которые мотивируют решения относительно продукта.
2.2. Типы пользователей
Кратко описываются будущие пользователи системы.
2.3. Среда пользователя
2.4. Основные потребности пользователей
Перечисляются основные проблемы или потребности пользователей.
2.5. Альтернативы и конкуренты
Выявляются все приемлемые (с точки зрения пользователя) альтернати вы.
3. Краткое описание продукта
3.1. Общий вид продукта
Предлагается блок-схема продукта или системы и ее интерфейсов с внешней средой.
3.2. Определение позиции продукта на рынке
Предлагается обобщенная краткая характеристика (на самом высоком уровне абстракции) уникальной позиции, которую должен занять продукт на рынке. Мур (Moore) (1991) рекомендует использовать следующую форму.
|
Для |
[целевой клиент] |
|
Который [Название продукта]
Который В отличие от Наш продукт |
[формулировка потребности или возможности] является [категория продукта] [формулировка основных преиму ществ, т.е. указание причин, по кото рым продукт будет покупаться] [основные конкурирующие альтерна тивы] [формулировка основных отличий] |
3.3. Характеристика возможностей
Перечисляются основные возможности и функции, которые будут пре доставлены продуктом.
|
Возможности клиентов |
Поддерживающие функции |
|
Возможность 1 Возможность 2 Возможность 3 |
Функция Функция Функция |
3.4. Предположения и зависимости
3.5. Затраты и цены
4. Атрибуты функций
Описываются атрибуты функций, которые будут использоваться для оценки, отслеживания, задания приоритетов и управления функциями. Некоторые из них перечислены ниже.
|
Статус Приоритет Трудоемкость Риск Стабильность Целевая версия Предназначен для Причина |
Предлагаемый, принятый, включенный Число голосов по результатам накопительного голосования или критический, важный, по лезный Низкая, средняя, высокая; командо-недели; человеко-месяцы Низкий, средний, высокий Низкая, средняя, высокая Номер версии Фамилия Текстовое поле |
5. Функции продукта
В данном разделе перечисляются функции продукта.
5.1. Функция №1
5.2. Функция №2
6. Ключевые прецеденты
Описываются основные прецеденты, которые важны с точки зрения ар хитектуры или наиболее полезны для того, чтобы помочь читателю по нять, как будет использоваться система.
7. Другие требования к продукту
7.1. Применяемые стандарты
Перечисляются все стандарты, которым должен соответствовать продукт.
7.2. Системные требования
Задаются все системные требования, которым должно соответствовать приложение.
7.3. Лицензирование и установка
Описываются все инсталляционные требования, которые оказывают влияние на создание программного кода или вызывают потребность в создании отдельного инсталляционного программного обеспечения.
7.4. Требования к производительности
Этот раздел используется для подробного описания требований к произ водительности.
8. Требования к документации
Описывается, какую документацию необходимо разработать для успеш ного развертывания приложения.
8.1. Руководство пользователя
Описывается цель и содержание руководства пользователя.
8.2. Интерактивные подсказки
Требования к интерактивным подсказкам, средствам предупреждения и т.п.
8.3. Руководства по инсталляции, конфигурация и файлы "Read Me"
8.4. Маркировка и упаковка
9. Глоссарий
Итак, документ-концепция кратко описывает все, что вы считаете наиболее важным для продукта или приложения. Он представляет собой достаточно подробное описание на естественном языке, поэтому основным участникам проекта легко с ним работать.
Документ Delta Vision
Разработка документа-концепции и работа с ним, являясь центром приложения действий многих участников (заказчиков, пользователей, представителей руководства проекта и марке тинга), могут играть заметную роль в успехе (или неудаче) программного проекта. Зачастую к разработке и пересмотру этого документа привлекается даже дирекция компании. Ведение до кумента-концепции является важным профессиональным приемом, который в состоянии значительно повысить общую производительность работы над проектом.
Чтобы это было легче осуществить, нужно сделать документ-концепцию как можно более кратким, сжатым и "по существу". При создании первой версии документа это не так уж слож но, так как практически все пункты в перечне будут новыми для данного проекта или, по крайней мере, должны быть переформулированы с учетом содержания данного приложения.
Однако неэффективно в последующие версии повторно записывать вошедшие в пре дыдущие версии функции, а также прочую информацию, которая не претерпела измене ний (описание пользователей и обслуживаемых рынков). Для решения данной проблемы мы предлагаем использовать документ изменений концепции (Delta Vision document). Одна ко перед тем, как заняться его разработкой, рассмотрим развитие документа-концепции на протяжении жизненного цикла нового проекта.
Документ-концепция версии 1.0
Для нового продукта или приложения необходимо разработать и исследовать практи чески все элементы документа-концепции. Если некий элемент не рассматривается, вы просто удаляете его из оглавления документа и ничего не пишете о нем. Обязательными элементами документа-концепции являются следующие (рис. 1).
• Общая информация и введение
• Сведения о пользователях системы и описание обслуживаемых рынков, функций, которые предполагается реализовать в версии 1.0
• Прочие требования (регуляторные и требования среды)
• Будущие функции, которые были выявлены, но не вошли в версию 1.0
Рис.1. Документ-концепция версии 1.0
Данный документ служит основой версии 1.0 и разработки более подробных про граммных требований и прецедентов, которые будут более полно описывать систему.
Документ-концепция версии 2.0
По мере развития проекта более четко определяются функции; это означает, что они будут более полно описаны в документе-концепции. Кроме того, выявляются новые функции и добавляются в него. Таким образом, документ разрастается, и одновременно возрастает его значение для команды.
Документ-концепция v2.0
Приступая к разработ ке версии 2.0, мы, безусловно, хотели бы сохранить документ, который так хорошо нам служил. В данной ситуации представляется логичным "откопать" будущие функции, которые включены в документ для версии 1.0, но не реализованы, и запланировать их для реализации в версии 2.0. Дру гими словами, мы хотим найти и "раскрутить" некоторые будущие функции, представляющие интерес для версии 2.0. Можно также запланировать про ведение дополнительного совещания, посвященного требованиям, или осуществление любого другого процесса выявления требований для обнаружения новых функций, за планированных для реализации в версии 2.0, а также тех, которые нужно будет внести в документ в качестве новых будущих функций. Некоторые из этих функций, основанные на обратной реакции заказчика, уже будут очевидны, другие возникнут как следствие по лученного командой опыта. В любом случае эти вновь обнаруженные функции следует записать в документ-концепцию версии 2.0 как запланированные для реализации в вер сии 2.0 или будущие функции.
Может оказаться, что некоторые реализованные в версии 1.0 функции не достигают по ставленной цели (возможно, из-за того, что внешняя среда изменилась за время разработки и функция больше не нужна или должна быть заменена новой, либо из-за того, что она просто не нужна клиентам, хотя они предполагали обратное). В любом случае, скорее всего обнару жится, что в следующей версии некоторые функции необходимо удалить. Как отразить эти "антитребования"? В данной ситуации нужно просто использовать документ-концепцию для указания того, что определенная функция должна быть удалена из следующей версии.
В процессе работы документ постоянно растет. Это естественно, так как он определя ет растущую систему. К сожалению, может случиться, что со временем документ будет все труднее читать и понимать. Почему? Потому, что он теперь гораздо длиннее и содержит много информации, которая не претерпела изменений со времени предыдущей реализа ции. Например, определение позиции продукта и целевые пользователи, скорее всего, остались неизменными, как и 25-50 функций, реализованных в версии 1.0, которые со хранились в документе-концепции версии 2.0.
Документ Delta Vision v2.0
Поэтому мы предлагаем вести документ изменений, концепции (Delta Vision document). В нем отражается только то, что изменилось, а также любая другая информация, которую следует включить для ясности. Эта информация вклю чается для того, чтобы напомнить команде концепцию проекта или помочь войти в курс дела новым членам команды.
В результате получается документ изменений, в котором основное внимание уделяется тому, что нового включено в данную версию и что от личает ее от предыдущих версий. При работе со сложными системами информации полезно применять данный метод, который позволяет сконцентрировать внимание на том, что изменилось. Воспользовавшись им, мы получаем модель, представленную на рис. 2.
Рис. 2. Документ Delta Vision
• Документ-концепция 1.0 является всеобъемлющей точкой отсчета; здесь представ лено все, что необходимо знать о нашем проекте.
• Delta Vision 2.0 определяет то, что отличает данную версию.
• Объединение этих двух документов задает полное определение продукта.
Следует использовать обе версии вместе, если согласно требованиям заказчика или регулирующих инструкций необходимо предоставить полное определение продукта. Их совместное использование, несомненно, полезно для новых членов команды. Однако в этом случае приходится читать о функциях версии 1.0, которых уже нет в версии 2.0, так как они были позднее удалены, и нужно всегда отслеживать эти изменения при воссозда нии полного определения.
Если это необходимо, можно достаточно просто соединить содержимое документа-концепции 1.0 и Delta 2.0 в новый документ-концепцию 2.0, который представляет все объемлющую и полную картину проекта.
Не существует строгих правил относительно определений этих документов или того, что каждый из них содержит. В других обстоятельствах может оказаться удобным использовать Delta Vision только при относительно небольших модификациях (таких, как версии 1.1 и 1.2) и начинать все сначала и пересматривать определение продукта в целом для каждой крупной реализации (версии 2.0 или 3.0). В любом случае применение документа Delta Vision поможет лучше справиться с процессом управления требованиями, так как позволит команде сконцен трироваться на "том, что действительно важно" на каждом конкретном этапе.
Документ Delta Vision для уже существующей системы
Крайне редко практикуется документирование полных требований крупномасштабной существующей системы.
Одна из сложнейших проблем управления требованиями состоит в применении методов управления требованиями к эволюции существующих IS/IT-систем
Крайне редко существуют полные и адекватные спецификации требований для миллионов строк кода и сотен человеко-лет трудозатрат, отражением которых являются эти системы. Также непрактично останавливаться и повторно документировать прошлое. При этом мож но упустить время и не выполнить свою задачу, записывая исторические требования то гда, когда следовало писать код!
Таким образом, если приходится начинать с нуля или с минимальной документации, следует использовать все имеющиеся в вашем распоряжении ресурсы (программный код, спецификации, знания членов команды о предыстории), чтобы прийти к пониманию то го, что система делает в настоящий момент. Затем мы рекомендуем применить процесс создания Delta Vision и задать функции и прецеденты, описывающие изменения, которые вы собираетесь вносить в существующую систему. Следуя этому процессу, можно скон центрироваться на том, что нового в данной реализации и что отличает ее от предыдущих реализаций; в результате ваши заказчики и команда получат несомненную пользу от хо рошо организованного процесса управления требованиями. Кроме того, созданные вами записи требований будут служить документацией для ваших последователей.
Образец документа-концепции
Исключительную важность для успеха проекта имеет документ-концепция, в котором представлены высокоуровневые потребности пользователя и функции приложения. Этот документ по мере необходимости обновляется и доводится до сведения членов ко манды разработчиков и других участников проекта. Предлагаемый ниже образец доку мента можно использовать в качестве отправной точки и модифицировать в соответст вии с потребностями конкретной организации.
Название компании
Документ-концепция [Название проекта]
©1999 Название компании
История исправлений
|
Дата |
Версия |
Описание |
Автор |
|
23/06/99 |
1.0 |
Исходная версия |
Имя автора |
|
число/месяц/год |
|||
Содержание
1. Введение
В данном разделе необходимо представить общую характеристику документа-концепции в целом; наряду с этим он должен содержать следующие подразделы.
1.1. Цель документа-концепции
Цель данного документа состоит в сборе, анализе и определении высокоуровневых потребностей пользователей и функций продукта. Основное внимание уделяется возможностям, в которых нуждаются будущие пользователи, и причинам существо вания этих потребностей. Конкретные требования, касающиеся того, как приложе ние выполняет эти потребности, должны быть представлены в спецификациях тре бований к программному обеспечению или спецификациях прецедентов.
1.2. Общая характеристика продукта
В данном разделе определяется цель приложения, его версия и новые предос тавляемые функции. Здесь следует:
1.3. Ссылки
Этот подраздел содержит следующее.
- Список всех документов, упоминаемых где-либо в документе-концепции Для каждого из этих документов указывается полное его название, номер (если нужно), дата публикации, а также название опубликовавшей его орга низации.
- Список источников, к которым можно обратиться за справками
Эта информация может быть представлена ссылкой на приложение или другой документ.
2. Описание пользователя
Чтобы преуспеть в предоставлении продуктов и услуг, удовлетворяющих потребно сти заказчиков, необходимо знать, с какими проблемами сталкиваются пользователи при выполнении своей работы. Данный раздел должен содержать описание профиля потен циальных пользователей приложения и основных проблем, ограничивающих их произ водительность. Этот раздел не следует использовать для формулировки конкретных тре бований. В нем должны содержаться обоснования того, почему необходимы перечис ленные в разделе 5 требования.
2.1. Характеристика рынка/пользователя
Здесь необходимо кратко перечислить основные характеристики рынка, кото рые послужили мотивацией решений, касающихся продукта: описать и указать целевые сегменты, а также оценить объем и перспективы роста рынка, ориен тируясь на число потенциальных пользователей или количество денег, кото рые в настоящее время тратят ваши заказчики, пытаясь решить те задачи, что будут решаться с помощью вашего приложения (или усовершенствования). Нужно также рассмотреть основные существующие в отрасли тенденции и тех нологии. При этом следует ответить на следующие стратегические вопросы: какова репутация вашей организации на этих рынках и как данный продукт или услуги помогают достижению вашей цели.
2.2. Описания пользователей
Здесь следует описать все типы пользователей. Пользователи могут сильно от личаться по своему уровню: от новичков до искушенных профессионалов. Опытному пользователю может потребоваться сложное гибкое средство под держки межплатформенного взаимодействия, в то время как новичку нужно простое в обращении дружественное пользователю средство. Описание про филя должно для каждого типа пользователей освещать следующие вопросы.
2.3. Среда пользователя
2.4. Основные потребности пользователя
Следует перечислить основные проблемы или потребности так, как они осознаются пользователем. Для каждой проблемы нужно прояснить следующие моменты.
Нужно понимать относительную важность для пользователя решения каждой из проблем. Методы упорядочения и накопительного голосования позволяют выделить проблемы, которые должны быть решены, и вопросы, которые же лательно учесть.
2.5. Альтернативы и конкуренты
Нужно указать возможные альтернативы поведения пользователя. Среди них может быть покупка продукта конкурентов, создание собственного решения или просто сохранение существующей ситуации. Перечислите все известные конкурирующие варианты, которые существуют или могут возникнуть. Опи шите основные преимущества и недостатки каждого варианта с точки зрения конечного пользователя.
2.5.1. Конкурент!
3. Характеристика продукта
В данном разделе предлагается общее описание возможностей продукта, интерфейсов с другими приложениями и конфигураций систем. Как правило, он состоит из сле дующих трех подразделов.
3.1. Общее описание продукта
В данном подразделе следует описать, как продукт взаимодействует с другими связанными с ним продуктами и средой пользователя. Если продукт является независимым и самодостаточным, это необходимо указать. Если продукт явля ется компонентом более крупной системы, в данном подразделе необходимо описать, как эти системы взаимодействуют, а также указать соответствующие интерфейсы между системами. Простым способом отображения основных компонентов более крупной системы, взаимосвязей и внешних интерфейсов является блок-схема.
3.2. Определение позиции продукта
Предлагается общее определение, характеризующее на самом высоком уровне абстракции особое положение, которое продукт должен занять на рынке. Мур (Moore, 1991) назвал это определением позиции продукта и рекомендовал ис пользовать для него следующую форму.
|
Для |
(целевые потребители), |
|
которые |
(определение потребности или возможности), |
|
(название продукта) |
является (категория продукта), |
|
который |
(описание основных преимуществ, т.е. почему его обязательно нужно купить). |
|
В отличие от |
(перечисление основных альтернативных вариантов), |
|
наш продукт |
(описание основных его особенностей). |
Это определение должно довести до сведения всех заинтересованных лиц на значение продукта и важность проекта.
3.3. Краткий обзор возможностей
Краткая характеристика основных возможностей и функций продукта. Напри мер, в документе-концепции системы поддержки клиента данный подраздел может описывать решение проблем документирования, маршрутизации и от слеживания статуса, не вдаваясь в подробности осуществления этих функций. Функции должны быть организованы так, чтобы список был понятен заказчику или тому, кто впервые читает данный документ. Ниже приводится образец, в котором в форме простой таблицы перечислены основные возможности и осуществляющие их поддержку функции.
Система поддержки заказчика
|
Предоставляемая пользователю возможность |
Поддерживающая функция |
|
Преимущество 1 |
фуннкция 1 |
3.4. Предположения и зависимости
Описываются предположения, изменение которых приведет к изменению концепции продукта. Например, предположение может состоять в том, что для аппаратного обеспечения программного продукта можно будет использовать определенную операционную систему. Если такой операционной системы не окажется, необходимо будет менять концепцию.
3.5. Вопросы затрат и цены
Для продаваемых внешним потребителям продуктов и многих приложений "для внутреннего использования" вопросы цены и затрат оказывают непосредственное влияние на определение и реализацию приложения. В данном разделе записывают ся все имеющиеся ограничения на затраты и цены. Например, затрать!, связанные с дистрибуцией (количество дискет и компакт-дисков, создание мастер-компакт диска), или другие затраты, входящие в стоимость проданных товаров (на руково дство, упаковку), могут оказывать влияние на успех проекта или не иметь особого значения, в зависимости от природы приложения.
4. Атрибуты функций
Как и требования, функции имеют атрибуты, предоставляющие дополнительную ин формацию, которую можно использовать для оценки, отслеживания и определения очередности предлагаемых для реализации элементов разработки, а также управле ния ими. Ниже мы описали атрибуты, которые можно использовать в документе-концепции. Вам нужно описывать в данном разделе только те атрибуты (и их значе ния), которые вы выберете, чтобы все участники могли лучше понять содержание каждой функции.
4.1. Статус
Задается в результате переговоров и рассмотрения руководством проекта. Ин формация о статусе отражает ход процесса определения базового уровня про екта. Атрибут статуса функции может иметь следующие значения.
• Предложена. Используется для описания обсуждаемых функций, которые еще не рассмотрены и не приняты "официальным органом" - рабочей группой, состоящей из представителей команды проекта, руководства и пользователей или заказчиков.
• Принята. Возможности, которые "официальный орган" признал полезны ми и достижимыми и принял к реализации.
• Включена, функции, включенные в базовый уровень на данный момент времени.
4.2. Приоритет
Приоритеты функций продукта задаются представителями маркетинга, ме неджером продукта или аналитиком базового уровня. Упорядочение функций по их относительной важности для конечного потребителя открывает диалог между заказчиками, аналитиками и членами команды разработчиков. Приори теты используются для управления масштабом и определения очередности разработки. Ниже предложена одна из возможных схем задания приоритетов.
• Критический. Основные функции. Если их не удастся реализовать, сис тема не будет удовлетворять потребности заказчика. В версии должны быть реализованы все критические функции, в противном случае график являет ся нереальным.
• Важный. Функции, важные для успешной и эффективной работы системы в большинстве приложений. Данные функциональные возможности нельзя легко обеспечить иным способом. Если важные функции не войдут в реали зацию, это может повлиять на удовлетворение пользователя или заказчика результатом работы или даже на доходы от продаж, но выпуск версии не должен задерживаться из-за нехватки некой важной функции.
• Полезный. Функции, которые нужны в менее распространенных прило жениях, будут использоваться не так часто или их можно достаточно эф фективно заменить другими действиями. Если они не войдут в реализацию, это не окажет заметного воздействия на отношение заказчика или доходы.
4.3. Уровень трудозатрат
Определяется командой разработчиков и используется для управления мас штабом и определения очередности разработки. Поскольку некоторые функ ции требуют больше времени и ресурсов, чем другие, оценка количества ко-мандо- или человеко-недель, строк кода или функциональных единиц помогает соразмерить сложность и оценить, что можно, а что нельзя осуществить за оп ределенный период времени.
4.4. Риск
Задается командой разработчиков на основе вероятности того, что данная функция вызовет нежелательные последствия для проекта, такие как превышение средств, отставание от графика или даже закрытие проекта. Большинство менеджеров про дукта считают достаточным деление рисков на категории низкий, средний, высокий, хотя возможна и более тонкая градация. Иногда риск можно оценить, измеряя меру неопределенности (диапазон) оценок времени работы команды.
4.5. Стабильность
Определяется аналитиком и командой разработчиков, исходя из вероятности того, что может измениться данная функция или понимание командой этой функции. Эта информация используется для того, чтобы помочь при опреде лении приоритетов разработки и выявить те элементы, для которых следую щим действием должно стать дополнительное исследование.
4.6. Целевая версия
Записывается, в какой версии продукта предполагается впервые реализовать данную функцию. Это поле можно использовать, чтобы поместить функции в базовый уровень конкретной версии. Комбинируя этот атрибут с полем стату са, команда может предлагать, записывать и обсуждать для версии различные функции, не приступая к их разработке. Будут реализовываться только функ ции, имеющие статус "Включенная", для которых определена целевая версия. При необходимости сокращения масштаба номер целевой версии может быть увеличен, так что элемент остается в документе-концепции, но его реализация будет отложена на более поздний срок.
4.7. Кому предназначена
Во многих проектах функции будут предназначаться "функциональным группам", ответственным за их дальнейшее исследование, написание программных требова ний, а также, возможно, реализацию. Это помогает членам команды разработчиков лучше понять свои обязанности.
4.8. Обоснование
Данное текстовое поле используется для отслеживания источника запраши ваемой функции. В этом поле записывается объяснение причины существова ния данной функции или ссылка на него. Например, ссылка может указывать на страницу, номер строки спецификации требований к продукту или времен ной маркер на видеозаписи важного интервью с клиентом.
5. Функции продукта
В данном разделе документируются функции продукта, которые обеспечивают необ ходимые возможности для удовлетворения потребностей пользователей. Каждая функция выполняет некую потребность пользователя. Например, функцией системы отслеживания состояния задачи может быть способность "предоставлять отчеты о выполнении". Отчеты о выполнении, в свою очередь, помогают пользователю "лучше понять состояние задачи".
Поскольку документ-концепция изучается широким кругом причастных к проекту лиц и служит основой для достижения соглашения, функции должны описываться на ес тественном языке пользователя. Описание функции должно быть кратким и ясным, как правило, одно-два предложения.
Для эффективного управления сложностью приложения мы рекомендуем, чтобы описание возможностей любой новой системы (или усовершенствования существую щей) производилось на достаточно высоком уровне абстракции и состояло из 25—99 функций. Эти функции составляют основу для определения продукта, а также управ ления масштабом и проектом в целом. Каждая из них будет описана более подробно в последующих спецификациях.
Каждая функция данного раздела должна описывать внешнее поведение системы, ко торое ощущается пользователями, операторами или другими внешними системами.
5.1. Функция 1
5.2. Функция 2
6. Основные прецеденты
Следует описать несколько основных прецедентов, которые важны для архитектуры или лучше всего помогут читателю понять, как предполагается использовать систему.
7. Другие требования к продукту
7.1. Применяемые стандарты
Перечисляются все стандарты, которым должен соответствовать продукт, та кие как законы и инструкции (FDA, FCC), коммуникационные стандарты (TCP/IP, ISDN), стандарты совместимости платформ (Windows, UNIX), a также стандарты качества и безопасности (UL, ISO, CMM).
7.2. Системные требования
Определяются все системные требования, необходимые для поддержки при ложения. Среди них могут быть поддерживаемые хостом операционные сис темы и сетевые платформы, конфигурации, память, периферические устрой ства и сопутствующее программное обеспечение.
7.3. Лицензирование и инсталляция
Вопросы лицензирования и инсталляции также могут оказывать непосредст венное воздействие на трудоемкость разработки. Например, необходимость обеспечения серийного выпуска продукта, поддержки системы безопасности на основе паролей или сетевого лицензирования будет создавать дополнительные системные требования, которые следует учитывать при разработке. Инсталля ционные требования могут также влиять на кодирование иди вызывать по требность в отдельном инсталляционном программном обеспечении.
7.4. Требования производительности
К вопросам производительности относятся фактор нагрузки, создаваемой пользователем, ширина коммуникационного канала, пропускная способность, точность, надежность или время ответа при различных условиях загрузки.
8. Требования к документации
В данном разделе описывается, какую документацию необходимо разработать для поддержки успешного внедрения приложения.
8.1. Руководство пользователя
Нужно описать цель и содержание руководства пользователя, рассмотреть его же лаемый объем, уровень детализации, потребность в индексе и глоссарии, а также, должно ли оно служить учебным пособием или скорее справочником и т.д. Следует также указать ограничения, связанные с форматированием и печатью.
8.2. Интерактивная подсказка
Многие приложения предлагают для помощи пользователю систему интерак тивных подсказок. Подобные системы имеют уникальную природу: они соче тают в себе моменты программирования (такие, как создание гиперссылок) с моментами написания технических текстов (такими, как организация и пре зентация). Многие считают, что разработка системы интерактивных подсказок является проектом внутри проекта, который весьма выиграет от предвари тельно проведенного ограничения масштаба и планирования действий.
8.3. Руководства по инсталляции, конфигурация и файл Read Me
Данный документ, содержащий инструкции по инсталляции и руководства по конфигурированию, важен для предложения всеобъемлющего решения. В ка честве стандартного компонента обычно включается файл Read Me. Он может содержать раздел "Что нового в данной версии" и обсуждение совместимости с более ранними версиями. Большинство пользователей также приветствуют на личие в данном файле документации, где указаны все известные недоработки.
8.4. Маркировка и упаковка
Современные приложения должны иметь соответствующее внешнее оформле ние, которое начинается с упаковки продукта и его самообъявления в инстал ляционных меню, открывающихся экранах, системах подсказок, GUI-диалогах и т.п. Примерами являются отметки об авторском праве и патентовании, а также логотипы компании, стандартизованные пиктограммы и другие графи ческие элементы и т.д.
9. Глоссарий
Глоссарий описывает все присущие данному проекту термины, в том числе все аббревиатуры, которые могут быть непонятны пользователю или другим читателям данно го документа.