Программное обеспечение АС_УДР должно быть достаточным для выполнения всех реализуемых функций системы, а также иметь средства организации всех требуемых процессов обработки данных, позволяющих своевременно выполнять все функции во всех режимах функционирования системы.
Системное программное обеспечение должно реализовывать программы задач (комплексов задач управления). Для нормального функционирования системы необходимо наличие следующего набора программных средств:
— операционная система Windows 98, Me, 2000, NT, XP.
— Microsoft Office Access (не ниже версии Microsoft Office 2000)
4.3.5 Требования к техническому обеспечению
При выборе технических средств, применяемых для функционирования системы АС, должны учитываться следующие требования:
— выбор технических средств должен обеспечивать рациональное соотношение между затратами на создание системы и достигаемым эффектом;
— технические параметры системы управления не должны налагать ограничения на регламент технологического процесса функционирования
2. Виды требований к программному обеспечению. Часть 1. (Курс бизнес-аналитик с нуля)
Для реализации вышеуказанных требований необходимо следующий состав технических средств и программного обеспечения:
— Микропроцессор Intel Pentium 3 с тактовой частотой 733 МГц;
— Оперативная память объемом не менее 64МБ;
— Накопитель на жестком магнитном диске со свободным объемом не менее 500 МБ;
— Дисплей с адаптером VGA или SVGA, поддерживающий видеорежим 800*600 (True color 24 бит);
— SVGA video card PCI объемом не менее 32 МБ;
— Windows 98, Me, 2000, NT, XP.
Эксплуатация комплекса программных средств системы должна проводиться согласно соответствующим требованиям.
4.3.6 Требования к методическому обеспечению
Методическое обеспечение АС_УДР должно содержать нормативно-техническую документацию: перечень стандартов и нормативов, применяемых при функционировании системы, руководство пользователя и справочно-правовую информацию.
Стадии и этапы работ по созданию АС_УДР; основные результаты выполнения работ по каждой стадии должны соответствовать данным, указанным в таблице 7.
2.1 Изучение объекта
2.2 Проведение необходимых научно-исследовательских работ
2.3 Разработка вариантов концепции АС и выбор варианта концепции АС, удовлетворявшего требованиям пользователя
2.4 Оформление отчета о выполненной работе
4.1 Формализация выходной и входной информации
4.2 Схема функциональной структуры АС и её описание
4.3 Виды обеспечения АС
4.4 Тестовый пример
5.1 Рабочая версия АС
5.2 Руководство пользователя АС
6 Порядок контроля и приемки системы
Система является пригодной для использования, если соответствует всем пунктам данного ТЗ. Контроль выполнения всех функций системы осуществляется на тестовом примере.
Приемка программы осуществляется заказчиком в течение 2-х недель. Производится тестирование программы на контрольном примере и собственных тестовых примерах заказчика.
Как писать требования так, чтобы команда хотела их читать / Александр Войтехович / ISsoft
При выявлении ошибок в функционировании и несоответствий техническому заданию разработчик в течение двух недель исправляет обнаруженные недостатки. После этого производится повторная приемка.
7 Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие
Подготовка объекта АС к вводу в действие предполагает выполнение видов работ:
— подготовка (обучение) персонала;
— укомплектование АС поставляемыми изделиями (программными и техническими средствами, программно-техническими комплексами, информационными изделиями);
— закупка необходимых технических устройств;
— проведение предварительных испытаний;
— проведение опытной эксплуатации;
— проведение приемочных испытаний.
8 Требования к документированию
АС_УДР должна комплектоваться следующими документами:
— инструкция по формированию и ведению базы данных (набора данных);
— общее описание системы;
— программа и методика испытаний (компонентов, комплексов средств автоматизации, подсистем, систем);
В учебных целях будет разрабатываться документ руководство пользователя.
— ГОСТ 34.602-89 Информационная технология Комплекс стандартов на автоматизированные системы. Техническое задание на создание АС.
— Правовая информационная система Гарант
— Правовая информационная система Консультант +
— Кондраков Н.К. Бухгалтерский учет. — М.: ИНФРА-М, 2003, 382 с.
— Культин Н.Б. Основы программирования в Delphi 7. – СПб.: БХВ- Петербург, 2003. – 608 с.: ил.
— Кудряшова Э.Е. Словарь терминов, использующихся при проектировании информационных систем в экономике. – Волгоград: ВФ ОУ ВПО ЦС РФ «МУПК», 2005. – 31 с.
Рис. Схема функциональной структуры АС_УДР
АС_УДР предназначена для хранения и обработки данных по дополнительным расходам, связанными с поступлением материалов, бухгалтером.
Целью создания АС_УДР, является автоматизация учета дополнительных расходов, связанных с поступлением материалов.
АС_УДР позволяет изменять, сохранять данные, а также выводить результаты на печать.
Для работы с АС_УДР не требуется специальная подготовка, достаточно знания СУБД MS Access и знания предметной области.
1 НАЗНАЧЕНИЕ И УСЛОВИЯ ПРИМЕНЕНИЯ
Разработанная АС_УДР позволяет автоматизировать процесс учета дополнительных расходов(различных сторонних организаций), связанных с поступлением материалов.
2 ПОДГОТОВКА К РАБОТЕ
Необходимо изучить предметную область учета дополнительных расходов (различных сторонних организаций), связанных с поступлением материалов.
Запуск АС_УДР лучше производить с рабочего стола, для этого необходимо создать ярлык программы (вызвать контекстное меню правым нажатием мыши – выбрать Создать – Ярлык – обзор, где указывается путь к программе). Запуск АС_УДР осуществляется двойным щелчком мыши.
3 ОПИСАНИЕ ОПЕРАЦИЙ
После запуска АС_УДР автоматически появляется заставка, которая представлена на рисунке Б.1.
Рисунок Б.1 — Заставка
После автоматического закрытия заставки появляется главная форма. На главной форме расположены следующие кнопки: «Справочники», «Формирование счет-фактуры», «Отчеты» и «Выход». Главная форма представлена на рисунке Б.2.
Рисунок Б.2 – Главная форма
При нажатии кнопки «Справочники» открывается форма «Справочники», которая представлена на рисунке Б.3, где заполняется первичная входная информация.
Рисунок Б.3 – Справочники.
Например, если пользователь решил ввести новый товар, то необходимо открыть форму «Товар», нажав кнопку «Товары», и ввести необходимые данные. Форма «Товар» представлена на рисунке Б.4.
Рисунок Б.4 – Товар
При нажатии кнопки «Формирование счет-фактуры» открывается форма «Счет-фактура», которая представлена на рисунке Б.5. Чтобы сформировать новую счет-фактуру, необходимо ввести следующие реквизиты: получатель, продавец, наименование товара и его характеристики. Затем рассчитать сумму, нажав кнопку «Обновление», и провести документ.
Рисунок Б.5 – Счет-фактура
При нажатии кнопки «Отчеты» открывается форма «Отчеты», которая представлена на рисунке Б.6 и служит для просмотра (печати) отчетной информации.
Рисунок Б.6 – Отчеты
Например, если пользователь решил просмотреть отчет о контрагентах, то необходимо нажать кнопку «Контрагенты». Отчет о контрагентах представлен на рисунке Б.7.
Рисунок Б.7 – Контрагенты
4 АВАРИЙНЫЕ СИТУАЦИИ
В случае отказа оборудования (сбой электропитания, выход из строя) АС_УДР должна быть перезапущена (в случае необходимости – после перезапуска ОС, замены оборудования).
Необходимо обеспечить следующие компоненты надежности проектируемой системы:
— уровень надежности программного обеспечения – обеспечивается разработчиком;
— уровень надежности обслуживающего персонала – обеспечивается заказчиком;
— режимы и параметры технической эксплуатации АС_УДР обеспечиваются заказчиком;
— поддержание заказчиком в постоянной исправности устройств контроля и измерительных комплексов, позволяющих достоверно и оперативно определить место и причину повреждения.
5 РЕКОМЕНДАЦИИ ПО ОСВОЕНИЮ
Перед началом работы пользователю следует изучить предметную область и методику работы с программой.
1. ГОСТ 19.505-79 Руководство оператора (пользователя).
2. Кузнецов В.В. Базы данных: Практикум. Часть 2.- М.: Московский университет потребительской кооперации, 2003г. -56 с.
3. Кузнецов В.В. Проектирование баз данных: Учебное пособие. Часть 1. М.: Издательско-книготорговый центр «Маркетинг», МУПК, 2001.–58с.
Информация о работе «АС учета дополнительных расходов, связанных с поступлением материалов»
Раздел: Информатика, программирование
Количество знаков с пробелами: 37191
Количество таблиц: 8
Количество изображений: 13
Источник: kazedu.com
Системные требования к программе как составить
Требования к программному обеспечению
Программное обеспечение должно отличаться простотой использования. Дружественность пользовательского интерфейса определяет такие особенности программы, как удобство работы с меню и экранными формами, их оснащенность системой помощи, подсказками, стандартность и привычность использования клавиатуры и терминологических понятий.
Полнота и уровень автоматизации функций в программном обеспечении означает, что отдельные расчетные функции должны быть реализованы практически в любом пакете. Высокий уровень автоматизации расчетов предполагает перерасчет за любой предшествующий период времени с учетом действовавших на тот момент показателей.
Одним из требований программного обеспечения является настраиваемость пакета, что означает наличие средств настройки на новые показатели. При этом у бухгалтера снимаются проблемы появления новых, ранее не предусмотренных показателей; можно вводить и настраивать новые виды показателей без изменения программного обеспечения.
Программное обеспечение должно быть гибким, открытым и системным. Это означает возможность добавлять новые данные без изменения в структуре и предполагает ведение бухгалтерского учета на всех его стадиях.
Программное обеспечение должно быть универсальным и надежным. Универсальность системы делает возможным учет особенностей бухгалтерского учета на предприятиях различных отраслей хозяйства. Надежность системы характеризует ее устойчивость к неправильным командам пользователя, отказам технических средств.
Каждое из требований нельзя рассматривать отдельно от других, они взаимозависимы.
Требования к программному обеспечению.
Программное обеспечение — совокупность всех программных средств не входящих в состав Системы, но используемых при отладке, функционировании и проверке работоспособности Системы.
Программное обеспечение включает в себя общее программное обеспечение (ОПО Системы) и специальное программное обеспечение (СПО Системы).
6.4.7 Требования к общесистемному программному обеспечению
Общесистемное программное обеспечение — совокупность программных средств общего назначения, предназначенных для организации вычислительного процесса и решения часто встречающихся задач обработки информации.
В состав общесистемного ПО должны входить:
— операционная система сервера;
— операционные системы рабочих станций администраторов и пользователей Системы (Windows XP, Vista);
— СКБД (MS SQL 2005).
Общесистемное клиентское программное обеспечение рабочих станций, необходимое для работы прикладного программного обеспечения, уточняется на этапе технического (техно-рабочего) проектирования, оформляется в виде отдельного документа и утверждается Заказчиком.
6.4.8 Требования к специальному программному обеспечению
Специальное программное обеспечение (СПО) — совокупность прикладных программных средств, настроенных при развитии данной Системы. Назначение и требования к СПО Системы определяются назначением и требованиями к функциональной модели Системы. СПО должно быть интегрируемо, совместимо и функционировать во взаимодействии с медицинской информационной системой «Медиалог-Невро», установленной и функционирующей в НЦН РАМН и обладать следующими характеристиками: состоять из модулей «регистратура» с рабочим местом «кассира», «электронная история болезни амбулаторно-поликлинического приема», «электронная история болезни стационара неврологического профиля», «коечный фонд», «лаборатория» с функциональностью лабораторной информационной системы, «аптека», «статистика», «импорт данных», «обработка изображений», «финансовый учет», «администрация».
СПО Системы должно предусматривать:
— средства контроля корректности и непротиворечивости данных;
— резервное копирование (архивация) данных, а также возможность настройки сессий автоматического копирования должны быть предусмотрены стандартными функциями системы управления базами данных и ПО сервера баз данных;
— работу одновременно тестовой и рабочей Систем и соответствующих лицензий к ним;
— средства печати документов из Системы.
Дата добавления: 2014-10-22; Просмотров: 502; Нарушение авторских прав?;
Функциональные и нефункциональные требования
Требования к программной системе классифицируются как функциональные и нефункциональные.
Функциональные требования. Это перечень функций, которые должна выполнять система, причем должно быть указано, как система реагирует на те или иные входные данные, как она ведет себя в определенных ситуациях и т.д. В некоторых случаях указывается, что система не должна делать. Пример функционального требования к библиотечной системе университета, предназначенной для заказа книг и документов из других библиотек:
1. Пользователь должен иметь возможность проводить поиск необходимых ему книг и документов или по всему множеству доступных каталожных баз данных
2. Система должна предоставлять пользователю подходящее средство просмотра библиотечных документов.
3. Каждый заказ должен быть снабжен уникальным идентификатором (NUM_ID), который копируется в формуляр пользователя для постоянного хранения.
Системные (нефункциональные) требования. Описывают характеристики системы и ее окружения, а не поведение системы. Здесь также может быть приведен перечень ограничений, накладываемых на действия и функции, выполняемые системой.
4.4. Требования к программному обеспечению
Они включают временные ограничения, ограничения на процесс разработки системы, стандарты и т.д.
Все системные требования можно разбить на три большие группы.
1.Требования к продукту. Описывают эксплуатационные свойства программного продукта. Сюда относятся требования к производительности системы, объему необходимой памяти, надежности (определяет частоту возможных сбоев в системе), переносимости системы на разные компьютерные платформы и удобству эксплуатации.
2.Организационные требования. Отображают политику и организационные процедуры заказчика и разработчика ПО. Они включают стандарты разработки программного продукта, требования к реализации ПО (т.е. к языку программирования и методам проектирования), выходные требования, которые определяют сроки изготовления программного продукта, и сопутствующую документацию.
3.Внешние требования. Учитывают факторы, внешние по отношению к разрабатываемой системе и процессу ее разработки. Они включают требования, определяющие взаимодействие данной системы с другими системами, юридические требования, следование которым гарантирует, что система будет разрабатываться и функционировать в рамках существующего законодательства, а также этические требования. Последние должны гарантировать, что система будет приемлемой для пользователей или заказчика.
Системные требования должным быть выражаться через количественные показатели, которые можно объективно измерить.
Пример системного требования:
Система должна быть простой в эксплуатации для опытного оператора и сводить количество его ошибок к минимуму
Данное требование лучше сформулировать так:
Опытному оператору должны быть доступны все системные функции после двух часов обучения работ данной системой. После такого обучения среднее число ошибок оператора не должно превышать двух за рабочий день.
В таблице 1Таблица 1 приведены показатели, с помощью которых можно специфицировать системные свойства.
Количественные показатели для системных требований
Таблица 1. Количественные показатели для системных требований
| Показатель | Единицы измерения |
| Скорость | Количество выполненных транзакций в секунду; время реакции на действия пользователя; время обновления экрана |
| Размер | Килобайты; количество модулей памяти |
| Простота эксплуатации | Время обучения персонала; количество статей в справочной системе |
| Надежность | Средняя продолжительность времени между двумя последовательными проявлениями ошибок в системе; вероятность выхода системы из строя; коэффициент готовности системы |
| Устойчивость к сбоям | Время восстановления системы после сбоя; процент событий, приводящих к сбоям; вероятность порчи данных при сбоях |
| Переносимость | Процент машинно-зависимых операторов; количество машинно-зависимых подсистем |
Дата добавления: 2016-12-17; просмотров: 373 | Нарушение авторских прав
Поиск Лекций
Классификация требований к ПО
LABA 2
1.1 Классификация требований
Требования разных уровней, это :
· требованияпользователя для обозначения высокоуровневых обобщенных требований;
· системные требованиядля детализированного описания выполняемых системой функций.
Третий уровень требований используется для более детализированного описания системы – проектная системная спецификация, которая может служить мостом между этапом разработки требований и этапом проектирования системы.
Три перечисленных вида требований можно определить следующим образом.
1 Требования пользователя – описание на естественном языке (плюс поясняющие диаграммы) функций, выполняемых системой, и ограничений, накладываемых на нее.
2 Системные требования – детализированное описание системных функций и ограничений, которое иногда называют функциональной спецификацией. Она служит основой для заключения контракта между покупателем системы и разработчиками программного обеспечения.
3 Проектная системная спецификация – обобщенное описание структуры программной системы, которое будет основой для более детализированного проектирования системы и ее последующей реализации. Эта спецификация дополняет и детализирует спецификацию системных требований и разрабатывается для команды разработчиков.
Требования пользователя
Спецификация требований пользователя представляет собой процесс организации информации о нуждах пользователя и отображения их в документе.
Требование является условием или возможностью, необходимым пользователю, чтобы решить задачу или достичь цели. Поэтому существуют два вида требований: «мандатным требованиям» и «ограничительным требованиям».
Мандатные требования должны определять операцию или последовательность связанных операций, которые программное обеспечение будет способно выполнить. Мандатные требования в группе должны быть структурированы так, чтобы отражать любые временные или причинные связи между ними..
Требования пользователя к системе должны описывать функциональные и нефункциональные требования так, чтобы они были понятны даже пользователю, не имеющему специальных технических знаний.
Количественные формулировки, которые точно определяют атрибуты эффективности и точности, должны составлять часть спецификации мандатных требований. Это означает, что мандатное требование должно быть квалифицированным в таких оценках, как: объем; скорость и точность.
Ограничительные требования. Пользователь может наложить ограничения на программное обеспечение , относящиеся к интерфейсам, качеству, ресурсам и временным диапазонам.
Требование интерфейсных связей может точно определять сети и сетевые протоколы, которые должны быть использованы.
Требование аппаратного интерфейса точно определяет все или часть компьютерной аппаратуры, на которой надо выполнить программное обеспечение. Указание формулировок марки и модели устройства, физических ограничений, например: размера, веса; эффективности, например: скорости, памяти
Требование программного интерфейса точно определяет, должно ли программное обеспечение быть совместимым с другими , например: другими приложениями, компиляторами, операционными системами.
Требование взаимодействия «человек-компьютер» точно определяет любой аспект интерфейса «пользователь- ПК». Это может включать положение о стиле, языке команд, меню, окнах; форматах сообщений, времени, затрачиваемое на ответ по команде.
Классификация требований к ПО
Системные требования обычно служат основой для заключения контракта на разработку программной системы и поэтому должны представлять максимально полную спецификацию системы в целом. Системные требования также используются в качестве отправной точки на этапе проектирования системы.
Системные требования определяют, что должна делать система, не показывая при этом механизма ее реализации (как).
Спецификация системных требований может строиться на основе различных системных моделей, таких, как объектная модель или модель потоков данных.
Но для полного описания системы требуется детализированная информация о ней, которая по возможности должна включать всю информацию о системной архитектуре.
Первоначальная архитектура системы помогает структурировать спецификацию требований.
2. В качестве внешнего системного требования может выступать условие использования для разрабатываемой системы специальной архитектуры.
В спецификацию системных требований входит также спецификация интерфейсов.
Различают три типа специфицируемых интерфейсов.
1. Процедурные интерфейсы, когда существующие подсистемы предлагают набор сервисов, доступных посредством вызываемой интерфейсной процедуры.
2. Структуры (интерфейсные форматы) данных, которые пересылаются от одной подсистемы к другой.
3. Специальные представления данных, например в виде упорядоченной последовательности двоичных разрядов.
Требования к программному обеспечению также классифицируются как функциональные, нефункциональные и требования предметной области.
1 Функциональные требования. Это перечень сервисов, функций, которые должна выполнять система (или системный компонент ), причем должно быть указано, как система реагирует на те или иные входные данные, как она ведет себя в определенных ситуациях и т.д. В некоторых случаях указывается, что система не должна делать.
2 Нефункциональные требования. Описывают характеристики системы и ее окружения, ане поведение системы. Здесь также может быть приведен перечень ограничений, накладываемых на действия и функции, выполняемые системой. Они включают временные ограничения, ограничения на процесс разработки системы, стандарты и т.д.
Требования к программному обеспечению
Т.е. указываются характеристики производительности, которым должны удовлетворять система или ее компонент, такие как скорость, точность или частота.
3 Требования предметной области.Характеризуют ту предметную область, для которой разрабатывается система. Эти требования могут быть функциональными и нефункциональными.
Источник: steptosleep.ru
Структура и виды требований к программному обеспечению
В современной практике существует множество подходов к формированию и управлению требованиями, но так или иначе, в основе всех подходов лежит знание и понимание видов требований и их последующего использования в работе.
Среди изученных мной классификаций требований я не нашел ту, которая наиболее полно описывала целостную структуру требований к системе и их взаимное влияние. Однако, полученная информация в совокупности позволяет сформировать представление о структуре требований к системе в целом и использовать рекомендации по видам требований для подготовки более качественного аналитического материала. Многие опытные аналитики знают, что частой проблемой IT проектов является передокументирование — ситуация, когда на разработку документации тратится огромное количество ресурсов, при этом объема информации значительно больше, чем требуется для разработки самой системы. В таком случае, мне видится, что первоочередной задачей является оценка необходимости и достаточности того или иного вида требований. Эта задача может быть решена только понимая, как тот или иной вид требований влияет на конечный программный продукт, учитывая его назначение, стадию реализации, состав и квалификацию команды, модель разработки и другие факторы.
Понятие “Уровень требований”
В различных классификациях понятие “Уровень требований” или “Уровень детализации” либо отсутствует вовсе, либо не имеет определения, хотя сами виды требований по уровням распределены. Чтобы исключить двусмысленность при освещении темы приведу мое личное понимание термина и буду придерживаться его. Уровень требований — это глубина детализации описания системы, процесса ее проектирования и разработки в зависимости от стадии, на которой находится проект .
Почему я рассматриваю требования к проекту и продукту, почему продуктом выбрана АС?
Разработка программного продукта или в более широком смысле автоматизированной системы это всегда проект. Выпустить продукт к определенному сроку, решающий конкретные задачи — формулировка полностью соответствующая заветам SMART (методика постановки целей). Проработав структуру требований к наиболее общему случаю, всегда можно трансформировать ее к частному или дополнить, для исключительных ситуаций. Сама информационная система это симбиоз программных, аппаратных средств, людей и любой информации, относящейся к предметной области системы.
Структура требований к программному обеспечению. Общая схема.
Почему я придерживаюсь трехуровневой структуры требований?
В отдельных документах ГОСТа на разработку ПО определяются 2 уровня требований, которые характеризуются максимально размыто: верхний уровень требований и нижний уровень требований. Четких правил определения видов требований на тот или иной уровень мне найти не удалось.
Лишь косвенно можно судить, что верхний уровень содержит более общее описание продукта, без технических подробностей, а нижний, соответственно, более детализирован. Карл Вигерс и Дин Леффингуэлл приводят описание трехуровневой структуры требований. Несмотря на некоторые различия в названиях видов требований, размещенных на уровнях, обе концепции объединяет последовательность формирования требований на каждом из уровней и их четкая взаимная зависимость друг от друга. Дробление структуры на большее количество уровней потребует наличия однозначных критериев для определения в них требований, и как мне кажется, является избыточным, поскольку на каждом уровне требований должны быть сформированы артефакты (документы), необходимые на текущей стадии проекта. Трехуровневая структура наилучшим образом соотносится с процессами сбора, формирования и управления изменениями требований вне зависимости от применяемой на проекте методологии, например водопад или SCRUM.
I уровень требований
Верхним уровнем требований (первым) являются бизнес-требования. Тезисы с которых начинается IT проект и последующее обсуждение будущего продукта.
Бизнес-требования содержат высокоуровневые цели (потребности) заказчиков системы. Во многих подходах к классификации требований бизнес-требования являются основополагающими, их часто относят к области проблемы, идее. На основе бизнес-требований, как правило, невозможно произвести оценку трудоемкости проекта, однако они определяют ценность продукта и ограничивают требования и фантазии пользователей. Первый уровень требований находит свое отражение в таких документах как: vision, концепция автоматизированной системы, дорожная карта и т.п.
Формулировка из области IT
В начале следующего года моя организация должна выдавать разрешения на строительство в электронном виде.
Абстрактная формулировка
Мне необходима в начале следующего месяца 1 тонна яблок.
II уровень требований
Второй уровень включает в себя два вида требований: требования пользователей и бизнес-правила.
Пользовательские требования описывают цели и задачи, которые система позволит решить пользователям. Существует множество подходов к описанию пользовательских требований. Для примера приведу некоторые из них: user story , use cases , модели и описание бизнес процессов, тезисный список пожеланий. Так или иначе, в основе лежит изучение предметной области в тех границах, которые очерчены бизнес-требованиями. Безусловно, выходить за пределы границ при анализе приходится, но конечная реализация должна соответствовать исходным целям бизнеса.
Формулировка из области IT
Необходимо реализовать в системе подписание документов электронной подписью.
Или в формате User Story: Я, как руководитель организации, хочу подписывать итоговое разрешение на строительство электронной подписью, чтобы соблюсти требование законодательства.
Абстрактная формулировка
Необходимо расфасовать партию яблок по коробкам, весом не более 10 кг.
Или в формате User Story: Я, как продавец, хочу получать товар в упаковке, весом не более 10 кг, чтобы не надорваться при подъеме на стеллаж.
Бизнес-правила описывают корпоративные политики, правительственные постановления, промышленные стандарты, вычислительные алгоритмы и, как правило, сами по себе являются артефактами (документами). Их очень часто относят к нефункциональным требованиям. Я намеренно на схеме разместил бизнес-правила и функциональные требования на разных уровнях. По большому счету, бизнес-правила существую скорее как свойства предметной области, они не появились просто так и не стали продуктом творчества проектировщиков продукта. В этой связи, изучать и анализировать их следует в контексте связанных бизнес-процессов и пользовательских сценариев, чтобы учесть в будущем в функциональных требованиях и ограничениях системы.
Формулировка из области IT
Срок ответа на заявление физического лица составляет не более 3-х рабочих дней со дня подачи заявления (ФЗ №___ от __ _____ ___).
Абстрактная формулировка
Высота полок стеллажа для хранения 30 см. Ширина стеллажа составляет 2,5 м. Глубина полок — 40 см.
Пользовательские требования можно использовать для предварительной оценки трудозатрат, но следует принимать во внимание возможные риски, связанные с изменением процессов работы пользователей, корректировкой бизнес-правил. К счастью, при должном описании требований на этом уровне, управлять изменениями можно без существенных потерь.
III уровень требований
Третий уровень самый насыщенный. Пять групп требований описывают систему и процессы, связанные с выпуском продукта. Именно на основе требований третьего уровня и будет разрабатываться будущий продукт. В современной литературе часто выделяют всего три группы требований: функциональные, нефункциональные, системные. На практике же, приходится сталкиваться с дополнительными характеристиками системы и процесса ее разработки, которые не находят по разным причинам своего отражения в проектной документации, что в конечном счете приводит к незапланированному изменению объемов работ.
Группа функциональных требований
Функциональные требования определяют функциональность ПО, которую разработчики должны реализовать, чтобы пользователи смогли выполнить свои задачи в рамках бизнес-требований. Тезисы функциональных требований являются квинтэссенцией пользовательских требований с учетом бизнес-правил. Иногда можно встретить выделение ограничений в отдельную группу тезисов.
Логически, для понимания структуры требований это оправданно, но с точки зрения документации чаще всего ограничения описываются в том же абзаце, что и функциональное требование. Так проще управлять изменениями. Кроме того, ограничения могут присутствовать и для требований других групп, логично упоминать о них рядом с соответствующим требованием.
В группу функциональных включены требования к функциям и задачам системы, к входным и выходным данным и сигналам, эмерджентные свойства.
Формулировка из области IT
Система должна обеспечивать уведомление заявителя о действиях с его заявлением в системе и результатах рассмотрения запроса.
Абстрактная формулировка
Партия яблок должна быть расфасована в упаковки из жесткого пластика или дерева высотой не более 25 см, шириной не более 40 см, длиной не более 30 см, общим весом (с учетом веса упаковки) не более 10 кг.
Требования к функциям и задачам содержат перечень функций, задач или их комплексов (в том числе обеспечивающих взаимодействие частей системы), подлежащих автоматизации, временной регламент реализации функций и задач, характеристики необходимой точности и времени выполнения, требования одновременности выполнения группы функций, достоверности выдачи результатов, перечень и критерии отказов для каждой функции, по которой задаются требования по надежности.
Требования к входным и выходным данным и сигналам описывают состав информации, которая поступает в систему и выдается в качестве результата выполнения ее функций, логические взаимосвязи между наборами данных (сигналов) и правила их проверки и трансформации.
Эмерджентные свойства описывают требования, которые не относятся к отдельным функциям системы, а проявляются в результате выполнения совокупности функций (иногда совершенно независимых друг от друга). Являются свойствами целостности системы. В большинстве классификаций, такие свойства не рассматриваются как отдельный вид требований, однако, при определенных обстоятельствах, наличие и понимание таких свойств может определять логику взаимодействия отдельных элементов системы друг с другом или же системы в целом с внешним миром.
Группа системных требований и ограничений
Системные требования и ограничения определяют общие для всей системы характеристики. В данную группу входят целевые показатели системы, требования к структуре и функционированию системы, эргономике, технической эстетике и usabilty ( UX ).
Целевые показатели устанавливают количественные значения отдельных свойств или элементов системы, которые она должна демонстрировать в процессе функционирования, а также значения показателей бизнеса, которые требуется достигнуть в определенные периоды времени. Очень часто для удобства отслеживания целевых показателей в системе реализуются функции мониторинга или ведения аналитической отчетности.
Структура и функционирование системы отражает требуемый компонентный состав системы, перечень программных и аппаратных средств, режим функционирования системы в целом и ее компонентов.
Эргономика, техническая эстетика , удобство использования (UX) — это, как правило, общие требования к реализации интерфейсов, применению цветовых схем, гарнитур шрифтов, наличию общих функций для отдельных компонентов пользовательского интерфейса, а также требования к организации рабочего пространства и установки оборудования. Данные требования направлены на повышение эффективности использования разрабатываемой системы.
Группа нефункциональных требований
Нефункциональные требования определяют свойства, которые система должна демонстрировать, или ограничения, которые она должна соблюдать, не относящиеся к поведению системы. В литературе можно встретить множество вариаций включенных в эту группу требований, однако основной пул относится к атрибутам качества системы, требованиям к патентной чистоте и правам на интеллектуальную собственность, а также безопасности системы и сохранности данных.
Атрибуты качества описывают способности программного обеспечения сохранять свой уровень качества функционирования при установленных условиях за установленный период времени. Стандарт ISO 9126 содержит характеристики и атрибуты качества, а также метрики для их оценки. Часть атрибутов качества из ISO может быть неприменима к разрабатываемой системе, часть атрибутов будет обусловлена назначением и областью применения продукта.
Требования к патентной чистоте и правам на интеллектуальную собственность для ряда систем могут не применяться. Но в большинстве случаев заказчики стараются защитить себя от юридических проблем и свой продукт от неправомерного использования третьей стороной. К такого рода требованиям будут относится правила, нормы и условия регистрации ПО в надзорных органах, положения по регулированию использования в системе стороннего ПО или отдельных компонент и так далее.
Требования безопасности системы подразумевают не только информационную безопасность, но и правила безопасности использования входящего в систему оборудования.
Требования к сохранности (данных) содержат описание функций и свойств системы по сохранности и восстановления данных при сбоях, правила длительного хранения, архивирования исторических данных.
Группа требований к внешним интерфейсам
Требования к внешним интерфейсам включают в себя описание не только пользовательских интерфейсов, но и программных интерфейсов, интерфейсов оборудования, связи и коммуникации.
Требования к интерфейсам пользователя (UI) очень часто ограничиваются только макетами или скетчами, реже подготовкой прототипов. На самом же деле, макеты и прототипы необходимо дополнять описанием поведения компонентов интерфейса, или формировать типовые компоненты, с однозначно определенным поведением.
Требования к программным интерфейсам указывают на особенности системы к взаимодействию модулей и компонентов системы друг с другом, а также правила и форматы взаимодействия системы с внешним миром (другими системами например).
Требования к интерфейсам оборудования определяют взаимосвязи и элементы управления любым оборудованием, входящим в систему.
Требования к интерфейсам связи и коммуникации — это требования к каналам и протоколам передачи данных из системы и к системе, а также между распределенными узлами системы при их наличии.
Группа требований к видам обеспечения
Требования к видам обеспечения больше относится к процессам проектирования, разработки, внедрения и сопровождения системы, нежели к самой системе.
Требования к программному обеспечению обычно включают наименования, характеристики, версии ПО, используемого в разработке, сопровождении, тестировании, мониторинге, а также в качестве отдельных элементов системы (включая серверные операционные системы, СУБД, конверторы данных и прочее).
Требования к аппаратному обеспечению содержит характеристики требуемого оборудования и параметры клиентских станций для работы с системой.
Требования к информационному обеспечению описывают совокупность системы классификации и кодирования информации, унифицированных систем документации и информационных массивов. К числу объектов, к которым могут предъявляться требования относятся не только базы данных самой системы, способы ее ведения, кодирования и обновления, но и любые информационные носители (в том числе и физические документы предметной области) относящиеся к процессу эксплуатации системы.
Требования к метрологическому обеспечению применяются больше для информационных измерительных систем и содержат сведения об измеряемых величинах и их характеристиках, перечни измерительных каналов и нормы их погрешностей, условия измерений, условия метрологического обслуживания.
Требования к организационному обеспечению включают требования к структуре и функциям подразделений, участвующих в функционировании системы или обеспечивающих эксплуатацию, к организации функционирования системы и порядку взаимодействия персонала АС и персонала объекта автоматизации, к защите от ошибочных действий персонала системы. Несмотря на то, что описание заимствовано из ГОСТ, взаимодействие людей в процессе создания и эксплуатации продукта является важным моментом практически каждого подхода к разработке.
Выводы
Структура требований очень обширна. Часть требований может возникнуть в процессе эксплуатации, часть обусловлена необходимостью исполнения законодательства или предметной областью. Отражение конкретного вида требований в документации зависит от множества факторов, однако стоит помнить, что чем больше требований к продукту выявлено на стадии анализа и проектирования системы, тем качественнее получится продукт и более эффективно будут использованы ресурсы разработчиков.
Последнее изменение: Пятница, 28 октября 2022 20:10
- требования
- виды требований
- структура
- анализ
- аналитика
- программное обеспечение
- по
- система
- софт
- разработка
- разработка программного обеспечения
Источник: personalyst.pro