Возможности поддержки

Задание 1

Структура SRS в RUP(Rational Unified Process) - представляет собой документ, в котором необходимо описать артефакты, полученные в процессе специфицирования требований.

Она состоит из следующих разделов:

1. Введение.

· 1. Цель.

· [Указывыается цель создания данного документа. "Спецификация программных требований" должна полностью описывать внешнее поведение определяемого приложения или подсистемы, нфункциональные требования, проектные ограничения и другие факторы, необходимые для полного и всестороннего описания требований к программному обеспечению.]

· 2. Краткая сводка возможностей.

· [Краткое описание программы, функции или группы подсистем, к которым относится данная спецификация. Указываются модели сценариев использования, с которыми она связана, и все прочие сведения, имеющие к ней отношение.]

· 3. Определения, акронимы и сокращения.

· [В этом разделе даются определения всех терминов, акронимов и сокращений, которые необходимы для правильной интерпретации документа "Спецификация программных требований". Данная информация может быть представлена в виде ссылки на словарь проекта.]

· 4. Ссылки.

· [В этом разделе дается полный список всех документов, на которые ссылается "Спецификация программных требований". Каждая ссылка должна содержать заголовок документа, номер отчета (при наличии), дату и название организации, опубликовавшей документ. Следует указать также, из каких источников могут быть получены эти сведения. Эта информация может быть представлена в виде ссылки на приложение или на другой документ.]

· 5. Краткое содержание.

· [Дается описание остальной информации из "Спецификации программных требований" и структуры этого документа.Пункт можно опустить]

2. Обзор системы

 

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

• перспектива продукта;

• функции продукта;

• пользовательские характеристики;

• ограничения;

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

3. Детальные требования

 

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

Функциональность

[В этом разделе описываются функциональные требования к системе, выражаемые естественным языком. Для многих приложений эти сведения составляют пакет спецификаций требований к системе (SRS), поэтому следует хорошо продумать структуру этого раздела. Как правило, этот раздел организуется по реализуемым функциям, однако, можно применить и альтернативные методы – например, организацию по пользователям или подсистемам. Функциональные требования могут включать в себя списки реализуемых функций, возможностей и средств обеспечения безопасности данных.

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

1.1.1. <Первое функциональное требование>

[Описание требования.]

Практичность

[В этот раздел следует включить все требования, имеющие отношение к практичности. Например:

• укажите необходимое время обучения обычных и квалифицированных пользователей, которое позволит им достичь высокой производительности при выполнении определенных операций;

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

• укажите требования общих стандартов практичности, например, стандартов общего пользовательского доступа (CUA) корпорации IBM или стандартов графического пользовательского интерфейса корпорации Microsoft.]

1.2.1. <Первое требование к практичности>

[Описание требования.]

Надежность

[Здесь должны быть описаны требования к надежности системы. Предполагается следующий вид раздела:

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

• среднее время безотказной работы (MTBF) – обычно указывается в часах, но может быть выражено в днях, месяцах или годах;

• среднее время устранения неисправностей (MTTR) – указывается допустимое время простоя системы после сбоя;

• точность – приводятся показатели четкости (разрешения) и точности (по какому-либо известному стандарту), которые требуются на выходе системы;

• максимально допустимое количество ошибок – обычно выражается в количестве ошибок на тысячу строк кода (KLOC), либо на количество реализуемых функций;

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

1.3.1. <Первое требование к надежности>

[Описание требования.]

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

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

• время реакции для операции (среднее, максимальное);

• производительность (например, число транзакций в секунду);

• полная мощность (например, число заказчиков или операций, которые может обслуживать система);

• режимы снижения производительности (опишите приемлемые режимы работы, при которых производительность системы каким-либо образом снижается);

• использование ресурсов: память, дисковое пространство, связь и т. д.]

1.4.1. <Первое требование к производительности>

[Описание требования.]

Возможности поддержки

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

1.5.1. <Первое требование к возможностям поддержки>

[Описание требования.]