руководство. спецификация требований

УТВЕРЖДЕНО
<Наименование организации Разработчика>
<Должность>
________________ <Ф.И.О.>
«____»_______________ 2006 г.
Спецификация требований
к программному обеспечению
Руководство по составлению
История версий
Версия
Дата
1.0
01.01.2006
Автор
Причина изменения
Иванов И.И.
Начальная версия документа
Спецификация требований к программному обеспечению. Руководство по составлению
2 из 20
Содержание
1. ВВЕДЕНИЕ ................................................................................................................................................................. 4
1.1.
1.2.
1.3.
1.4.
НАЗНАЧЕНИЕ ......................................................................................................................................................... 4
СОГЛАШЕНИЯ, ПРИНЯТЫЕ В ДОКУМЕНТАХ........................................................................................................... 4
ПРЕДПОЛАГАЕМАЯ АУДИТОРИЯ И РЕКОМЕНДАЦИИ ПО ЧТЕНИЮ ......................................................................... 4
ССЫЛКИ ................................................................................................................................................................. 4
2. БИЗНЕС-ТРЕБОВАНИЯ ......................................................................................................................................... 5
2.1.
2.2.
2.3.
2.4.
2.5.
ИСХОДНЫЕ ДАННЫЕ .............................................................................................................................................. 5
БИЗНЕС-ЗАДАЧИ ПРОДУКТА .................................................................................................................................. 5
БИЗНЕС-ЦЕЛИ ПРОДУКТА ...................................................................................................................................... 5
КРИТЕРИИ УСПЕХА ................................................................................................................................................ 5
БИЗНЕС-РИСКИ ...................................................................................................................................................... 5
3. ОБРАЗ И ГРАНИЦЫ ПРОЕКТА ........................................................................................................................... 6
3.1.
3.2.
3.3.
3.4.
ПОЛОЖЕНИЕ ОБ ОБРАЗЕ ПРОЕКТА ......................................................................................................................... 6
МАСШТАБЫ И ОГРАНИЧЕНИЯ ПРОЕКТА ................................................................................................................ 6
ПРЕДПОЛОЖЕНИЯ ОТНОСИТЕЛЬНО ПРОЕКТА ........................................................................................................ 7
ЗАВИСИМОСТИ ПРОЕКТА ....................................................................................................................................... 7
4. ОБЩЕЕ ОПИСАНИЕ............................................................................................................................................... 8
4.1.
4.2.
4.3.
4.4.
4.5.
4.6.
ОБЩИЙ ВЗГЛЯД НА ПРОДУКТ................................................................................................................................. 8
ОСОБЕННОСТИ ПРОДУКТА ..................................................................................................................................... 8
КЛАССЫ И ХАРАКТЕРИСТИКИ ПОЛЬЗОВАТЕЛЕЙ.................................................................................................... 8
ОПЕРАЦИОННАЯ СРЕДА ......................................................................................................................................... 8
ОГРАНИЧЕНИЯ ДИЗАЙНА И РЕАЛИЗАЦИИ .............................................................................................................. 8
ДОКУМЕНТАЦИЯ ДЛЯ ПОЛЬЗОВАТЕЛЕЙ ................................................................................................................ 9
5. ВАРИАНТЫ ИСПОЛЬЗОВАНИЯ ....................................................................................................................... 10
5.1. ПЕРЕЧЕНЬ ДЕЙСТВУЮЩИХ ЛИЦ .......................................................................................................................... 10
5.2. ПЕРЕЧЕНЬ ВАРИАНТОВ ИСПОЛЬЗОВАНИЯ ........................................................................................................... 10
5.3. ОПРЕДЕЛЕНИЯ ВАРИАНТОВ ИСПОЛЬЗОВАНИЯ .................................................................................................... 10
6. ФУНКЦИОНАЛЬНЫЕ ТРЕБОВАНИЯ ............................................................................................................. 14
7. ТРЕБОВАНИЯ К ВНЕШНЕМУ ИНТЕРФЕЙСУ ............................................................................................. 15
7.1.
7.2.
7.3.
7.4.
ИНТЕРФЕЙСЫ ПОЛЬЗОВАТЕЛЯ ............................................................................................................................. 15
ИНТЕРФЕЙСЫ ОБОРУДОВАНИЯ ............................................................................................................................ 15
ИНТЕРФЕЙСЫ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ ................................................................................................... 16
ИНТЕРФЕЙСЫ ПЕРЕДАЧИ ИНФОРМАЦИИ ............................................................................................................. 16
8. ДРУГИЕ НЕФУНКЦИОНАЛЬНЫЕ ТРЕБОВАНИЯ ...................................................................................... 17
8.1. ТРЕБОВАНИЯ К ПРОИЗВОДИТЕЛЬНОСТИ .............................................................................................................. 17
8.2. АТРИБУТЫ КАЧЕСТВА.......................................................................................................................................... 17
ПРИЛОЖЕНИЕ 1. СЛОВАРЬ ТЕРМИНОВ............................................................................................................ 18
ПРИЛОЖЕНИЕ 2. МОДЕЛИ АНАЛИЗА ................................................................................................................ 19
ПРИЛОЖЕНИЕ 3. СПИСОК ВОПРОСОВ.............................................................................................................. 20
Перечень таблиц
ТАБЛИЦА 2-1. ПЕРЕЧЕНЬ БИЗНЕС-ЗАДАЧ ............................................................................................................................ 5
ТАБЛИЦА 2-2. ПЕРЕЧЕНЬ БИЗНЕС-ЦЕЛЕЙ............................................................................................................................ 5
ТАБЛИЦА 3-1. ОБЪЕМ ВЕРСИЙ ............................................................................................................................................ 7
ТАБЛИЦА 3-2. ПРЕДПОЛОЖЕНИЯ ОТНОСИТЕЛЬНО ПРОЕКТА .............................................................................................. 7
ТАБЛИЦА 3-3. ЗАВИСИМОСТИ ПРОЕКТА ............................................................................................................................. 7
ТАБЛИЦА 4-1. ОГРАНИЧЕНИЯ ДИЗАЙНА И РЕАЛИЗАЦИИ .................................................................................................... 9
ТАБЛИЦА 5-1. ПЕРЕЧЕНЬ ДЕЙСТВУЮЩИХ ЛИЦ ................................................................................................................ 10
ТАБЛИЦА 5-2. ПЕРЕЧЕНЬ ВАРИАНТОВ ИСПОЛЬЗОВАНИЯ ................................................................................................. 10
ТАБЛИЦА 6-1. ФУНКЦИОНАЛЬНЫЕ ТРЕБОВАНИЯ ............................................................................................................. 14
ТАБЛИЦА 7-1. ИНТЕРФЕЙСЫ ПОЛЬЗОВАТЕЛЯ ................................................................................................................... 15
ТАБЛИЦА 7-2. ИНТЕРФЕЙСЫ ОБОРУДОВАНИЯ .................................................................................................................. 16
Спецификация требований к программному обеспечению. Руководство по составлению
3 из 20
ТАБЛИЦА 7-3. ИНТЕРФЕЙСЫ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ ......................................................................................... 16
ТАБЛИЦА 7-4. ИНТЕРФЕЙСЫ ПЕРЕДАЧИ ИНФОРМАЦИИ ................................................................................................... 16
ТАБЛИЦА 8-1. ТРЕБОВАНИЯ К ПРОИЗВОДИТЕЛЬНОСТИ .................................................................................................... 17
ТАБЛИЦА 8-2. АТРИБУТЫ КАЧЕСТВА................................................................................................................................ 17
Спецификация требований к программному обеспечению. Руководство по составлению
4 из 20
1. Введение
1.1. Назначение
В данном разделе необходимо определить продукт, требования для которого указаны в этом документе, в том числе его редакцию или номер выпуска. Если эта спецификация требований к программному обеспечению относится только к части системы, идентифицируйте эту часть или подсистему.
1.2. Соглашения, принятые в документах
В данном разделе описываются все стандарты, включая стили текста, особенности выделения
или замечания. Например, укажите, унаследован ли приоритет, указанный для требований высшего
уровня, всеми их детализированными требованиями, или каждое положение о функциональных требованиях должно обладать собственным приоритетом.
1.3. Предполагаемая аудитория и рекомендации по чтению
В данном разделе перечисляются пользователи, для которых предназначена эта спецификация
требований к программному обеспечению. Описывается содержание документа и его структура.
Приводятся рекомендации наиболее подходящих для каждого класса читателей последовательностей чтения документа.
1.4. Ссылки
В данном разделе перечисляются все документы или другие ресурсы, на которые ссылается эта
спецификация. Это могут быть руководства по стилям пользовательского интерфейса, контракты, стандарты, спецификации к системным требованиям, документы по вариантам использования,
спецификации интерфейса, концептуальные документы и спецификация требований к программному обеспечению для продуктов, на которые вы ссылаетесь. Объем информации должен быть достаточным для того, чтобы пользователь сумел при необходимости получить доступ к каждому
указанному материалу, а именно: название, имя автора, номер версии, дата и источник или расположение документа.
Спецификация требований к программному обеспечению. Руководство по составлению
5 из 20
2. Бизнес-требования
Данный раздел определяет бизнес-требования заказчика. Важно отметить, что в раздел включаются все бизнес-требования, сформулированные заказчиком, а не только принятые в конечном
варианте базовой спецификации. Для определения «действующих» бизнес-требований используется
соответствующее поле статуса.
2.1. Исходные данные
Данный раздел суммирует обоснование и содержание нового продукта. Здесь помещают общее
описание предыстории или ситуации, в результате которых было принято решение о создании продукта.
2.2. Бизнес-задачи продукта
Продукт (приводится наименование продукта) предназначен для решения следующих бизнесзадач:
Таблица 2-1. Перечень бизнес-задач
Идентификатор
BT-xx
Ста Вертус сия
Бизнес-задача
1.0
2.3. Бизнес-цели продукта
Бизнес-целями создания продукта (приводится наименование продукта) являются (цели формулируются в количественном и измеряемом виде):
Таблица 2-2. Перечень бизнес-целей
Идентификатор
BA-xx
Ста Вертус сия
Бизнес-цель
1.0
2.4. Критерии успеха
В данном разделе определяется, как заинтересованные лица будут определять и измерять успех
проекта. Необходимо установить факторы, которые максимально влияют на успех проекта – и те,
которые организация может контролировать, и те, которые находятся вне сферы ее влияния.
Определите меру для оценки того, были ли достигнуты бизнес-цели.
2.5. Бизнес-риски
Данный раздел обобщает важнейшие бизнес-риски, связанные с разработкой – или с не разработкой – продукта. В категорию рисков входят рыночная конкуренция, временные факторы, приемлемость для пользователей, проблемы, связанные с реализацией, и возможные негативные факторы,
влияющие на бизнес. Оцените возможные потери от каждого фактора риска, вероятность его возникновения и вашу способность контролировать его. Определите все возможные действия по смягчению ситуации.
Спецификация требований к программному обеспечению. Руководство по составлению
6 из 20
3. Образ и границы проекта
В этом разделе документа определяется стратегический образ системы, позволяющей выполнять бизнес-задачи и достичь поставленных бизнес-целей. Этот образ обеспечивает основу для
принятия решений в течение жизненного цикла продукта. В него не надо включать детали функциональных требований или информацию, связанную с планированием проекта.
Кратко опишите программное обеспечение и его назначение. Покажите, как связан продукт с
пользователями или корпоративными целями, а также с бизнес-целями и стратегиями.
Образ продукта выстраивает работу всех заинтересованных лиц в одном направлении. Он описывает, что продукт представляет собой сейчас и каким он станет впоследствии. Границы проекта показывают, к какой области конечного долгосрочного образа продукта будет направлен текущий проект. В положении о границах должна быть определена черта между тем, что входит в
проект и тем, что остается вовне. То есть указанные рамки также определяют ограничения проекта.
Говоря об образе, мы подразумеваем весь продукт. Поскольку образ продукта по определению
является высокоуровневой абстракцией, он будет изменяться относительно медленно при изменении со временем стратегии продукта или развитии бизнес-целей. Границы же относятся к определенному проекту– базовой или последующим версиям.
3.1. Положение об образе проекта
Составьте сжатое положение об образе продукта, обобщающее долгосрочные цели и назначение нового продукта. В этом разделе следует отразить сбалансированный образ, удовлетворяющий
различные заинтересованные лица. Он может быть несколько идеалистичным, но должен быть основан на существующих или предполагаемых рыночных факторах, архитектуре предприятия заказчика, стратегическом направлении развития предприятия заказчика и ограничениях ресурсов.
Далее показан шаблон, состоящий из ключевых слов, которые прекрасно подходят для определения образа продукта:
целевая аудитория покупателей продукта
для
который
потребности, удовлетворяемые продуктом, и/или возможности, предоставляемые
продуктом
эта (этот)
является
наименование продукта
категория продукта
который(ая)
ключевое преимущество, основная причина для покупки или использования
в отличие от основной конкурирующий продукт, текущая система или текущий бизнес-процесс
наш продукт положение об основном отличии и преимуществе нового продукта
3.2. Масштабы и ограничения проекта
В этом разделе вам необходимо указать, что может делать система, а что не может. Границы проекта определяют концепцию и круг действия предложенного решения. В ограничениях указываются определенные возможности, которые не будут включены в продукт. Рамки и ограничения
помогают установить реалистичные ожидания заинтересованных лиц.
Уточнение рамок определяет границу и связи системы, которую мы разрабатываем, со всем
остальным миром. Для более наглядного представления границ проекта желательно использовать
контекстную диаграмму. Она определяет оконечные элементы, расположенные вне системы, которые определенным образом взаимодействуют с ней, а также данные, элементы управления и материальные потоки, протекающие между оконечными элементами и системой. Контекстная диаграмма, по сути, представляет собой высший уровень абстракции в диаграммы потока данных. На
подобной диаграмме нет смысла показывать внутренние объекты системы, процессы и данные –
она вполне может быть представлена в виде единого объекта. Оконечные элементы обычно пред-
Спецификация требований к программному обеспечению. Руководство по составлению
7 из 20
ставляют классы пользователей, подразделения, другие системы или аппаратные комплексы. Главное назначение подобной диаграммы – наглядно показать, что находится за границами проекта.
Определение границы между тем, что входит и выходит за границы проекта, – отличный способ управления расползанием объема и ожиданиями клиентов.
Данный раздел по существу обобщает бизнес-требования, включенные в базовую версию продукта. Объем бизнес-требований (бизнес-задач и бизнес-целей), включенных в данный раздел, может
быть меньше объема соответствующих разделов определения бизнес-требований (разделы 2.2 и
2.3), в особенности, если планируется поэтапная разработка продукта.
При поэтапной разработке базовая версия не обязательно должна быть быстрой, красиво
оформленной или легкой в использовании, но она должна быть надежной; это основа работы команды. Необходимо помнить, что первая версия системы выполняет лишь базовые задачи. В будущие выпуски будут включены дополнительные функции, возможности и средства, обеспечивающие
легкость и простоту использования.
Таблица 3-1. Объем версий
Идентификатор
бизнес-требования
Базовая версия
Версия 2
Версия N
3.3. Предположения относительно проекта
Предположением называется положение, которое считается истинным при отсутствии определенной информации или доказательства противного. Проблемы возможны в том случае, если
предположение неверны, не находятся в совместном использовании или они изменяются, поэтому
определенные предположения можно отнести к группе рисков проекта. Один пользователь спецификации может считать, что продукт будут соответствовать особому стандарту пользовательского интерфейса, тогда как другой предположит нечто совершенно иное.
Разработчик может думать, что определенный набор функций написан специально для этого
приложения, аналитик – что он будет взят из предыдущего проекта, а менеджер проекта – что
предполагается приобрести коммерческую библиотеку функций.
Задокументируйте все предположения относительно проекта, сделанные заинтересованными
лицами, в процессе обсуждения. Часто предположения одних лиц не разделяют другие стороны. Если вы запишите их и просмотрите позже, то получите возможность обговорить основные положения проекта. Так вы избежите путаницы и ухудшения ситуации в будущем.
Таблица 3-2. Предположения относительно проекта
Идентификатор
A-xx
Ста Вертус сия
Предположение
1.0
3.4. Зависимости проекта
Определите все зависимости (dependencies) проекта от внешних факторов, такие, как изменения индустриальных стандартов или правительственных положений, сроки выпуска следующей версии операционной системы или выпуск каких-либо инструментальных, необходимых для реализации
проекта. Если вы планируете встроить в систему компоненты, разрабатываемые в другом проекте, то вы зависите от своевременной их поставки.
Таблица 3-3. Зависимости проекта
Идентификатор
D-xx
Ста Вертус сия
1.0
Зависимость
Спецификация требований к программному обеспечению. Руководство по составлению
8 из 20
4. Общее описание
В этом разделе представлен общий обзор продукта и среды, в которой он будет применяться,
предполагаемая пользовательская аудитория, а также известные ограничения, предположения и
зависимости.
4.1. Общий взгляд на продукт
Опишите содержание и происхождение продукта. Поясните, является он новым членом растущего семейства продуктов, новой версией существующей системы, заменой существующего приложения или совершенно новым продуктом. Если спецификация требований определяет компонент
более крупной системы, укажите, как это программное обеспечение соотносится со всей системой
и определите основные интерфейсы между ними.
Кроме того, приведите здесь сравнительную оценку существующих продуктов и возможных решений, указав, в чем заключается привлекательность продукта и его преимущества. Опишите проблемы, которые не удается разрешить без продукта. Покажите, насколько он соответствует
тенденциям рынка, развитию технологий или корпоративной стратегии. Кратко опишите другие
технологии, процессы или ресурсы, необходимые для удовлетворения клиента.
4.2. Особенности продукта
Перечислите основные особенности продукта или его главные функции. Детали будут изложены
в разделе 5 спецификации требований к программному обеспечению, здесь же следует их только
указать. Также здесь уместно проиллюстрировать основные группы требований и их взаимоотношения, например, показать диаграмму потоков данных высшего уровня, диаграмму основных вариантов использования.
4.3. Классы и характеристики пользователей
Определите различные классы пользователей, которые, как предполагается, будут работать с
вашим продуктом, и опишите их соответствующие характеристики. Некоторые требования могут относиться только к определенным классам пользователей. Определите привилегированные
классы пользователей
4.4. Операционная среда
Опишите рабочую среду программного обеспечения, включая аппаратные средства, операционные системы и их версии, а также географическое местоположение пользователей, серверов и баз
данных. Перечислите все остальные компоненты программного обеспечения или приложений, с которыми система должна быть совместима.
4.5. Ограничения дизайна и реализации
Опишите любые факторы, которые ограничат возможности, доступные разработчикам, и логически обоснуйте каждое положение. Ограничения могут быть такого рода:
 определенные технологии, средства, языки программирования и базы данных, которые следует
