Требования к техническому обеспечению программы

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

Требование техники

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

Целью проектирования требований является разработка и сопровождение сложного и описательного документа «Спецификация системных требований».

Требование инженерного процесса

Это четырехэтапный процесс, который включает в себя:

• Технико-экономическое обоснование
• Сбор требований
• Спецификация требований к программному обеспечению
• Проверка требований к программному обеспечению

Давайте посмотрим на процесс вкратце –

Технико-экономическое обоснование

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

Качества хороших требований к разработке программного обеспечения

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

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

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

Сбор требований

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

Спецификация требований к программному обеспечению

SRS – это документ, созданный системным аналитиком после сбора требований от различных заинтересованных сторон.

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

Требования, полученные от клиента, написаны на естественном языке. Системный аналитик обязан документировать требования на техническом языке, чтобы они могли быть поняты и полезны для команды разработчиков программного обеспечения.

2. Виды требований к программному обеспечению. Часть 1. (Курс бизнес-аналитик с нуля)

SRS должен придумать следующие функции:

• Требования пользователя выражены на естественном языке.
• Технические требования выражены на структурированном языке, который используется внутри организации.
• Описание дизайна должно быть написано в псевдокоде.
• Формат форм и печать графического интерфейса.
• Условные и математические обозначения для DFD и т. Д.

Проверка требований к программному обеспечению

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

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

Процесс выявления требований

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

• Сбор требований – разработчики обсуждают с клиентом и конечными пользователями и знают их ожидания от программного обеспечения.
• Организация требований – Разработчики расставляют приоритеты и распределяют требования в порядке важности, срочности и удобства.
• Переговоры и обсуждение – если требования неоднозначны или если есть какие-то противоречия в требованиях различных заинтересованных сторон, если они есть, то это обсуждается и обсуждается с заинтересованными сторонами. Требования могут быть затем расставлены по приоритетам и разумно скомпрометированы. Требования исходят от различных заинтересованных сторон. Чтобы устранить двусмысленность и конфликты, они обсуждаются для ясности и правильности. Нереальные требования разумно скомпрометированы.
• Документация. Все формальные и неформальные, функциональные и нефункциональные требования документируются и предоставляются для последующей обработки.

Переговоры и обсуждение – если требования неоднозначны или если есть какие-то противоречия в требованиях различных заинтересованных сторон, если они есть, то это обсуждается и обсуждается с заинтересованными сторонами. Требования могут быть затем расставлены по приоритетам и разумно скомпрометированы.

Требования исходят от различных заинтересованных сторон. Чтобы устранить двусмысленность и конфликты, они обсуждаются для ясности и правильности. Нереальные требования разумно скомпрометированы.

Методы выявления требований

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

Существуют различные способы определения требований

Интервью

Интервью являются сильной средой для сбора требований. Организация может проводить несколько типов интервью, таких как:

• Структурированные (закрытые) собеседования, в которых каждая информация, подлежащая сбору, определяется заранее, они твердо следуют шаблону и предмету обсуждения.
• Неструктурированные (открытые) интервью, где информация для сбора не определена заранее, более гибкая и менее предвзятая.
• Устные интервью
• Письменные интервью
• Индивидуальные интервью, которые проводятся между двумя людьми за столом.
• Групповые интервью, которые проводятся между группами участников. Они помогают выявить любые недостающие требования, так как вовлечены многочисленные люди.

Обзоры

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

Анкетирование

Документ с предварительно определенным набором объективных вопросов и соответствующими вариантами передается всем заинтересованным сторонам для ответа, которые собираются и компилируются.

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

Анализ задач

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

Анализ предметной области

Каждое программное обеспечение попадает в какую-то доменную категорию. Опытные люди в этой области могут оказать большую помощь в анализе общих и конкретных требований.

мозговая атака

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

макетирования

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

наблюдение

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

Требования к программному обеспечению Характеристики

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

Полные спецификации требований к программному обеспечению должны быть:

