Для чего разрабатываются спецификации на программный продукт
Правила составления Software requirements specification
Все мы прекрасно знаем о том, как разрабатывается ПО. Подумали 10 минут и сразу пошли кодить. Цикл создания программного обеспечения состоит из многих ключевых моментов. Это такие моменты как планирование, создания архитектуры, создание SRS, создание дизайна и тд и тп.
SRS — Software Requirement Specification — специальная документация для ПО которая содержит в себе информацию о том, как должна себя вести система, какие функции должна выполнять, какую нагрузку должна выдерживать и тд.
Все предельно просто. Вы используете ТЗ (велосипед), я использую SRS (машину). Надеюсь аналогия получилась ясная? 🙂
Структура SRS
Ниже приведена структура на англ языке в raw виде. Чуть ниже в статье мы рассмотрим каждый пункт более подробно
И так со структурой разобрались, теперь перейдем к разделам и тому, что в них надо писать.
Базовые требования ко всем разделам SRS
Пояснение каждого пункта структуры SRS
Introduction \ Purpose
В данной секции описываем приложение или продукт, функционал которого будет описываться в SRS.
Introduction \ Document conventions
Здесь мы описываем все непонятные технические слова или термины которые встречаются в SRS. Заметьте, что описание непонятного слова не может содержать другое непонятное слово. Старайтесь расписать как можно подробнее термин который Вы используете простым и понятным всем языком. Не экономьте на этой секции потому, что чем больше вы распишете непонятных вещей, тем проще будет потом проектировать.
Introduction \ References
В данной секции мы пишем ссылки на литературу в которой можно найти основания использованных технологий и фактов. Допустим можно вставлять RFC если вы пишете приложение работающее с TCP/IP, вставлять ссылки на документы на которые вы ссылаетесь и тд. Ссылки и их описание должны быть максимально полными, чтобы в случае чего (линк умер просто) можно было нагуглить этот материал.
Overall Description \ Product features
В данном разделе мы описываем части функционала на высоком уровне. Более детально каждая часть функционала будет описана в своем разделе ниже. Тут желательно разместить DFD-диаграмму которая покажет общее взаимодействие системы.
Overall Description \ Operating environment
Как понятно из названия раздела тут мы описываем окружение в котором будет работать продукт. ОС, версии компиляторов, базы данных, сервера, софт, железо и другие вещи которые необходимы для работы вашего продукта.
Overall Description \ User documentation
Описываем какая документация нужна для пользователей данного продукта. Возможно это книга по HTML если это HTML редактор.
System features \ System feature X
Называем фичу проекту и даем ей уникальный идентификатор. Например, server.html.editor. Уникальный идентификатор дается для того, чтобы потом где то в тикетах ваших не писать — «а вот та хреновина, которая позволяет редактировать хтмл»
System features \ System feature X \ Description and priority
Описываем детально фичу продукта. Для чего она? Что должна делать? Какой у нее приоритет выполнения. Из этого раздела читающему срс человеку должно сразу стать понятно зачем этот функционал присутствует в системе.
System features \ System feature X \ Stimulus/Response sequences
Триггер запуска фичи. Когда она запускается и как себя ведет при запуске? Например, HTML редактор показывается при нажатии пользователя на ссылку меню Открыть HTML редактор
System features \ System feature X \ Functional requirements
Подробное и детальное описание фичи. Описываем все: как работает, как реагирует на ошибки, что должно проверять, как отображать данные, как и куда что сохраняет и тд
External interface requirements
Описание того как система будет взаимодействовать с внешним миров. Если будет конечно. Какие API, как получить те или иные данные и тп. Подразделы служат для детализации требований. Какие софт интерфейсы, «железячные» интерфейсы, комуникационные интерфейсы и прочее.
Non functional requirements
Не функциональные требования. Есть требования которые невозможно описать как какую то фичу, например, требования к безопасности.
Non functional requirements \ Performance requirements
Требования к производительности. Это не фича, однако налагает определенные ограничения. Допустим база данных проекта должна выдерживать 1000 запросов в секунду и тп. Эти требования приводят к колоссальной работе по оптимизации проекта.
Non functional requirements \ Software quality attributes
Тут мы описываем требования к качеству кода. Какие тесты использовать? Какие метрики использовать для определения качества кода? Сколько кода должно быть покрыто тестами?
Non functional requirements \ Security requirements
Требования по безопасности. Если это HTML редактор, через которые можно изменять что-то на сайте, то это может быть нечто вроде: через HTML редактор не должно быть возможности поставить shell на сервер и тп
Appendix A: Glossary
Приложение. Иногда в SRS пытаются вставлять описание протоколов и тд и тп. Этого делать не нужно. Однако иногда нужно таки прояснить какую то концепцию. Для этого существует этот раздел. Вставляем ссылочки на такие пояснения. Такой себе словарик.
Appendix B: Analysis Models
Раздел определяет какие диаграммы нужно использовать при написании SRS. Например, DFD, какие то общие диаграммы взаимодействия и работы
Appendix C: Issues list
Данный раздел используется для очень формальных SRS. Описывает пункты TBD(To Be Done) — что в будущем надо еще сделать, но тут не описано.
Заключение
SRS не является обязательным для использования, однако может помочь в средних и больших проектах. Использование SRS показывает Ваш профессиональный уровень как разработчика.
Спецификации и их роль в разработке программ
Технология разработки программных продуктов
Составитель Румбешт В.В., кандидат технических наук, доц.
Рецензент Михилев В.М., кандидат технических наук, доц.
Т38 Технология разработки программных продуктов: Методические указания. – Белгород: Изд-во БИЭИ, 2005. – 42 с.
В методических указаниях изложены современные методы специфицирования программного обеспечения такие, как Р-технология
(ГОСТ 19.005–85) и метод структурного анализа. Содержатся задания к выполнению лабораторных работ, посвященных изучению указанных методов.
Предназначены для студентов специальности 22.03.
Ó Белгородский инженерно-экономический
институт (БИЭИ), 2005
ОГЛАВЛЕНИЕ
Спецификации и их роль в разработке программ
Спецификация программы – это описание задачи, которую решает программа. Слово «спецификация» буквально означает «описание» или «получение описания», а «специфицировать» значит «описывать».
В отличие от компьютерной программы спецификация обращена, прежде всего, к человеку и представляет собой описание в терминах, характерных для самой задачи, а не для ее реализации. Спецификация – это задание для программиста, написанное постановщиком задачи. Она служит основой дальнейшей детализации и разработки. С другой стороны, требования к программе, отраженные в техническом задании, также обращены к человеку. Однако спецификация более формально, чем требования, описывает решаемую задачу.
К основным свойствам спецификации можно отнести следующее.
1. Спецификация не должна содержать деталей реализации. В отличие от программы она «говорит», что надо сделать, а не как это делать.
2. Спецификация должна обладать формальностью (однозначностью прочтения, точностью), причем диапазон требований здесь очень широк: от полностью формализованного описания до слегка формализованного. Описание на «естественном языке» обычно считается неудовлетворительным, поскольку оно слишком неформально.
3. Спецификация должна быть понятной (ясной, читабельной). В этом заключается еще одно отличие от программы. В общем случае спецификация должна быть более понятным описанием задачи, чем программа, так как краткость не всегда содействует ясности и понятности.
4. Спецификация должна обладать полнотой описания задачи: ничто существенное не должно быть упущено.
Итак, спецификация – это достаточно точное и достаточно полное описание задачи, которое человеку, участвующему в решении, легче написать, понять и прочесть, чем программисту представить решение этой задачи на доступном ему языке программирования.
Дополненные и уточненные требования к программе – это уже спецификация, которая на пути к готовому программному продукту может претерпеть много изменений, оставаясь спецификацией до тех пор, пока не сможет быть выполнена на машине или пока это выполнение не станет достаточно эффективным.
В спецификации программы имеет смысл выделить по крайней мере две существенно разные части. Одна описывает объекты, действующие в задаче: разбиение задачи на подзадачи; входные и выходные данные, связи между ними, если речь идет о задаче преобразования данных или вычислении функции, процессы и действия, если речь идет о задаче управления или взаимодействия с внешней средой, реакции на исключительные ситуации и т.д. Эта часть называется функциональной спецификацией. Она описывает функцию программы, решающей задачу. Другая часть спецификации касается таких аспектов, как скорость работы программы или используемые ею ресурсы, характеристики аппаратуры, на которой она должна работать, специальные требования к надежности и безопасности и т.д. Эту часть называют эксплуатационной спецификацией.
Спецификациям уделяется все большее внимание, их разработка рассматривается как самостоятельная область технологии и методологии программирования, а сами они — как существенная часть программной документации.
В последнее время появилось большое количество технологий и методов построения функциональных спецификаций, а также языков спецификаций. Для этих языков характерно следующее.
1. Разбиение на уровни абстракций.
2. Ограниченное число элементов, приходящихся на уровень абстракции (не более 7).
3. Ограниченный контекст – включается лишь то, что входит в процесс, а все остальное из рассмотрения исключается.
4. В описание включаются как сами данные, так и действия над ними.
В данных методических указаниях рассмотрим две наиболее распространенные технологии специфицирования: Р-технологию и метод структурного анализа, языки которых можно отнести к так называемым графическим языкам. Эти средства представляют информацию в виде графов и диаграмм, а также содержат определенную методологию построения функциональных спецификаций.
2. Основные принципы Р-технологии
Р-технология была создана в Институте Кибернетики АН УССР. Для написания спецификаций в Р-технологии используется язык нагруженных по дугам ориентированных графов. Конкретная спецификация, созданная с помощью Р-технологии, представляет собой иерархию таких графов, называемых Р-схемами.
На самом деле Р-технология охватывает не только этап специфицирования программ, но и этапы проектирования, кодирования, отладки, и документирования в жизненном цикле программного обеспечения. Она предусматривает следующую цепочку работ по созданию программы:
* построение Р-схемы или иерархии Р-схем, реализующей поставленную задачу;
* генерацию исходного текста программы по заданной Р-схеме;
* компиляцию и компоновку загрузочного модуля программы;
* отладку и тестирование, полученной программы;
* генерацию Р-схемы по исходному тексту программы;
Язык Р-схем является удобной оболочкой, в которую может быть погружен любой язык программирования от ассемблера до языка высокого уровня, и в настоящее время является составной частью Единой системы программной документации (ГОСТ 19.005–85).
2.1. Графические структуры Р-схем
Р-схема — это управляющая структура программы в виде множества возможных путей ее выполнения, изображенных направленными дугами. Структура Р-схем изображается с помощью простых графических элементов таких, как вершины, соединительные дуги и вертикальные линии.
Для чего разрабатываются спецификации на программный продукт
Аналитик
Template tips
Включает ряд пользовательских сценариев (англ. use cases ), которые описывают все варианты взаимодействия между пользователями и программным обеспечением.
Пользовательские сценарии являются средством представления функциональных требований. В дополнение к пользовательским сценариям, спецификация также содержит нефункциональные требования, которые налагают ограничения на дизайн или реализацию (такие как требования производительности, стандарты качества, или проектные ограничения).
В стандарте IEEE 830 содержится рекомендации к структуре и методам описания программных требований — «Recommended Practice for Software Requirements Specifications».
Введение\ Цели
В данной секции описываем приложение или продукт, функционал которого будет описываться в SRS.
Введение\ Соглашение о терминах
Здесь мы описываем все непонятные технические слова или термины которые встречаются в SRS. Заметьте, что описание непонятного слова не может содержать другое непонятное слово. Старайтесь расписать как можно подробнее термин который Вы используете простым и понятным всем языком. Не экономьте на этой секции потому, что чем больше вы распишете непонятных вещей, тем проще будет потом проектировать.
Введение \ Ссылки на источники
В данной секции мы пишем ссылки на литературу в которой можно найти основания использованных технологий и фактов. Допустим можно вставлять RFC если вы пишете приложение работающее с TCP/IP, вставлять ссылки на документы на которые вы ссылаетесь и тд. Ссылки и их описание должны быть максимально полными, чтобы в случае чего (линк умер просто) можно было нагуглить этот материал.
Общее описание\ Функциональность продукта
В данном разделе мы описываем части функционала на высоком уровне. Более детально каждая часть функционала будет описана в своем разделе ниже. Тут желательно разместить DFD-диаграмму которая покажет общее взаимодействие системы.
Общее описание\ Среда функционирования продукта
Как понятно из названия раздела тут мы описываем окружение в котором будет работать продукт. ОС, версии компиляторов, базы данных, сервера, софт, железо и другие вещи которые необходимы для работы вашего продукта.
Общее описание\ Документация для пользователей
Описываем какая документация нужна для пользователей данного продукта. Возможно это книга по HTML если это HTML редактор.
Функциональность системы \ Функциональный блок X
Называем фичу проекту и даем ей уникальный идентификатор. Например, server.html.editor. Уникальный идентификатор дается для того, чтобы потом где то в тикетах ваших не писать — «а вот та хреновина, которая позволяет редактировать хтмл»
Функциональность системы \ Функциональный блок X\ Описание и приоритет
Описываем детально фичу продукта. Для чего она? Что должна делать? Какой у нее приоритет выполнения. Из этого раздела читающему срс человеку должно сразу стать понятно зачем этот функционал присутствует в системе.
Функциональность системы \ Функциональный блок X \ Прицинно-следственные связи, алгоритмы
Триггер запуска фичи. Когда она запускается и как себя ведет при запуске? Например, HTML редактор показывается при нажатии пользователя на ссылку меню Открыть HTML редактор
Функциональность системы \ Функциональный блок X \ Функциональные требования
Подробное и детальное описание фичи. Описываем все: как работает, как реагирует на ошибки, что должно проверять, как отображать данные, как и куда что сохраняет и тд
Требования к внешним интерфейсам
Описание того как система будет взаимодействовать с внешним миров. Если будет конечно. Какие API, как получить те или иные данные и тп. Подразделы служат для детализации требований. Какие софт интерфейсы, «железячные» интерфейсы, комуникационные интерфейсы и прочее.
Не функциональные требования
Не функциональные требования. Есть требования которые невозможно описать как какую то фичу, например, требования к безопасности.
Не функциональные требования \ Требования к производительности
Требования к производительности. Это не фича, однако налагает определенные ограничения. Допустим база данных проекта должна выдерживать 1000 запросов в секунду и тп. Эти требования приводят к колоссальной работе по оптимизации проекта.
Не функциональные требования \ Критерии качества программного обеспечения
Тут мы описываем требования к качеству кода. Какие тесты использовать? Какие метрики использовать для определения качества кода? Сколько кода должно быть покрыто тестами?
Не функциональные требования \ Требования к безопасности системы
Требования по безопасности. Если это HTML редактор, через которые можно изменять что-то на сайте, то это может быть нечто вроде: через HTML редактор не должно быть возможности поставить shell на сервер и тп
Приложение A: Глоссарий
Приложение. Иногда в SRS пытаются вставлять описание протоколов и тд и тп. Этого делать не нужно. Однако иногда нужно таки прояснить какую то концепцию. Для этого существует этот раздел. Вставляем ссылочки на такие пояснения. Такой себе словарик.
Приложение B: Модели процессов предметной области и другие диаграммы
Раздел определяет какие диаграммы нужно использовать при написании SRS. Например, DFD, какие то общие диаграммы взаимодействия и работы
Приложение C: Список ключевых задач
Данный раздел используется для очень формальных SRS. Описывает пункты TBD(To Be Done) — что в будущем надо еще сделать, но тут не описано.
Методические указания «Разработка спецификаций к Программному продукту»
Методические указания к проектированию спецификаций программного обеспечения
по УП ПМ.01 «Разработка программных модулей программного обеспечения для компьютерных систем»
специальности 09.02.03 «Программирование в компьютерных системах»
Назначение спецификации
Каждая организация, специализирующаяся на разработке ПО, должна принять один или несколько стандартных шаблонов спецификации требований к ПО для использования в проектах. Существуют различные шаблоны спецификаций. Если вы беретесь за проекты различных типов и размеров, от конструирования новой объемной системы до небольших улучшений уже работающих систем, позаботьтесь для проектов каждого крупного класса завести отдельный шаблон спецификации.
План разработки спецификации
Приведенный шаблон подходит для многих проектов. Состоит он из следующих разделов:
1.2 Соглашения, принятые в документах
1.3 Границы проекта
2.1 Общий взгляд на продукт
2.2 Классы и характеристики пользователей
2.3 Операционная среда
2.4 Ограничения дизайна и реализации
2.5 Предположения и зависимости
3.x Функция системы X
3.x.2 Функциональные требования
4. Требования к данным
4.1 Логическая модель данных
4.4 Получение, целостность, хранение и утилизация данных
5. Требования к внешним интерфейсам
5.1 Пользовательские интерфейсы
5.3 Интерфейсы оборудования
5.4 Коммуникационные интерфейсы
6. Атрибуты качества
6.1 Удобство использования
6.4 Техника безопасности
7. Требования по интернационализации и локализации
8. Остальные требования
Приложение A. Словарь терминов
Приложение Б. Модели анализа
Методические указания по заполнению спецификации
Иногда фрагмент информации логически подходит для нескольких разделов шаблона. Выберите один раздел и используйте именно его для информации такого типа в своем проекте. Не дублируйте информацию в нескольких разделах, даже если логически она ложится в эти разделы. Используйте перекрестные ссылки и гиперссылки, чтобы облегчить читателям поиск нужной информации.
При создании документов требований применяйте эффективные приемы и средства управления версиями, чтобы все читатели четко понимали, какую версию они читают в тот или иной момент времени. Ведите журнал изменений, в котором фиксируются суть изменений, автор, дата и причина.
Внимание! Вы можете внедрять материал с помощью ссылки в другие документы, а не дублировать его в спецификации требований к ПО. Для этого можно использовать гиперссылки в качестве ссылок для отслеживания связей, определенных в средстве управления требованиями. С гиперссылками связан тот риск, что они могут «ломаться» при изменении иерархии папок, где хранятся документы.
Описание разделов шаблона спецификации требований
Введение представляет собой обзор, помогающий читателям разобраться в структуре и принципе использования спецификации требований к ПО.
1.2 Соглашения, принятые в документах
1.3 Границы проекта
Кратко опишите ПО и его назначение. Покажите, как связан продукт с пользователями или корпоративными целями, а также с бизнес-целями и стратегиями. Если имеется отдельный документ о концепции и границах проекта, не повторяйте его содержимое, а просто сошлитесь на него. Если спецификацию требований к ПО предполагается разрабатывать постепенно, она должна содержать собственное положение о концепции и границах продукта в качестве подраздела долгосрочной стратегической концепции. Можно предоставить высокоуровневую сводку главной функциональности выпуска или функций, которые он должен выполнять.
2.1 Общий взгляд на продукт
Опишите контекст и происхождение продукта. Поясните, является он новым членом растущего семейства продуктов, новой версией существующей системы, заменой существующего приложения или совершенно новым продуктом. Если спецификация требований определяет компонент более крупной системы, укажите, как это ПО соотносится со всей системой и определите основные интерфейсы между ними. Неплохо также включить визуальные модели, такие как контекстную диаграмму или карту экосистемы, чтобы показать взаимосвязь продукта с другими системами.
2.2 Классы и характеристики пользователей
2.3 Операционная среда
2.4 Ограничения дизайна и реализации
Бывает, что нужно использовать вполне определенный язык программирования, определенную библиотеку, на разработку которой уже потрачено время, и т. п. Опишите все факторы, которые ограничат возможности, доступные разработчикам, и логически обоснуйте каждое положение. Требования, которые включают или написаны в форме идей по решению, а не потребностей накладывают ограничения на дизайн, часто неоправданные, поэтому за этим надо следить.
2.5 Предположения и зависимости
Приведенный здесь шаблон структурирован по функциям системы — это еще один способ систематизации функциональных требований. Другие методы классификации — по функциональным областям, рабочим потокам, вариантам использования, режимам работы, классам пользователей, стимулам и реакциям. Возможны также иерархические комбинации этих элементов, например варианты использования внутри классов пользователей. Не существует единственно правильного метода организации; выберите тот, при котором пользователям будет легче понять предполагаемые возможности продукта.
Опишем схему функций на примере.
3.x Функция системы X
Кратко опишите функцию системы и укажите ее приоритет : высокий, средний или низкий приоритетом. Приоритеты являются динамичной характеристикой, они могут изменяться в ходе проекта. Если вы используете средство управления требованиями, определите атрибут требований для обозначения приоритета.
3.x.2 Функциональные требования
4. Требования к данным
Ценность информационных систем заключается в том, что они предоставляют возможность манипулировать данными. Используйте этот раздел шаблона для описания различных аспектов данных, которые будет потреблять система в качестве входной информации, как-то обрабатывать и возвращать в виде выходной информации.
4.1 Логическая модель данных
Модель данных это визуальное представление объектов и наборов данных, которые будет обрабатывать система, а также отношений между ними. Существует много видов нотации для моделирования данных, в том числе диаграммы отношений «сущность–связь» и диаграммы классов UML. Можно включить модель данных для бизнес-операций, выполняемых системой или логическое представление данных, с которыми будет работать система. Это не то же самое, что модель данных реализации, которая реализуется в виде дизайна базы данных.
Словарь данных определяет состав структур данных, а также их значение, тип данных, длину, формат и разрешенные значения элементов данных, из которых состоят эти структуры. Серийные средства моделирования данных часто включают компонент-словарь данных. Во многих случаях словарь данных лучше хранить как отдельный артефакт, не внедряя его в спецификацию требований к ПО. Это повышает возможности повторного использования в других проектах.
4.4 Получение, целостность, хранение и утилизация данных
Если это важно, опишите, как получают и обслуживают данные. Например, при открытии канала номенклатуры данных может требоваться первым делом выполнить начальный дамп всей номенклатуры данных в принимающую систему, а после этого использовать каналы для передачи только изменений. Укажите все требования, относящиеся к защите целостности данных системы. Укажите все процедуры, которые могут потребоваться, например резервное копирование, создание контрольных точек, зеркальное отображение или проверка корректности данных. Укажите политики, которые должна применять система для хранения или утилизации данных, в том числе временных данных, метаданных, остаточных данных (таких как удаленные записи), данных в кеше, локальных копий, архивов и промежуточных архивов.
5. Требования к внешним интерфейсам
В этом разделе указывается информация, которая гарантирует, что система будет правильно взаимодействовать с пользователями и компонентам внешнего оборудования и ПО. Выработка согласия по внешнему и внутреннему интерфейсу системы признано оптимальным приемом в области разработки ПО (Brown, 1996). В сложной системе с множеством подкомпонентов следует использовать раздельные спецификации для интерфейсов или спецификацию системной архитектуры. В документацию по интерфейсу можно включить ссылки на материал из других документов. Например, ссылка может указать на руководство по работе с устройством, где перечислены коды ошибок, которые устройство может отправить программе.
Две команды разработчиков ПО объединились для создания флагманского продукта компании A. Datum Corporation. Команда, отвечающая за базу знаний, создала сложное ядро анализа на C++, а команда, отвечающая за приложения, реализовала пользовательский интерфейс на Java. Подсистемы взаимодействовали между собой посредством API. К сожалению, команда, отвечающая за базу знаний, периодически модифицировала API, в результате чего систему не удавалось собрать и запустить на выполнение должным образом. Команде, отвечающей за приложения, требовалось несколько часов, чтобы распознать все проблемы и определить основную причину — изменение API. Эти изменения не согласовывались, не доводились до сведения всех заинтересованных в проекте лиц и не были скоординированы с соответствующими модификациями в коде на Java. Изменение интерфейса обязательно требует уведомления об этом людей, группы или системы на другой стороне этого интерфейса. Интерфейс скрепляет компоненты вашей системы — включая пользователей, поэтому необходимо документировать детали интерфейса и синхронизировать модификации в процессе управления изменениями в проекте.
5.1 Пользовательские интерфейсы
• ссылки на стандарты графического интерфейса пользователей или стилевые рекомендации для семейства продуктов, которые необходимо соблюдать;
• стандарты шрифтов, значков, названий кнопок, изображений, цветовых схем, последовательностей полей вкладок, часто используемых элементов управления, графики фирменного стиля, уведомления о зарегистрированных товарных знаках и о конфиденциальности и т.п.;
• размер и конфигурация экрана или ограничения разрешения;
• стандартные кнопки, функции или ссылки перемещения, одинаковые для всех экранов, например кнопка справки;
• стандарты отображения и текста сообщений;
• стандарты проверки данных (такие как ограничения на вводимые значения и когда нужно проверять содержимое полей);
• стандарты конфигурации интерфейса для упрощения локализации ПО;
• специальные возможности для пользователей с проблемами со зрением, различением цвета и другими ограничениями.
Опишите связи продукта и других компонентов ПО (идентифицированные по имени и версии), в том числе другие приложения, базы данных, операционные системы, средства, библиотеки, веб-сайты и интегрированные серийные компоненты. Укажите назначение, форматы и содержимое сообщений, данных и контрольных значений, обмен которыми происходит между компонентами ПО. Опишите соответствия между входными и выходными данными между системами и все преобразования, которые должны происходить с данными при перемещении между системами. Опишите службы, необходимые внешним компонентам ПО, и природу взаимодействия между компонентами. Определите данные, которыми будут обмениваться и к которым будут иметь общий доступ компоненты ПО. Определите нефункциональные требования, влияющие на интерфейс, такие как уровни обслуживания для времени и частоты отклика или меры и ограничения безопасности. Часть этой информации может быть определена как требования к данным в разделе 4 или как требования к взаимодействию в разделе «6. Атрибуты качества».
5.3 Интерфейсы оборудования
Опишите характеристики каждого интерфейса между компонентами ПО и оборудования системы. В описание могут входить типы поддерживаемых устройств, взаимодействия данных и элементов управлений между ПО и оборудованием, а также протоколы взаимодействия, которые будут использоваться. Перечислите входные и выходные данные, их формат, разрешенные значения или их диапазоны, а также все временные характеристики, о которых должны знать разработчики. Если такой информации очень много, лучше создать отдельный документ спецификации интерфейса.
5.4 Коммуникационные интерфейсы
6. Атрибуты качества
6.1 Удобство использования
Требования к удобству использования подразумевают легкость изучения, простоту использования, предотвращение ошибок и восстановление, эффективности взаимодействия и специальные возможности. Указанные в этом разделе требования к удобству использования помогут дизайнеру интерфейсов создать максимально удобную для пользователя рабочую среду.
Укажите конкретные требования к производительности для различных системных операций. Если у различных функциональных требований или функций имеются разные требования к производительности, то следует указывать задачи, связанные с производительностью, там же, в разделе соответствующих функциональных требований, а не включать их все в этот раздел.
6.4 Техника безопасности
7. Требования по интернационализации и локализации
Требования по интернационализации и локализации обеспечивают возможность использовать продукт в других странах, региональных стандартах и географических районах, отличающихся от тех, в которых он был создан. Такие требования могут быть направлены на разрешение различий в валютах, форматировании дат, чисел, адресов и телефонных номеров, языках, в том числе различных вариантах одного языка (например, американского и британского вариантов английского), используемых символах и наборах символов, личных именах и фамилиях, часовых поясах, международных нормативных актах и законах, культурных и политических традициях, размере используемой бумаги, единицах веса и меры, электрическом напряжении и конфигурации электрических разъемов и во многом другом. Требования по интернационализации и локализации вполне могут повторно использоваться во многих проектах.
8. [Остальные требования]
Приложение A. Словарь терминов
Приложение Б. Модели анализа
В этом необязательном разделе описывается, а точнее напоминается, о таких моделях анализа, как диаграммы потоков данных, деревья функций, диаграммы переходов состояния и диаграммы «сущность-связь». Часто читателю удобнее, когда определенные модели внедрены в соответствующие разделы спецификации, а не собраны скопом в конце.
Методические указания по оформлению спецификации
Интервал между текстом предыдущего раздела (подраздела) и заголовком последующего должен быть не меньше 15 мм.
Абзацы в тексте начинаются отступом, равным 15 мм.
Разрешается использовать компьютерные возможности акцентирования внимания на определенных терминах, формулах, применяя шрифты разной гарнитуры или жирности.
Нумерация страниц начинается с титульного листа и заканчивается последним листом пояснительной записки.
Номер страницы проставляется в центре нижней части листа без точки.
На титульном листе номер страницы не указывается.
Заголовки глав, пунктов и подпунктов должны быть краткими, при этом заголовки должны точно отражать содержание соответствующего раздела.
Заголовки глав записывают в виде предложения с абзацного отступа, с прописной буквы, без точки в конце, не подчеркивая.
Заголовки пунктов и подпунктов записывают с абзацного отступа строчными буквами (кроме первой прописной).
Переносы слов в заголовках не допускаются. Точка в конце заголовка не ставится.
Наименования структурных элементов «СОДЕРЖАНИЕ», «ВВЕДЕНИЕ», «ЗАКЛЮЧЕНИЕ», «СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ» служат заголовками структурных элементов и печатаются симметрично тексту.
Каждую новую главу записки и каждый структурный элемент рекомендуется начинать с нового листа.
Титульный лист является первым листом пояснительной записки. Титульный лист выполняется на листе формата А4 по форме, приведенной в Приложении 1.
Слово «Содержание» записывают в виде заголовка (симметрично тексту) прописными буквами.
Содержание включает: введение;
номера и названия разделов, подразделов, пунктов и подпунктов строчными буквами кроме первой прописной; заключение;
список использованных источников; номера и полные названия всех приложений.
Для каждого названия указывается номер страницы, на которой оно находится. Название и номер страницы разделяются отточием. Номера страниц выровнены по правому краю.
Разделы нумеруются в пределах пояснительной записки порядковыми номерами арабскими цифрами.
Пункты нумеруются по порядку в пределах раздела. Например, 3.2 — пункт 2 раздела 3.
Подпункты нумеруются в пределах пункта, например, 3.2.1.
Введение, заключение и список использованных источников не нумеруются.
Внутри пунктов и подпунктов могут быть перечисления. Перед каждым перечислением следует ставить дефис или, при необходимости ссылки в тексте на одно из перечислений, строчную букву (за исключением ё, з, о, г, ь, й, ы, ъ), после которой ставится скобка.
Для дальнейшей детализации перечислений необходимо использовать арабские цифры, после которых ставится скобка, а запись производится с абзацного отступа.
Иллюстрации (графики, схемы, диаграммы) следует располагать непосредственно после текста, в котором они упоминаются впервые, или на следующей странице. На все иллюстрации должны быть даны ссылки.
Чертежи, графики, диаграммы, схемы должны соответствовать требованиям Единой системы конструкторской документации (ЕСКД).
Иллюстрации, за исключением иллюстрации приложений, нумеруются арабскими цифрами сквозной нумерацией. Допускается нумерация в пределах раздела (разбиение на пункты во внимание не принимается). Например, рисунок 3.1 — рисунок первый в третьем разделе. В общем случае рисунок может содержать:
поясняющие надписи, расположенные под рисунком (могут отсутствовать); номер рисунка и название, расположенные под пояснительными данными по центру следующим образом:
Если рисунок располагается на нескольких листах, то на каждом последующем листе указывается номер рисунка, за которым следует слово «Продолжение».
Например, Рисунок Продолжение. Точки после номера и названия рисунка не ставятся.
Иллюстрации приложений обозначают отдельной нумерацией арабскими цифрами с добавлением перед цифрой обозначения приложения. Например, Рисунок АЗ.
При ссылках на иллюстрации следует писать «. в соответствии с рисунком 2».
Таблицу следует располагать непосредственно после текста, в котором она упоминается впервые, или на следующей странице. На все таблицы должны быть ссылки. При ссылке следует писать слово «таблица» с указанием ее номера.
Название таблицы следует помещать над таблицей слева, без абзацного отступа в одну строку с ее номером через тире, например: Таблица 2.1- Перечень элементов. Точка после названия не ставится.
При переносе части таблицы на другой лист слово «Таблица», ее номер и название указывают один раз над первой частью таблицы, нижнюю горизонтальную черту, ограничивающую таблицу, не проводят. Над другими частями пишут слово «Продолжение» и указывают номер таблицы, например, «Продолжение таблицы 1». Точка после номера не ставится.
Заголовки граф таблицы начинают с прописной буквы, а подзаголовки со строчной, если они составляют одно предложение с заголовком.
В конце заголовков в подзаголовков знаки препинания не ставят.
Заголовки указывают в единственном числе.
Диагональное деление головки таблицы не допускается.
Графу «№ п/п» в таблицу не включают. Порядковые номера показателей могут быть указаны в заголовках строк перед соответствующим заголовком.
При переносе таблицы на следующую страницу и для облегчения ссылок в тексте записки допускается нумерация граф.
Единицы измерения физических величин указываются через запятую после заголовка строки или заголовка (подзаголовка) графы.
Повторяющийся в графе таблицы текст, состоящий из одного слова, допускается заметать кавычками.
Если повторяющийся текст состоит из нескольких слов, то при первом повторении его заметают словами «То же», а далее кавычками.
Цифровые и подобные им данные заменять кавычками нельзя.
Если какие-либо данные в таблице не приводят, то в соответствующей графе ставят прочерк.
Числовые значения величин в одной графе должны иметь, как правило, одинаковое количество десятичных знаков.
Таблицы, за исключением таблиц приложений, следует нумеровать арабскими цифрами сквозной нумерацией. Допускается нумерация в пределах раздела. В этом случае номер таблицы состоит из номера раздела и порядкового номера таблицы, разделенных точкой.
Таблицы каждого приложения обозначают отдельной нумерацией арабскими цифрами с добавлением перед цифрой обозначения приложения, например: «Таблица В.1».
Формула располагается в отдельной строке (строках) текста. Выше и ниже каждой формулы должно быть оставлено не менее одной свободной строки. Обозначения расшифровываются сразу после формулы в последующих строках текста в порядке появления обозначений в формуле. При этом пояснение для каждого обозначения начинается с новой строки, в первой строке перед обозначением пишется слово «где». Например:
Формулы, на которые есть ссылки в тексте, нумеруются арабскими цифрами сквозной нумерацией или в пределах раздела. Номер заключается в круглые скобки и ставится справа от формулы в последней (или единственной) строке, занимаемой формулой.
Формулы, помещаемые в приложениях, должны нумероваться отдельной нумерацией с добавлением обозначения приложения, например: (А. 1).
Ссылки в тексте на порядковые номера формул дают в скобках.
В соответствии с ГОСТ 7.32-2003 список составляется в порядке появления ссылок в пояснительной записке. В список включают все источники, на которые есть ссылки в пояснительной записке.
Пример сведений о периодическом издании: Колесов А. П., Павлова О. М. Заключительные советы тем, кто программирует на VB & VBA // КомпьютерПресс № 6 / 2002, с. 35-38.
При ссылке на статьи из периодических изданий указание страниц обязательно.
Вспомогательный материал, необходимый для полноты изложения результатов курсовой работы (иллюстрации, таблицы или текст вспомогательного характера) допускается оформлять в виде приложений. В тексте должны быть ссылки на все приложения. Приложения располагают в порядке появления ссылок на них.
Каждое приложение должно начинаться с нового листа с указанием наверху посередине страницы слова «ПРИЛОЖЕНИЕ» и его обозначения.
Приложения оформляют как продолжение пояснительной записки на последующих ее страницах. Для приложений можно использовать кегль 8-10.
Приложение должно иметь заголовок, который располагается симметрично относительно текста с прописной буквы отдельной строкой.
Приложения обозначают заглавными буквами русского алфавита, начиная с А, за исключением букв Ё, 3, И, О, Ч, Ь, Ы, Ъ. Если в документе одно приложение, оно обозначается «ПРИЛОЖЕНИЕ А»
Ниже заголовка располагается текст приложения.
Текст приложения может состоять из разделов, пунктов и подпунктов, которые нумеруются в пределах данного приложения.
Рисунки, таблицы и формулы, помещаемые в приложении нумеруют в пределах данного приложения, например: Рисунок Б.1 — рисунок 1 в приложении Б.
Приложения должны иметь общую с остальной частью документа сквозную нумерацию страниц. При необходимости приложение может иметь «СОДЕРЖАНИЕ».
В пояснительной записке можно использовать ссылки на любые рисунки, таблицы, формулы, приложения, литературные источники, которые приведены в записке.
Рисунки, таблицы, формулы располагаются сразу после появления первой ссылки на них, то есть на текущем или следующем листе записки.
Порядок номеров приложений и литературных ссылок должен соответствовать порядку появления ссылок на них.
При ссылке на литературный источник указывается его порядковый номер, заключенный в квадратные скобки. Например, [4] или [4, 5, 6].
При первой ссылке на рисунок пишется, например, рисунок 1.4 или (рисунок 1.4).
При повторной ссылке на рисунок пишется, например, см. рисунок 1.4 или (см. рисунок 1.4).
При первой ссылке на таблицу пишется, например, в таблице 2.3 или (таблица 2.3).
При повторной ссылке добавляется слово «см.», например, см. таблицу 2.4 или (см. таблицу 3.1).
При ссылке на приложение пишется полностью слово «приложение» и указывается его номер, например, «. в приложении А» или (приложение Б).
Если Вы считаете, что материал нарушает авторские права либо по каким-то другим причинам должен быть удален с сайта, Вы можете оставить жалобу на материал.