4. Функциональные требования

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

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

1. Введение

1.1 Назначение

1.2 Соглашения, принятые в документах

1.3 Границы проекта

1.4 Ссылки

2. Общее описание

2.1 Общий взгляд на продукт

2.2 Классы и характеристики пользователей

2.3 Операционная среда

2.4 Ограничения дизайна и реализации

2.5 Предположения и зависимости

3. Функции системы

3.x Функция системы X

3.x.1 Описание

3.x.2 Функциональные требования

4. Требования к данным

4.1 Логическая модель данных

4.2 Словарь данных

4.3 Отчеты

4.4 Получение, целостность, хранение и утилизация данных

5. Требования к внешним интерфейсам

5.1 Пользовательские интерфейсы

5.2 Интерфейсы ПО

5.3 Интерфейсы оборудования

5.4 Коммуникационные интерфейсы

6. Атрибуты качества

6.1 Удобство использования

6.2 Производительность

6.3 Безопасность

6.4 Техника безопасности

6.x [Другие]

7. Требования по интернационализации и локализации

8. Остальные требования

Приложение A. Словарь терминов

Приложение Б. Модели анализа

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

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

1. Введение

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

1.1 Назначение

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

1.2 Соглашения, принятые в документах

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

1.3 Границы проекта

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

1.4 Ссылки

Перечислите все документы или другие ресурсы, на которые вы ссылаетесь в этой спецификации, в том числе гиперссылки на них, если их местоположение меняться не будет. Это могут быть руководства по стилям пользовательского интерфейса, контракты, стандарты, спецификации к системным требованиям, спецификации интерфейса и спецификации требований к ПО связанных продуктов. Объем информации должен быть достаточным для того, чтобы пользователь сумел при необходимости получить доступ к каждому указанному материалу, а именно: название, имя автора, номер версии, дата, источник, место хранения или URL-адрес.

2. Общее описание

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

2.1 Общий взгляд на продукт

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

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

2.2 Классы и характеристики пользователей

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

2.3 Операционная среда

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

2.4 Ограничения дизайна и реализации

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

2.5 Предположения и зависимости

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

Определите все зависимости проекта или создаваемой системы от внешних факторов или компонентов вне ее контроля. Например, до установки продукта может требоваться установить Microsoft .NET Framework 4.5 или более позднюю версию — это зависимость.

3. Функции системы

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

3.X Функция системы X

Опишите название особенности несколькими словами, например «3.1 Проверка правописания». Так же назовите подразделы с 3.x.1 по 3.x.3 для каждой функции системы.

3.X.1 Описание

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

3.X.2 Функциональные требования

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

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

Приложение а Спецификация требований к по

1. Введение

1.1. Назначение

Эта спецификация требований к ПО описывает функциональные и нефункциональные требования к выпуску 1.0 Cafeteria Ordering System (COS). Этот документ предназначен для команды, которая будет реализовывать и проверять корректность работы системы. Кроме специально обозначенных случаев, все указанные здесь требования имеют высокий приоритет и приписаны

к выпуску 1.0.

1.2. Соглашения, принятые в документах

В этой спецификации нет никаких типографских условных обозначений.

1.3. Границы проекта

Cafeteria Ordering System позволит сотрудникам Process Impact заказывать блюда в кафетерии компании через Интернет для доставки в указанные пункты на территории компании. Детальное описание продукта приведено в документе «Cafeteria Ordering System Vision and Scope Document» [1], где перечислены функции, полная или частичная реализация которых запланирована в этом выпуске.

1.4. Ссылки

1. Cafeteria Ordering System Vision and Scope Document, адреспорталасдокументами /COS Vision and Scope.docx

2. Process Impact Intranet Development Standard, версия 1.3 адреспорталасдокументами /PIIDS.pdf

2. Общее описание

2.1. Общий взгляд на продукт

Cafeteria Ordering System — это новая система, которая заменяет текущие ручные процессы заказа и получения обедов в кафетерии Process Impact.

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

Рис. 2.1 - Контекстная диаграмма для выпуска 1.0 системы Cafeteria Ordering System