• Очистить
• Правильный
• последовательный
• Последовательный
• понятный
• модифицируемый
• проверяемый
• Приоритетное
• недвусмысленный
• прослеживаемый
• Достоверный источник

Требования к программному обеспечению

Техническая документация

разработка техдокументации по ГОСТ без бумаги и расстояний

(4.3.5) Требования к техническому обеспечению

Требования к техническому обеспечению — пункт технического задания на автоматизированную систему, разрабатываемого согласно ГОСТ 34.602. Как элемент иерархической структуры или «дерева» техзадания может быть представлен так: Требования к системе (разд. 4) ⇨ Требования к видам обеспечения (подр. 4.3) ⇨ Требования к техническому обеспечению (п. 4.3.5).

Чем же заполнять данный пункт? Редакция от 02.04.2021.

Создан 03.05.2018 14:19:36

Термины и определения

Техническое обеспечение автоматизированной системы — Совокупность всех технических средств, используемых при функционировании AC [из 2.5 ГОСТ 34.003-90], геоинформационной системы — Комплекс технических средств, используемых для реализации функциональных возможностей геоинформационных систем, включая устройства ввода, обработки, хранения и передачи данных [из 14 ГОСТ Р 52438-2005].

Комплекс технических средств АСУ должен быть достаточным для выполнения всех автоматизированных функций АСУ [из 1.4.1 ГОСТ 24.104-85].

В качестве основных технических средств АСУ ТП должны быть использованы изделия Государственной системы промышленных приборов и средств автоматизации (ГСП), другие изделия, удовлетворяющие требованиям стандартов ЕССП, и средства вычислительной техники, соответствующие ГОСТ 21552-84 [из 9 прил. 1 ГОСТ 24.104-85].

В комплексе технических средств АСУ должны в основном использоваться технические средства серийного производства. При необходимости допускается применение технических средств единичного производства [из 1.4.2 ГОСТ 24.104-85].

В АСУ должны быть использованы средства вычислительной техники, удовлетворяющие общим техническим требованиям по ГОСТ 21552-84 [из 1.4.10 ГОСТ 24.104-85].

При использовании в проекте технических средств, для заказа которых требуется заполнение опросных листов, приложение последних к проекту обязательно [из 4.17.2 РД 50-34.698-90].

При использовании в проекте технических средств, имеющих ограничения в применении в соответствии с перечнями, утвержденными в установленном порядке, необходимо приложение к проекту копий документов о согласовании поставки этих средств [из 4.17.3 РД 50-34.698-90].

В АСУ для связи между устройствами комплекса технических средств должны быть применены:

• входные и выходныесигналы:

• электрические — тока и напряжения по ГОСТ 26.011-80, с дискретным изменением параметров по ГОСТ 26.013-81, кодированные по ГОСТ 26.014-81;
• гидравлические по ГОСТ 26.012-94;
• пневматические по ГОСТ 26.015-81;
• наборы символов алфавитно-цифровые по ГОСТ 27465-87;
• коды 8-битные по ГОСТ 19768-93.

[из 1.6.5 ГОСТ 24.104-85].

Технические средства АСУ, используемые при взаимодействии АСУ с другими системами, должны быть совместимы по интерфейсам с соответствующими техническими средствами этих систем и используемых систем связи [из 1.4.6 ГОСТ 24.104-85].

В АСУ должны быть использованы технические средства со сроком службы не менее десяти лет. Применение технических средств с меньшим сроком службы допускается только в обоснованных случаях и по согласованию с заказчиком АСУ [из 1.4.7 ГОСТ 24.104-85].

Все внешние элементы технических средств АСУ, находящиеся под напряжением, должны иметь защиту от случайного прикосновения, а сами технические средства иметь зануление или защитное заземление в соответствии с ГОСТ 12.1.030-81 и «Правилами устройства электроустановок» [из 2.4 ГОСТ 24.104-85].

Технические средства АСУ, размещаемые на взрыво- и пожароопасных установках, должны отвечать требованиям «Правил устройства электроустановок» [из 2.5 ГОСТ 24.104-85].