использовать или избегать;
 ограничения, налагаемые операционной средой продукта, например, типы и версии установленных Web-браузеров;
Спецификация требований к программному обеспечению. Руководство по составлению






9 из 20
обязательные соглашения или стандарты разработки (например, если обслуживать программное обеспечение будут клиенты, то они должны указать особенности дизайна и стандарты
программирования, которые должны быть соблюдены);
обратная совместимость с продуктами, выпущенными ранее;
ограничения, налагаемые бизнес-правилами (подробно они должны быть зафиксированы в других
документах);
ограничения, связанные с оборудованием, например, требования к срокам, ограничения памяти
или процессора, размер, вес, материалы или затраты;
соглашения, связанные с пользовательским интерфейсом существующего продукта, которые
необходимо соблюдать при улучшении существующего продукта;
стандартный формат обмена данными, например XML.
Таблица 4-1. Ограничения дизайна и реализации
Идентификатор
C-xx
Ста Вертус сия
Ограничение
1.0
4.6. Документация для пользователей
Перечислите все компоненты пользовательской документации, поставляемые с исполняемым
программным обеспечением. В них могут входить руководства для пользователя, онлайн-справка и
обучающие программы. Определите все необходимые форматы, стандарты и средства поставки
документации.
Спецификация требований к программному обеспечению. Руководство по составлению
10 из 20
5. Варианты использования
В этом разделе должны быть представлены варианты использования, которые являются основой для функциональных требований.
При написании вариантов использования следует избегать слишком большой детализации описаний и включения в варианты использования особенностей пользовательского интерфейса. И то, и
другое делают варианты использования слишком длинными, неудобочитаемыми и нестабильными.
5.1. Перечень действующих лиц
В этом разделе приводится перечень действующих лиц, т.е. лиц, играющих особую роль, систем
программного обеспечения или аппаратных устройств, которые взаимодействуют с системой для
достижения полезных целей.
Таблица 5-1. Перечень действующих лиц
Идентификатор
Действующее лицо
ACT-xx
5.2. Перечень вариантов использования
В этом разделе приводится перечень вариантов использования, упорядоченный по первичным
действующим лицам. Подробные определения приводятся в следующем разделе.
Таблица 5-2. Перечень вариантов использования
ПриДейств. Иденти- Ста
Верорилицо фикатор тус
сия
тет
ACT-xx
UC-xx
Вариант использования
1.0
5.3. Определения вариантов использования
Указывается уникальный идентификатор варианта использования, например, UC-01
Указывается краткое наименование варианта использования, отНаименование
ражающее его суть
Действующее лицо – это человек или объект, внешний по отПервичное действующее
ношению к системе, который взаимодействует с системой и ислицо
полняет вариант использования для выполнения определенных задач. Различные действующие лица соответствуют различным
классам пользователей или ролям, идентифицирующим различные
способы использования продукта. В этой секции необходимо указать действующее лицо, которое инициирует данный вариант использования.
В этой секции необходимо указать любые другие действующие
Другие действующие лица
лица, которые будут принимать участие в завершении варианта
использования
В этой секции необходимо привести краткое описание причин
Описание
и результата этого варианта использования, или высокоуровневое
описание последовательности действий и результата выполнения
варианта использования.
Составьте список действий, которые должны иметь место,
Предварительные условия
Идентификатор
Спецификация требований к программному обеспечению. Руководство по составлению
Идентификатор
Наименование
Выходные условия
Нормальный поток
развития
Альтернативный поток
развития
Исключения
Включение
11 из 20
Указывается уникальный идентификатор варианта использования, например, UC-01
Указывается краткое наименование варианта использования, отражающее его суть
или условий, которые должны быть верны, перед тем, как вариант использования сможет быть запущен. Нумеруйте каждое
предварительное условие.
Опишите состояние системы по завершении выполнения варианта использования. Нумеруйте каждое выходное условие.
Обеспечьте детальное описание пользовательских действий и
системных ответов, которые будут иметь место в ходе выполнения варианта использования в нормальных, ожидаемых условиях.
Эта последовательность диалога будет, в конечном счете, приводить к выполнению цели, заявленной в названии варианта использования и его описании.
Это описание можно составлять как ответ на гипотетический вопрос: “Как я достигаю задачи, заявленной в имени варианта использования?” Наиболее удобно представить это описание
как пронумерованный список действий, выполняемых действующим лицом, и ответов, обеспечиваемых системой.
Нормальный поток идентифицируется как «X.0», где «X» –
идентификатор варианта использования. Например, нормальный
поток варианта использования UC-15 будет обозначаться как
UC-15.0.
Все другие легитимные сценарии использования, которые могут иметь место в пределах данного варианта использования, следует документировать отдельно в этой секции. Заявите все альтернативные потоки и опишите последовательность их шагов.
Каждый альтернативный поток идентифицируется как
«X.Y», где «X» – идентификатор варианта использования, а «Y» –
порядковый номер альтернативного потока. Например, UC-15.3
указывает на третий альтернативный поток для варианта использования UC-15.
Опишите любые ожидаемые состояния ошибки, которые могут происходить в ходе выполнения варианта использования, и
определите, как система должна на них реагировать. Также опишите, как система должна реагировать, если выполнение варианта использования терпит неудачу по непредвиденным причинам.
Если вариант использования приводит к изменению состояния
базы данных или изменению состояния во внешнем окружении,
необходимо определить должно ли наличие ошибки при изменении
вызвать полный откат к предыдущему состоянию, частичный
откат к известному состоянию или же состояние должно
остаться неопределенным вследствие исключения.
Каждое исключение идентифицируется как «X.Y.E.Z», где «X»
– идентификатор варианта использования, «Y» – нормальный поток (0) или альтернативный поток (>0), «E» признак исключения,
а «Z» – порядковый номер исключения. Например, UC-15.0.E.2
определяет второе исключительное состояние для нормального
потока варианта использования UC-15.
Общая функциональность, которая появляется во множественных вариантах использования, может быть выделена в отдельные варианты использования, которые используются везде,
где необходима эта общая функциональность.
Если данный вариант использования использует подобную общую функциональность («включает в себя» другие варианты использования), то в данной секции следует привести список иден-
Спецификация требований к программному обеспечению. Руководство по составлению
Идентификатор
Наименование
Частота использования
Ссылки
Предположения
Замечания и вопросы
Идентификатор
Наименование
Первичное действующее
лицо
Другие действующие лица
Описание
Указывается уникальный идентификатор варианта использования, например, UC-01
Указывается краткое наименование варианта использования, отражающее его суть
тификаторов включаемых вариантов использования.
Оцените количество выполнений этого варианта использования за определенный период времени.
В данной секции следует привести список идентификаторов
бизнес-требований, обуславливающих данный вариант использования, влияющих на него бизнес-правил, а также указать любые дополнительные требования, как например нефункциональные требования, для варианта использования, к которым, возможно, будет нужно обратиться в ходе проектирования или реализации.
Сюда же можно включить требования к производительности или
атрибуты качества
Составьте список любых предположений, сделанных в ходе
анализа и обсуждения этого варианта использования, а также его
описания.
Составьте список любых дополнительных комментариев об
этом варианте использования, а также перечень открытых вопросов. Все открытые вопросы должны быть изложены в формате «НО» (необходимо определить) с указанием ответственного
и даты исполнения.
UC-01
Запросить товар
Сотрудник, размещающий заказ на товар
Нет
Сотрудник, разместивший заказ на товар, указывает в запросе
необходимый товар, вводя его название или номер идентификатора товара, или выбирая товар из каталога, или вводя специальным
сканером штрих-код товара. Система выполняет запрос, предлагая товар, имеющийся на складе, или позволяя создать запрос на
заказ у стороннего поставщика
Предварительные условия 1.
2.
3.
Выходные условия
1.
Нормальный поток
развития
12 из 20
Личность пользователя аутентифицирована.
Пользователь имеет право запрашивать товары.
База данных по запасам товаров в данный момент подключена.
Запрос сохраняется в Реестре запросов.
2. Запрос отправляется по электронной почте на склад товаров
или поставщику.
UC-01.0. Запросить товар со склада
1. Сотрудник указывает требуемый товар.
2. Система подтверждает, что такой товар доступен.
3. Система перечисляет контейнеры с необходимым товаром,
имеющиеся на складе.
4. Сотрудник может просмотреть историю любого контейнера.
5. Сотрудник выбирает определенный контейнер или просит отправить запрос поставщику (альтернативное направление
UC-01.1).
6. Сотрудник вводит остальную информацию, чтобы завершить
запрос.
7. Система сохраняет запрос и отправляет его по электронной
Спецификация требований к программному обеспечению. Руководство по составлению
Идентификатор
Наименование
Альтернативный поток
развития
Исключения
Включение
Частота использования
Ссылки
Предположения
Замечания и вопросы
13 из 20
UC-01
Запросить товар
почте на склад товаров.
UC-01.1. Запросить товар у поставщика (ответвление после
этапа 5)
1. Сотрудник ищет товар по каталогам поставщика.
2. Система отображает список поставщиков, где также указаны размеры и цена контейнеров.
3. Сотрудник выбирает поставщика, размер, класс и количество
контейнеров.
4. Сотрудник вводит остальную информацию, чтобы завершить
запрос.
5. Система сохраняет запрос и отправляет его по электронной
почте поставщику.
UC-01.0.E.1. Товар не доступен (на этапе 2)
1. Система отображает сообщение «Товар не существует».
2. Система спрашивает сотрудника, хочет ли он запросить другой товар или завершить работу.
Вариант 1
Вариант 2
3. Сотрудник просит запро3. Сотрудник решает заверсить другой товар.
шить работу.
4. Система заново начинает
4. Система завершает варинормальное направление
ант использования.
развития варианта использования.
UC-01.0.E.2. Товара нет в продаже (на этапе 5)
1. Система отображает сообщение «Нет поставщика этого
товара».
2. Система спрашивает сотрудника, хочет ли он запросить другой товар или завершить работу.
Вариант 1
Вариант 2
3. Сотрудник просит запро3. Сотрудник решает заверсить другой товар.
шить работу.
4. Система заново начинает
4. Система завершает варинормальное направление
ант использования.
развития варианта использования.
UC-22
Используется примерно 100-300 раз каждым менеджером по продажам в течение операционного дня
BR-30
1. Импортированные из драйверов сканеров штрих-коды должны
быть достоверными.
1. Иванов И.И. должен выяснить необходимо ли одобрение руководства при заказе товаров на сумму, превышающую определенное значение, и если необходимо, то какова эта сумма. Дата выполнения 14.06.2006
Спецификация требований к программному обеспечению. Руководство по составлению
14 из 20
6. Функциональные требования
Поскольку функциональные требования упорядочиваются по вариантам использования, для их
идентификации используется схема вида FR-uc-xx, где uc – номер соответствующего варианта использования, а xx – порядковый номер функционального требования. Для всех функциональных требований, которые не связаны с конкретными вариантами использования, или являются общими для
нескольких вариантов использования рекомендуется в качестве номера варианта использования указывать нулевое значение В этом случае простое упорядочение таблицы по полю «Идентификатор»
автоматически обеспечивает соответствующую группировку.
При определении функциональных требований для каждого варианта использования следует указать не только функции, необходимые для нормального потока развития, но и определить, как продукт должен реагировать на ожидаемые ошибки, неправильный ввод информации или неверные действия.
Также следует сделать оговорку о приоритетности функциональных требований. Их приоритет может устанавливаться независимо или же наследоваться от соответствующих вариантов
использования.
Таблица 6-1. Функциональные требования
ПриИденти- Ста
Верорификатор тус
сия
тет
FR-uc-xx
1.0
Функциональное требование
Спецификация требований к программному обеспечению. Руководство по составлению
15 из 20
7. Требования к внешнему интерфейсу
Требования к внешнему интерфейсу определяют оборудование, программное обеспечение или
элементы баз данных, с которыми система или компонент должны взаимодействовать. Информация этого раздела позволяет вам быть уверенным, что система будет должным образом взаимодействовать с внешними компонентами. Если у разных частей продукта разные внешние интерфейсы, вставьте подобный раздел в детализированные требования для каждой такой части.
Вставьте подробные описания компонентов данных и элементов управления интерфейса в словарь данных. В сложной системе с множеством подкомпонентов следует использовать раздельные
спецификации для интерфейсов или спецификацию системной архитектуры. В документацию по
интерфейсу можно включить ссылки на материал из других документов. Например, ссылка на спецификацию программного интерфейса другого приложения (API) или на руководство по работе с
устройством, где перечислены коды с ошибками, которые устройство может отправить программному обеспечению.
7.1. Интерфейсы пользователя
Опишите логические характеристики каждого пользовательского интерфейса, который необходим системе, например:
 ссылки на стандарты графического интерфейса пользователей или стилевые рекомендации для
