Базовая версия
2026-03-20T18:37:01+00:00
НИЯУ МИФИ Стандарт на разработку Требований к ПО Команда №3 Москва, 2025 Содержание 1 ВВЕДЕНИЕ2 1.1 Цель2 1.2 Область применения2 1.3 Ссылки2 1.4 Термины, определения и соглашения2 2 ОПИСАНИЕ ПРОЦЕССА4 2.1 Окружение процесса4 2.2 Критерии начала процесса5 2.3 Входные данные5 2.4 Выходные данные5 2.5 Структура процесса5 2.6 Критерии окончания процесса6 2.7 Роли и квалификация участников процесса6 3 ПРАВИЛА СОСТАВЛЕНИЯ СПЕЦИФИКАЦИЙ ТРЕБОВАНИЙ7 3.1 Содержание спецификации требований7 3.2 Свойства спецификации требований7 3.2.1 Корректность7 3.2.2 Однозначность7 3.2.3 Полнота7 3.2.4 Непротиворечивость8 3.2.5 Неизбыточность8 3.2.6 Неделимость8 3.2.7 Модифицируемость8 3.2.8 Проверяемость9 3.2.9 Трассируемость9 3.2.10 Независимость от реализации9 3.2.11 Использование комментариев9 4 Нотации, используемые при разработке требований к ПО10 4.1 Системные требования10 4.2 Требования, вытекающие из проектных решений системного уровня10 Список рисунков Рисунок 1. Окружение процесса разработки программных требований4 Список таблиц Таблица 1. Термины, определения и соглашения2 Таблица 2. Сокращения3 Таблица 3. Расшифровка сокращения <RS>10 ВВЕДЕНИЕ Цель Целью данного стандарта является определение нотаций, используемых при разработке требований к клиент-серверному веб-приложению, определение общих свойств, которыми должна обладать спецификация требований и требования в отдельности, объявление общего окружения процесса разработки требований и инструментов процесса разработки требований. Область применения Документ предназначен для использования в проектах, связанных с разработкой программных требований (требований высокого уровня) к ПО. Настоящий стандарт применим в проектах, не предполагающих прямого взаимодействия разработчиков СПТ с пользователями разрабатываемых систем. Предполагается, что вопросы, связанные с определением системных требований, а также валидации разрабатываемых СПТ находятся в компетенции заказчика и решаются им. Настоящий стандарт должен использоваться совместно с разработанными на его основе стандартами проектов. Ссылки IEEE Std 830-1998, IEEE Recommended Practice for Software Requirements Specifications. Guide to Software Engineering Body of Knowledge (SWEBOK). IEEE Computer Society, 2004. Термины, определения и соглашения Таблица 1. Термины, определения и соглашения Термин Определение, толкование Заказчик Организация, заинтересованная в разработке программного обеспечения. В данной версии стандарта предполагается, что заказчик не является пользователем. Пользователь Лицо или организация, которые непосредственно будут эксплуатировать разрабатываемую систему. Предполагается, что взаимодействие с пользователями находится в компетенции Заказчика. Программные требования Требования высокого уровня к программному обеспечению. Включают в себя: системные требования, отнесенные к программному обеспечению; требования, вытекающие из проектных решений системного уровня; требования, вытекающие из других источников (таких, как интерфейсные соглашения или технические нормы). Системные требования Требования, предъявляемые к системе, понимаемой как программное решение. Спецификация программных требований Совокупность требований, определяющих функции и свойства, которые должны быть реализованы в разрабатываемом программном обеспечении. Спецификация требований может быть организована как один или несколько логически связанных документов (файлов), либо как совокупность записей в специализированной базе данных, либо иным способом Таблица 2. Сокращения Термин Определение, толкование ПО Программное обеспечение РПТ Разработка программных требований СПТ Спецификация программных требований ОПИСАНИЕ ПРОЦЕССА Окружение процесса Процесс разработки программных требований является частью жизненного цикла ПО и взаимодействует со всеми остальными процессами, определенными в проекте. Окружение процесса упрощенно представлено на рисунке 1. В данном документе не показан процесс УК [4], с помощью которого осуществляется взаимодействие между всеми процессами жизненного цикла ПО. Рисунок 1. Окружение процесса разработки программных требований Процесс РПТ использует входные данные, поставляемые заказчиком (например, спецификации системных требований и архитектуры, спецификации внешних интерфейсов), регламентирующие документы (стандарты на разработку требований и т.п.) и данные, образующиеся на предприятии в ходе других процессов, связанных с процессом РПТ (например, результаты формальных инспекций). Результаты (выходы) процесса РПТ поступают на входы других процессов, выполняющихся на предприятии, а также предоставляются заказчику. Полный перечень данных, которыми обмениваются заказчик и разработчики СПТ, должен быть определен в стандартах проекта, однако заказчику должны предоставляться, как минимум, разрабатываемая СПТ и сообщения о проблемах, обнаруживаемых в ходе разработки СПТ. Верификация разработанной СПТ проводится с помощью процедуры формальной инспекции и планом верификации проекта. В случае обнаружения несоответствий процесс РПТ повторяется. В общем случае разрабатываемая СПТ может быть представлена в виде одного или нескольких компонентов (документов, файлов, множества записей в базе данных и т.п.), которые могут инспектироваться или совместно, или независимо друг от друга. В случае, когда отдельные компоненты разрабатываемой СПТ инспектируются независимо, стандарты проекта должны предусматривать дополнительную процедуру формальной инспекции для проверки всей спецификации требований как единого целого. Критерии начала процесса Критерии начала процесса разработки требований определяются в стандартах проекта. Как минимум, для начала процесса необходимо наличие хотя бы части входных данных. Входные данные Исходные материалыдляразработкипрограммныхтребованийобычнопредоставляются заказчиком и могут включать в себя: системные требования; данный стандарт; план разработки ПО. Также возможны ситуации, когда необходимо модифицировать ранее разработанную СПТ, например, заказчик может предоставить некоторую базовую версию СПТ и запросы на ее изменение для завершения разработки. Такие случаи предполагают, что заказчиком поставляются базовая версия СПТ запрос на изменения Кроме того, при повторении процесса дополнительным входом служат описания несоответствий в СПТ, выявленных в ходе формальных инспекций, проводимых в рамках процесса РПТ, в других процессах (например, при проектировании, кодировании или тестировании) заказчиком. Регламентирующая документация процесса включает в себя настоящий стандарт, стандарты проекта, отраслевые стандарты, а также, возможно, стандарты заказчика и(или) стандарты, используемые по указанию заказчика. Выходные данные Список выходных данных, места их хранения и дальнейшее предназначение определяются в стандартах проекта. Выходные данные обычно включают в себя: Спецификация программных требований Сообщения о проблемах в ходе разработки требований (список несоответствий во входных данных и т.д) (опционально) Структура процесса. Процесс РПТ включает в себя следующие виды деятельности [3]: выделение программных требований из системных требований анализ и систематизация выделенных требований. Производится с целью приведения требований в соответствие свойствам, описанным в данном стандарте. документирование требований. Эти виды деятельности, как правило, тесно связаны в процессе РПТ и не могут быть выделены в отдельные подпроцессы. Критерии окончания процесса. Процесс разработки требований носит итерационный характер. Каждая итерация заканчивается, когда разработчик требований решает, что разработанные им документы готовы к формальной инспекции, и регистрирует это решение в соответствии со стандартами проекта. Процесс повторяется до тех пор, пока в результате инспекции не будет установлено соответствие разработанных требований входным данным и все запросы на изменение будут выполнены. Роли и квалификация участников процесса. На роль разработчика требований назначаютсясотрудники, аттестованные процессом “Обеспечение людскими ресурсами” для выполнения этой роли и, по возможности, хорошо знающие предметную область. ПРАВИЛА СОСТАВЛЕНИЯ СПЕЦИФИКАЦИЙ ТРЕБОВАНИЙ В ходе разработки стандартов проекта должны быть определены форматы выходных документов процесса – СПТ и отчетов о дефектах. Форматы выходных документов процесса РПТ в настоящем стандарте не определяются и должны быть определены в соответствующих стандартах проекта. Формат СПТ должен быть согласован с заказчиком. Требования к формату СПТ могут определяться заказчиком. В тех случаях, когда заказчиком явно не определяются требования к формату СПТ, или же необходимо предложить формат СПТ для согласования с заказчиком, возможно использование одного из шаблонов, приведенных в [2]. Вне зависимости от используемых форматов СПТ, требования к содержанию спецификаций программных требований, создаваемых в ходе процесса РПТ, изложены в последующих подразделах. Содержание спецификации требований СПТ должна содержать программные требования, включающие определение предполагаемых функций ПО и его внешних интерфейсов и производные требования. Все системные требования, относящиеся к ПО, должны быть учтены в СПТ, то есть в СПТ должны быть включены одно или несколько программных требований, соответствующих каждому такому системному требованию. Каждое программное требование, соответствующее какому-либо элементу входных данных процесса, должно быть помечено ссылкой на этот элемент. Кроме того, в процессе РПТ возможно появление так называемых производных требований, которые нельзя прямо отнести к каким-либо входным данным. Такие требования должны передаваться заказчику для исследования на предмет их влияния на требования, относящиеся к безопасности. Свойства спецификации требований Перечисленные в последующих подразделах свойства спецификаций требований следует рассматривать как цели, к которым следует стремиться при написании спецификаций. Однако достичь всех этих целей одновременно не всегда бывает возможно и, кроме того, не всегда можно определить формальные критерии для оценки наличия или отсутствия у спецификации этих свойств. Оценка свойств спецификации требований производится экспертами в ходе ее верификации, реализуемой на предприятии в виде процедуры формальной инспекции [4]. Корректность СПТ должна соответствовать (не противоречить) входным данным (2.3) процесса РПТ. Однозначность Каждое входящее в СПТ требование должно иметь только одну интерпретацию. Полнота СПТ должна включать все требования, которые являются необходимыми с точки зрения реализации требуемых функциональности, производительности, ограничений реализации, свойств или внешних интерфейсов системы. Все системные требования, относящиеся к ПО, должны быть учтены в СПТ. СПТ должна определить все реальные ситуации, которые могут встретиться при функционировании системы, то есть СПТ должна включать определения реакций системы на все реально возможные классы ситуаций и определения соответствующих классов входных данных. Требования не должны включать описание нереальных ситуаций, однако необходимо специфицировать реакции системы как на допустимые, так и на недопустимые значения входных данных, которые могут появляться, например, вследствие ошибок (ПО или оборудования) при работе системы. СПТ должна включать определения всех используемых в ней терминов, аббревиатур и единиц измерения, а также ссылки на все используемые рисунки, таблицы и диаграммы (то есть все используемые в спецификации рисунки, таблицы и диаграммы должны иметь метки и на все эти метки в документе должны быть ссылки). Непротиворечивость Под непротиворечивостью понимается внутренняя непротиворечивость спецификации (если спецификация не согласовывается с каким-то документом более высокого уровня, таким как, например, спецификации системных требований, то она является некорректной, согласно 3.2.1). В СПТ не должно присутствовать ни одного подмножества отдельных требований, находящихся в конфликте друг с другом. Определить все возможные типы конфликтов, приводящих к противоречивости спецификаций, не представляется возможным. Например, возможны следующие типы таких конфликтов: конфликты между отдельными компонентами спецификации, то есть между входящими в нее функциональными, нефункциональными требованиями и ограничениями (3.1). конфликты между спецификациями характеристик объектов реального мира; терминологические конфликты. Неизбыточность СПТ не должна включать описаний нереальных ситуаций или ненужных свойств/функций системы. Каждое входящее в СПТ требование должно быть определено только однажды (в одном месте СПТ), то есть определения требований или их частей не должны повторяться Неделимость СПТ должна быть неделимой. Спецификация требований является неделимой, если каждое из входящих в нее требований является неделимым. Требование является неделимым, если оно не может быть разделено на две или более независимых составляющих и не смешано с другими и может быть выделено из спецификации. Если требование фактически содержит два или несколько независимых утверждений, то оно должно представляться в документе соответствующим числом неделимых требований. Например, утверждение «В огороде бузина, а в Киеве дядька» должно было бы быть представлено в спецификации в виде двух требований. Модифицируемость СПТ должна быть модифицируемой. Спецификация требований является модифицируемой, если ее структура и стиль таковы, что изменения в требованиях могут быть сделаны полностью и последовательно, с сохранением структуры и стиля документа. Модифицируемость спецификации предполагает следующее: спецификация имеет последовательную организацию с оглавлением, индексом и явно заданной системой перекрестных ссылок; спецификация не избыточна (3.2.5); спецификация неделима (3.2.6). Проверяемость СПТ должна быть проверяемой. Спецификация требований является проверяемой, если каждое определенное в ней требование является проверяемым. Требование является проверяемым тогда и только тогда, когда существует некоторая конечная процедура, с помощью которой человек или машина сможет проверить, что данное требование реализовано в ПО. Для того, чтобы требование было проверяемым, оно должно быть выражено в такой форме, чтобы для оценки его выполнения можно было бы применить четкий критерий (например, pass/fail), выводимый или непосредственно из требования, или из соответствующей ссылочной информации. Трассируемость Каждое требование в СПТ должно быть уникально идентифицирована для обеспечения возможности прослеживаемости между СПТ и документами, созданными на ее основе. Идентификация требований не должна меняться как в ходе разработки СПТ, так и при последующих ее модификациях. Каждое требование в СПТ, зависящее от документов предшествующих стадий разработки, должно быть снабжено ссылками на источники этого требования в исходных документах. Независимость от реализации СПТ должна, в общем случае, описывать ЧТО, а не КАК должна делать система. СПТ не должна содержать деталей реализации (кроме явно определенных и обоснованных ограничений), данных о процессе разработки проекта или сведений о тестировании. Использование комментариев В тех случаях, когда это необходимо для обеспечения понятности спецификации, в нее должны включаться комментарии (например, в виде пояснительного текста, рисунков, диаграмм и т.п.). Во всех случаях, когда в текст СПТ включаются комментарии, они должны быть явно отделяемы от собственно требований. Комментарии не должны подменять собой определения требований, то есть при удалении комментариев из СПТ не должны меняться ее свойства, определенные в 3.2.1-3.2.10. Нотации, используемые при разработке требований к ПО Требования, вытекающие из проектных решений системного уровня Для обеспечения трассируемости требований внутри проекта используется система уникальных номеров, которые присваиваются каждому требованию с целью классификации их относительно системных требований и элементов архитектуры разрабатываемого ПО. Трассировка требований осуществляется с помощью создания ссылок на системные требования и отображение их в отдельном столбце таблицы, если требование является программным. В случае если требование оказалось производным, вместо ссылок пишется обоснование для него в том же столбце. Присвоенный требованию номер отражает информацию, необходимую для соотнесения его с более общими требованиями и затрагиваемыми ими составными частями проекта. Шаблоны идентификаторов требований определяется следующим образом: Общий вид идентификатора: REQ-<Тип требования>-<№ раздела >-<№ требования в разделе> <Тип требования> - SYS(system) - системное, DER(derivative) - производное, SW(software) - программное <№ раздела> - номер тематического раздела требований <№ требования в разделе> - порядковый номер внутри раздела