Технические средства АСУ должны быть установлены так, чтобы обеспечивались их безопасная эксплуатация и техническое обслуживание [из 2.6 ГОСТ 24.104-85].

Эргономика и техническая эстетика

Размещение технических средств, используемых персоналом АСУ при выполнении автоматизированных функций, должно соответствовать требованиям эргономики: для производственного оборудования по ГОСТ 12.2.049-80, для средств представления зрительной информации по ГОСТ 21829-76, в том числе для табло коллективного пользования из цифровых знакосинтезирующих электролюминесцентных индикаторов по ГОСТ 29.05.002-82 [из 1.4.5 ГОСТ 24.104-85].

Технические средства АСУ должны быть размещены с соблюдением требований, содержащихся в технической, в том числе эксплуатационной, документации на них, и так, чтобы было удобно использовать их при функционировании АСУ и выполнять техническое обслуживание [из 1.4.4 ГОСТ 24.104-85].

Технические средства АСУ допускается использовать только в условиях, определенных в эксплуатационной документации на них. В случаях, когда необходимо их использование в среде, параметры которой превышают допустимые значения, установленные для этих технических средств, должны быть предусмотрены меры защиты отдельных технических средств АСУ от влияния внешних воздействующих факторов [из 1.4.9 ГОСТ 24.104-85].

Технические средства АСУ ТП, размещаемые на технологическом оборудовании, должны соответствовать требованиям, предъявляемым к ним условиям эксплуатации [из 10 прил. 1 ГОСТ 24.104-85].

Техническое обслуживание и ремонт

Любое из технических средств АСУ должно допускать замену его средством аналогичного функционального назначения без каких-либо конструктивных изменений или регулировки в остальных технических средствах АСУ (кроме случаев, специально оговоренных в технической документации на АСУ) [из 1.4.8 ГОСТ 24.104-85]

Устойчивость к ВВФ

В АСУ должны быть использованы технические средства, соответствующие:

• по устойчивости к внешним воздействующим факторам — ГОСТ Р 52931-2008 для промышленных приборов и средств автоматизации ГСП, ГОСТ 14254-96 для оболочекизделий электротехники, ГОСТ 17516-72 для изделий электротехники в части воздействия механических факторов внешней среды, ГОСТ 21552-84 для средств вычислительной техники;
• по параметрам питания — ГОСТ 12997-84 для промышленных приборов и средств автоматизации ГСП, ГОСТ 21552-84 для средств вычислительной техники;
• по категории исполнения — ГОСТ 12997-84 для промышленных приборов и средств автоматизации ГСП, ГОСТ 21552-84 для средств вычислительной техники.

[из 1.4.11 ГОСТ 24.104-85].

Защита технических средств АСУ от воздействия внешних электрических и магнитных полей, а также помех по цепям питания должна быть достаточной для эффективного выполнения техническими средствами АСУ своего назначения при функционировании АСУ [из 1.4.12 ГОСТ 24.104-85].

В АСУ в соответствии с требованиями, предусмотренными «Общесоюзными нормами допускаемых индустриальных помех» 1-72 — 9-72 и ГОСТ Р 51318.11-2006, должны быть предусмотрены меры по защите внешней среды от индустриальных радиопомех, излучаемых техническими средствами АСУ при работе, а также в момент включения и выключения [из 1.4.13 ГОСТ 24.104-85].

Стандартизация и унификация

Тиражируемые АСУ и их части должны строиться на базе унифицированных технических средств [из 1.4.3 ГОСТ 24.104-85]

1. к видам технических средств, в том числе к видам комплексов технических средств, программно-технических комплексов и других комплектующих изделий, допустимых к использованию в системе;
2. к функциональным, конструктивным и эксплуатационнымхарактеристикам средств технического обеспечения системы.

[из 2.6.3.5 ГОСТ 34.602-89].

Для «обычного» ТЗ всего перечисленного достаточно, при автоматизированной разработке все придется переформулировать в виде списка (перечня).