семейства продукта, которые необходимо соблюдать;
 стандарты шрифтов, значков, названий кнопок, изображений, цветовых схем, последовательностей полей вкладок, часто используемых элементов управления и т.п.;
 конфигурация экрана или ограничения разрешения;
 стандартные кнопки, функции или ссылки перемещения, одинаковые для всех экранов, например
кнопка справки;
 быстрые клавиши;
 стандарты отображения сообщений;
 стандарты конфигурации для упрощения локализации программного обеспечения;
 специальные возможности для пользователей с проблемами со зрением.
Детально документировать детали пользовательского интерфейса, вплоть до таких деталей,
как конфигурации конкретных диалоговых окон, в спецификации не целесообразно, поскольку эти
вопросы скорее прерогатива дизайна, а не требований к проекту. Конечно, добавить еще одну точку
зрения на требования полезно, но необходимо подчеркнуть, что эти модели не являются официальными планами экрана.
Если в спецификации требований к программному обеспечению говорится об улучшении существующей системы, то стоит включить в документ изображения экранов в том виде, как они будут реализованы. Для разработчиков уже заданы ограничения существующей системой, поэтому
можно заранее представить, как будут выглядеть измененные, а, возможно, новые экраны.
Таблица 7-1. Интерфейсы пользователя
Идентификатор
IU-xx
Ста Вертус сия
Интерфейс пользователя
1.0
7.2. Интерфейсы оборудования
Опишите характеристики каждого интерфейса между компонентами программного обеспечения и оборудованием системы. В описание могут входить типы поддерживаемых устройств, протоколы обмена данными между программным обеспечением и оборудованием, а также протоколы
взаимодействия, которые будут использоваться.
Спецификация требований к программному обеспечению. Руководство по составлению
16 из 20
Таблица 7-2. Интерфейсы оборудования
Идентификатор
IH-xx
Ста Вертус сия
Интерфейс оборудования
1.0
7.3. Интерфейсы программного обеспечения
Опишите соединения продукта и других компонентов программного обеспечения (идентифицированные по имени и версии), в том числе базы данных, операционные системы, средства, библиотеки и интегрированные коммерческие компоненты. Укажите назначение элементов сообщений,
данных и элементов управления, обмен которыми происходит между компонентами программного
обеспечения. Опишите службы, необходимые внешним компонентам программного обеспечения, и
природу взаимодействия между компонентами. Определите данные, к которым будут иметь доступ компоненты программного обеспечения. Если механизм предоставления общего доступа к данным должен быть реализован определенным способом, например в качестве глобальной области
данных, то укажите его как ограничение.
Таблица 7-3. Интерфейсы программного обеспечения
Идентификатор
IS-xx
Ста Вертус сия
Интерфейс программного обеспечения
1.0
7.4. Интерфейсы передачи информации
Укажите требования для любых функций взаимодействия, которые будут использоваться продуктом, включая электронную почту, Web-браузер, протоколы сетевого соединения и электронные
формы. Определите соответствующие форматы сообщений. Опишите особенности безопасности
взаимодействия или шифрования, частоты передачи данных и механизмов синхронизации и т.п.
Таблица 7-4. Интерфейсы передачи информации
Идентификатор
IC-xx
Ста Вертус сия
1.0
Интерфейс передачи информации
Спецификация требований к программному обеспечению. Руководство по составлению
17 из 20
8. Другие нефункциональные требования
В этом разделе описываются остальные нефункциональные требования, не относящиеся к требованиям к интерфейсу и к ограничениям.
8.1. Требования к производительности
Требования к производительности определяют, насколько быстро и качественно система
должна выполнять определенные функции. Они определяют такие параметры, как скорость
(например, время отклика БД), пропускная способность (количество транзакций в секунду), мощность (нагрузка при совместном использовании) и распределение по времени (интенсивные запросы
реального времени). Жесткие требования к производительности сильно влияют на стратегию разработки программного обеспечения и выбор оборудования, поэтому определите задачи, касающиеся
производительности, для соответствующей операционной среды. Все пользователи хотят, чтобы
их приложение запускалось моментально, но реальные требования к производительности быть обусловлены важностью соответствующих функций для реализации бизнес-требований. Требования к
производительности также должны учитывать снижение производительности при перегрузках.
Таблица 8-1. Требования к производительности
Идентификатор
PR-xx
При
Ста
Вероритус
сия
тет
Требование к производительности
1.0
8.2. Атрибуты качества
Естественно, что пользователей, как правило, интересуют функциональные, или поведенческие,
требования – то есть возможности, предоставляемые ПО, однако для успеха ПО недостаточно
правильно реализовать соответствующую функциональность. Кроме того, пользователей волнует,
насколько хорошо новая система будет работать. К характеристикам, описывающим это свойство системы, относятся легкость использования, быстрота запуска, количество сбоев и обработка неожиданных ситуаций. В целом они называются атрибутами качества ПО или факторами качества и считаются частью нефункциональных (или неповеденческих) требований к системе.
Атрибуты качества можно разделить на очевидные характеристики, главным образом важные
для пользователей (доступность, эффективность, гибкость, целостность, способность к взаимодействию, надежность, устойчивость к сбоям, удобство и простота использования), и скрытые
качества, которые имеют значение для службы технической поддержки (легкость в эксплуатации,
мобильность, возможность повторного использования, тестируемость). Последние косвенно влияют на мнение клиента, так как упрощают возможные изменения продукта, его корректировку, проверку и переход на другие платформы.
Таблица 8-2. Атрибуты качества
Идентификатор
QA-xx
При
Ста
Вероритус
сия
тет
1.0
Атрибут качества
Спецификация требований к программному обеспечению. Руководство по составлению
18 из 20
Приложение 1. Словарь терминов
Поясните термины, которые пользователю необходимо знать для правильного понимания спецификации требований к программному обеспечению, включая сокращения и аббревиатуры. Расшифруйте каждое сокращение и приведите его определение.
Сокращение, термин
Расшифровка сокращения или термина
Спецификация требований к программному обеспечению. Руководство по составлению
19 из 20
Приложение 2. Модели анализа
В этом разделе приводятся модели анализа такие, как диаграммы потока данных, диаграммы
классов, диаграммы перехода состояния, диаграммы «сущность – связь», которые иллюстрируют
требования данной спецификации. Виды и количество моделей определяются спецификой проекта.
Спецификация требований к программному обеспечению. Руководство по составлению
20 из 20
Приложение 3. Список вопросов
Это динамический список еще не разрешенных проблем, связанных с требованиями. Это могут
быть элементы, помеченные как НО (необходимо определить), отложенные решения, необходимая
информация, неразрешенные конфликты и т.п. Все это не обязательно включать в спецификацию
требований к программному обеспечению, но в некоторых организациях принято прилагать данный
список к спецификации требований к программному обеспечению.