Системные требования к проекту "<название_проекта>"¶
<_Этот документ должен содержать формализованные требования заказчика в выполняемому проекту, созданные на основе Технического Задания. Цель документа - представить описание разрабатываемого продукта в виде "чёрного ящика", т.е. воздействия, оказываемые на него со стороны предметной области, и его реакции на эти воздействия. Этот же документ будет в последствии выполнять роль спецификации, по которой будет осуществляться сдача-приёмка проекта заказчику. Весь текст данного шаблона с применением курсива, заключённый в угловые скобки, должен быть либо заменён на конкретные сведения о проекте, либо удалён_.>
- Table of contents
- Системные требования к проекту "<название_проекта>"
Введение
h3. Назначение проекта
<Опишите здесь кратко проект, требования к которому приводятся в этом документе. Опишите здесь также, к каой части проекта относится данный документ, потому что довольно часто спецификация покрывает не весь проект, а только какую-то его часть.>
Ссылки¶
<Если есть ссылки на другие документы, Web-страницы или SRS, перечислите их в этом разделе. Постарайтесь также упомянуть все необходимые реквизиты такого документа, чтобы облегчить читающему поиск и идентификацию этого документа (например, название, автора, дату выпуска, версию документа etc)>
Общее описание
h3. Развитие проекта
<Опишите в этом разделе, является ли проект самостоятельным продуктом, или развитием существующей системы, или развитием линейки продуктов. Если данный продукт является одним из компонентов какой-то большой системы, то укажите здесь положение и роль компонента среди других компонентов системы. Тут очень поможет диграммка или рисунок, на котором бы показывалось положение компонента, его связи и внешние интерфейсы.>
Основные функции¶
<Опишите в этом разделе основные или наиболее значимые функции продукта, которые он будет выполнять или позволит выпоолнять заказчику. Подробное описание их будет приведено в Разделе 3, поэтому здесь нужно только общее, ретроспективное их описание, дабы составить себе общее представление о продукте. Постарайтесь написать это так, чтобы это было понятно любому, кто будет читать данный документ (даже менеджеру ;-)). Очень облегчить дело может диаграмма, на которой были бы представлены основные группы требований и взаимосвязи между ними, и/или диаграмма потоков данных, и/или диаграмма классов etc>
Классы пользователей и их характеристики¶
<Постарайтесь определить здесь классы пользователей данного продукта. Это может быть разделение по частоте обращения к данному продукту, по по техническому уровню, по уровням доступа etc. Опишите, особенности каждого класса. В дальнейшем это поможет сформировать правильные технологические цепочки, определить специфические требования для каждого класса и правильно распределить приоритеты.>
Операционная среда¶
<Приведите здесь по возможности полное описание операционной среды, включая версии операционных систем, железо, на котором этот продукт должен работать, а также названия и версии других приложений и компонент, с которыми должен работать этот продукт. Список, приведённый в этом разделе, будет служить основанием для сдачи-приёмки проекта, а также будет являться основанием для заключения дополнительных соглашений по разработке.>
Ограничения разработки¶
<Опишите здесь любые фишки, которые будут ограничивать разработчиков в процессе разработки. Это могут быть внутренние правила, принятые в компании, ограничения по железу (время, память и другие ресурсы), интерфейсы с другими приложениями, специальные утилиты, технологии, базы данных, языки программирования, параллельные операции, протоколы обмена, ограничения безопасности etc>
Документация пользователя¶
<Перечислите здесь, какая пользовательская документация должна поставляться в составе данного проекта (руководства пользователя, обучалки, on-line help). Во избежание лишних вопросов и недоразумений можно также указать, в каком формате они будут поставляться.>
Функции системы¶
<Этот шаблон показывает, как правильно организовать требования к основным функциям и сервисам проекта. Этот раздел можно разбить по use case-ам, по режимиам работы, по классам пользователей, по классам объектов, по функциональной иерархии, по их комбинациям, вобщем, по любым логическим критериям, которые больше всего годятся для разрабатываемого продукта.>
Функция 1¶
<На самом деле не называйте её pls "Функция 1". Дайте ей какое-то более осмысленное название.>
Описание и приоритет¶
<Приведите здесь общее описание этой функции и укажите её приоритет: Низкий, Средний или Высокий. Можно также включить важность отдельных её компонент, указать возможные риски и неустойки.>
Последовательность взаимодействия¶
<Перечислите здесь список возможных действий пользователя и реакций системы на эти действия. Можно также включить сюда диаграммы и use case-ы для большей наглядности.>
Функциональные требования¶
<Здесь нужно перечислить функциональные требования к этой функции. Это возможности системы, которые должны быть реализованы, чтобы дать пользователю возможность выполнить перечисленные в предыдущем пункте действия. НЕобходимо также учесть ошибочные и исключительные ситуации. Требования по возможности должны быть лаконичными, полными, недвусмысленными, нужными и проверяемыми. Если для полного описания информации недостаточно, используйте аббревиатуру ’TBD.>
<Каждому требованию желательно присвоить уникальный номер или тэг, типа этого:>
REQ-1:
REQ-2:
Функция 2¶
…
Требования к интерфейсу
h3. Интерфейс с пользователем
<Опишите здесь логические характеристики каждого интерфейса между пользователем и системой. Сюда можно включить примеры окон, стилей, различных стандартов, тем, горячих клавиш, сообщений об ошибках и т.д. Определите компоненты системы, для которых нужен этот интерфейс.>
Интерфейс с аппаратным обеспечением¶
<Здесь нужно описать интерфейс с железными компонентами системы. Это может быть тип поддерживаемых устройств, передаваемые данные, протоколы обмена etc>
Программный интерфейс¶
<Опишите здесь связи данного продукта с другими программными компонентами (название и версия), включая базы данных, ОС, утилиты, библиотеки и интегрированные компоненты. Определите и опишите передаваемы данные и сообщения, а также их назначение. Укажите необходимые сервисы и протоколы обмена. Определите общие данные и методы доступа к ним. При необходимости какого-то специального способа доступа, укажите ограничения этого способа.>
Интерфейс передачи данных¶
<Приведите здесь требования, касающиеся передачи данных, включая e-mail, Web браузер, протоколы сетевого обмена, электронные формы etc. Определите формат сообщений и стандарты протоколов. Можно также указать механизмы синхронизации, методы разделения прав доступа и криптования.>
Другие нефункциональные требования
h3. Требования к производительности
<Если есть какие-то требования к производительности системы, то укажите их здесь и объясните, с чем это связано, чтобы помочь разработчикам определить наиболее оптимальный способ. Для систем реального времени определите временные интервалы. Определите эти требования как можно точнее. Возможно, для каждого компонента будут нужны свои индивидуальные требования.>
Требования по надёжности¶
<Приведите здесь требования, касающиеся возможной потери, повреждения или утечки данных. Определите методы борьбы с ними и методы пресечения попыток повреждения данных. Сошлитесь на стандарты надёжности, которые должны быть соблюдены.>
Требования по безопасности¶
<Определите здесь все требования к системе доступа и защиты продукта. Определите, какие медоты идентификации и авторизации будут использоваться. Сошлитесь на стандарты безопасности, которые должны быть соблюдены.>
Требования по качеству¶
<Определите любые дополнительные требования по качеству, которые важны для пользователей и/или разработчиков. Например: адаптируемость, доступность, правильность, гибкость, совместимость, лёгкость сопровождения, переносимость, надежность, возможность повторного использования, надежность, управляемость, удобство и простота использования. Постарайтесь разъяснить акценты на различные признаки, такие как лёгкость использования по отношению к лёгкости обучения etc>
Другие требования¶
<Добавьте сюда другие требования, которые не покрываются этой SRS. Они могут включать требования к базам данных, локализации, повторного использования etc. Добавьте дополнительные разделв при необходимости.>
Приложение 1: Словарь терминов¶
<Сюда нужно включить список специфических терминов, акронимов и аббревиатур, ежели таковые используются в этом документе. Лучше в алфавитном порядке>
Приложение 2: Анализируемые модели¶
<Это необязательное приложение, куда можно включить различные анализируемые модели, например, диграммы передачи данных, диаграммы классов, диаграммы состояний, диаграммы отношений между объектами etc>