• Описание комплекса технических средств по РД 50-34.698-90;
• Схема структурная комплекса технических средств по РД 50-34.698-90;
• Чертеж установки технических средств по РД 50-34.698-90;
• Инструкция по эксплуатации КТС по РД 50-34-698-90;
• и ряд других.

• Этап 5.1 «Разработка проектных решений по системе и ее частям» по ГОСТ 34.601-90;
• Этап 7.3 «Комплектация АС поставляемыми изделиями (программными и техническими средствами, программно-техническими комплексами, информационными изделиями)» по ГОСТ 34.601-90.

Источник: tdocs.su

Лекция 12 Разработка технического задания

Программный документ «Техническое задание» разрабатывается в соответствии с ГОСТ 19.201 — 78. Техническое задание содержит совокупность требований к программному средству и может использоваться как критерий проверки и приемки разработанной программы, поэтому достаточно полно составленное (с учетом возможности внесения дополнительных разделов) и принятое заказчиком и разработчиком техническое задание является одним из основополагающих документов проекта. Умение грамотно создавать техническое задание на разработку программного продукта определяет профессиональный уровень программиста и избавляет его от претензий со стороны заказчика.

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

Разработка технического задания выполняется в такой последовательности:

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

2) определяют перечень результатов, их характеристики и способы их представления,

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

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

Основные факторы, определяющие характеристики разрабатываемого программного обеспечения:

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

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

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

В соответствии с ГОСТ 19.201 — 78 программный документ «Техническое задание» содержит следующие разделы.

1. Основание для разработки.

2. Назначение разработки.

3. Требования к программе или программному изделию.

4. Требования к программной документации.

5. Технико-экономическое обоснование.

6. Стадии и этапы разработки.

7. Порядок контроля и приемки.

Во введении указываются цель разработки программного продукта, краткая характеристика области применения и описание объекта, в котором он используется, т.е. описание предметной области.

1. В разделе «Основание для разработки» должны быть указаны:

• документы, на основании которых ведется разработка;

• организация, утвердившая этот документ, и дата его утверждения;

• наименование и (или) условное обозначение темы разработки.

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

3. В раздел «Требования к программе или программному изделию» входят следующие подразделы:

• требования к функциональным характеристикам;

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

• требования к составу и параметрам технических средств;

• требования к информационной и программной совместимости;

• требования к маркировке и упаковке;

• требования к хранению и транспортированию;

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

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

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

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

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

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

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

Требования к составу и параметрам технических средств включают указания на состав технических средств и их основные характеристики, а именно: минимальные системные требования, необходимые для работы программы; указываются мощность процессора (Гц), на базе которого должен работать ПК, объем оперативной памяти (Мб), необходимый объем свободного дискового пространства, разрешение монитора, наличие устройства чтения компакт-дисков и т. п., а также возможность переноса программы с одной аппаратной платформы на другую.

Требования к информационной и программной совместимости содержат требования к информационным структурам, языкам программирования и программным средствам, используемым программой, а именно:

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

4. «Требования к программной документации». Основными документами, регламентирующими разработку будущих программ, должны быть документы Единой системы программной документации: руководство пользователя, руководство администратора, описание применения.

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

5. В разделе «Технико-экономическое обоснование» представлены ориентировочная экономическая эффективность разрабатываемого программного продукта, экономические преимущества разработки по сравнению с имеющимися на предприятии образцами или аналогами (или в сравнении с ручными операциями).

6. Стадии и этапы разработки описаны в учебном пособии А.В.Рудакова «Технология разработки программных продуктов».

7. «Порядок контроля и приемки» предполагает указание на виды испытаний и общие требования к приему работы.

В программный документ «Техническое задание» допускается включать приложения, где при необходимости приводят:

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

• перечень научно-исследовательских и других работ, обосновывающих разработку;

• схемы алгоритмов, таблицы, описания, обоснования, расчеты и т,д.;

• другие источники разработки.

Источник: karpusheva.ru