Л.Новиков в русской редакции нотации RUP приводит следующее определение: «Требование – это условие или возможность, которой должна соответствовать система».
В IEEE Standard Glossary of Software Engineering Terminology (1990)
данное понятие трактуется шире. Требование – это:
1) условия или возможности, необходимые пользователю для решения проблем или достижения целей;
2) условия или возможности, которыми должна обладать система или системные компоненты, чтобы выполнить контракт или удовлетворять стандартам, спецификациям или другим формальным документам;
3) документированное представление условий или возможностей для пунктов 1 и 2.
Основным источником требований к информационной системе, безусловно, являются соображения, высказанные представителями Заказчика.
Ключевой стратегией выявления требований было и остается интервью с экспертами.Полезными приемами являются формирование программы беседы и ознакомление с ней респондента, подробное планирование беседы вплоть до записи подготовленных вопросов. Подготовленное таким образом интервью называют структурированным. В дополнение к так построенному интервью предлагается проводить неструктурированное интервью, «представляющее собой неформальную встречу, которой не свойственны заготовленные впрок вопросы или заранее поставленные цели». Цель такого интервью – пробудить респондента к креативу в области, в которой интервьюер недостаточно хорошо ориентируется.
Законодательные требования РФ по информационной безопасности 2023 | Алексей Лукацкий
Анкетирование – самый малозатратный для аналитика способ извлечения информации, он же – и наименее эффективный. Обычно применяется как дополнение к другим стратегиям выявления требований.
Недостатки анкетирования очевидны: респонденты часто бывают неспособны, либо слабо мотивированы в том, чтобы хорошо и информативно заполнить анкету. Велика вероятность получить неполную или вовсе ложную информацию. Преимущество – в том, что подготовка и анализ анкет требуют небольшой ресурс.
Наблюдение за работой моделируемой организационной системы – полезная стратегия получения информации.
Различают пассивное и активное наблюдение. При активном наблюдении аналитик работает, как участник команды, что позволяет улучшить понимание процессов.
Через наблюдение, а возможно, и участие аналитики получают информацию о происходящих день за днем операциях из первых рук. Во время наблюдения за работой системы часто возникают вопросы, которые никогда бы не появились, если бы аналитик только читал документы или разговаривал с экспертами.
Недостатком этой стратегии является то, что наблюдатель, как и всякий «измерительный прибор», вносит помехи в результаты измерений: сотрудники организации, находясь «под колпаком» могут начать вести себя принципиально по-другому, чем обычно.
Документы – хороший источник информации, потому что они чаще всего доступны и их можно «опрашивать» в удобном для себя темпе. Чтение документов — прекрасный способ получить первоначальное представление о системе и сформулировать вопросы к экспертам.
Как описывать требования к интеграции информационных систем? Ольга Пономарева
Если опытный аналитик уже исследовал большое число систем такого же типа, что и на предприятии внедрения, он обладает фундаментальными знаниями в соответствующей предметной области, относительно определенного класса систем.
По результатам анализа документов и собственных знаний аналитик может составить описание требований и предложить его представителям Заказчика в качестве информации к размышлению, либо – основы для формирования технического задания.
Недостаток этой стратегии – опасность пропуска знаний, специфичных для объекта исследования (в случае самоопроса), либо – неформализованных знаний, эмпирических правил и процедур, широко используемых на практике, но не вошедших в документы.
Прототипирование– ключевая стратегия выявления требований в большинстве современных методологий. Программный прототип – «зеркало», в котором видно отражение того, как понял Исполнитель требования Заказчика. Процесс выявления требований путем прототипирования тем более интенсивен, чем это зеркало кривее.
Документальный способ выявления требований всегда уступает живому общению. Анализ того, что сделано в виде интерфейсов пользователя дает еще больший эффект. Подключается правополушарный канал восприятия, который, как известно, работает у большинства людей на порядок эффективнее, чем вербальный.
В данной работе был использован метод самостоятельного составления требований и прототипирования.
Обычно выделяют три уровня требований.
1) На верхнем уровне представлены так называемые бизнес-требования (businessrequirements). Примеры бизнес-требования: система должна сократить срок оборачиваемости обрабатываемых на предприятии заказов в три раза. Бизнес-требования обычно формулируются топ-менеджерами, либо акционерами предприятия;
2) Следующий уровень – уровень требований пользователей (userrequirements). Пример требования пользователя: система должна представлять диалоговые средства для ввода исчерпывающей информации о заказе, последующей фиксации информации в базе данных и маршрутизации информации о заказе к сотруднику, отвечающему за его планирование и исполнение. Требования пользователей часто бывают плохо структурированными, дублирующимися, противоречивыми. Поэтому для создания системы важен третий уровень, в котором осуществляется формализация требований;
3) Третий уровень – функциональный (functionalrequirements). Пример функциональных требований (или просто функций) по работе с электронным заказом: заказ может быть создан, отредактирован, удален и перемещен с участка на участок.
В дальнейшем будет использоваться именно третий уровень.
Функциональные требования регламентируют функционирование или поведение системы (behavioralrequirements). Функциональные требования отвечают на вопрос «что должна делать система» в тех или иных ситуациях. Функциональные требования определяют основной «фронт работ» Разработчика, и устанавливают цели, задачи и сервисы, предоставляемые системой Заказчику.
Функциональные требования записываются, как правило, при посредстве предписывающих правил: «система должна позволять кладовщику формировать приходные и расходные накладные». Другим способом являются так называемые варианты использования (userscases) – популярный и весьма продуктивный способ представления требований.
В качестве требований к тестируемой информационной системе были взяты следующие показатели:
1) возможность просмотра отчётов о состоянии домов;
2) возможность добавления информации о домах;
3) возможность удаления информации о домах;
4) возможность изменения информации о домах.
ИНДИВИДУАЛЬНОЕ ЗАДАНИЕ
В ходе практики было произведено исследование методов и технологий проектирования, разработки и тестирования программного обеспечения. В результате было созданы модель классов и структуры базы данных и программное средство. Разработка велась с использованием технологий Java, H2DB/JDBC. В качестве способа организации модулей была использована модель Model-Service-Controller-View. Она подразумевает, что программа делится на 4 уровня.
1) Model – отображает структуру базы данных на уровне программы.
2) Service – используется для работы с данными: чтение, запись, изменение, удаление, поиск.
3) Controller – модуль, отвечающий за все операции, производимые в программе. Именно здесь реализуются все основные алгоритмы.
4) View – модуль-интерфейс, отвечающий за отображение программы пользователю в виде графического или консольного приложения.
На рисунке 2 изображена модульная структура программы. Классы BaseHall.class и BaseEntity.class являются предками для классов Room.class, Flat.class, Floor.class, Entrance.class, House.class. Вместе эти классы представляют собой Model. Класс Service.class отвечает за операции над данными и представляет собой Service. Класс Controller.class отвечает за выполнение основных операций и алгоритмов и является Controller.
Класс View.class отвечает за отображение интерфейса конечному пользователю и представляет собой View. Класс Main.class служит инициализатором программы – с него начинается выполнение программы.
На рисунке 3 изображена структура базы данных для данного программного средства.
Рисунок 2 – диаграмма классов
Рисунок 3 – диаграмма «сущность-связь»
Данная программа позволяет через консоль просматривать, изменять, добавлять и удалять информацию о домах, а также выводить отчёт об итоговом состоянии домов.
На рисунках 4 и 5 изображена работа программы с точки зрения пользователя.
Рисунок 4 – главное меню
Рисунок 5 – пример отчёта
ЗАКЛЮЧЕНИЕ
В ходе производственной практики былиполучены навыки по разработке и тестированию программных средств на реальном производстве. Были описаны функциональные требования к разрабатываемому программному продукту. Основной целью программы является обработка информации: отображение, добавление, изменение и удаление данных.
Был написан прототип программы.
В процессе тестирования прототипа было реализовано 5 тест-кейсов, которые показали основные ошибки программы, на что стоит обратить внимание. По результатам тестирования был сформирован план по исправлению ошибок.
Источник: poisk-ru.ru
Требования к информационной и программной совместимости
В настоящее время, в условиях активного проникновения информационных технологий в систему образования, актуальной становится задача переосмысления теории организации учебного процесса и процесса управления образованием, процесса передачи систематизированных знаний, навыков и умений от одного поколения к другому, и создания новых методов и технологий обучения.
Сегодня ни у кого не вызывает сомнения тот факт, что электронные учебные пособия позволяют обогатить школьный курс обучения, дополняя его разнообразными возможностями компьютерных технологий, и делают его, таким образом, более интересным и привлекательным для учащихся.
Исключительно высокая степень наглядности представленного материала, взаимосвязь различных компонентов курсов, комплексность и интерактивность делают программы незаменимыми помощниками, как для ученика, так и для учителя.
Благодаря комплексу разнообразных мультимедийных возможностей (качественные иллюстрации, интерактивные задания и т.д.) процесс обучения становится более эффективным и интересным.
Цели создания электронного пособия:
— повышение эффективности и качества обучения;
— приобщение к индивидуальной форме обучения с помощью IT- технологий;
— обеспечение творческого и активного овладения студентами знаниями, умениями и навыками в данной области;
— развитие навыков по использованию компьютерных систем;
— психологическая адаптация студентов к инфокоммуникационной среде.
Очевидно, электронные учебные пособия и любые другие образовательные технологии не являются альтернативой преподавателю, хотя и предполагают альтернативные формы подачи материала, выполнения упражнений и контроля знаний.
Это, конечно же, расширение возможностей выбора для преподавателя при организации учебного процесса и способов подачи материала, не исключая использования технологий совместно с традиционными учебниками, а также в условиях обеспечения живого общения с преподавателем и между студентами.
Однако, вместе с тем, это не просто автоматизация деятельности преподавателя и освобождение его от механического, рутинного труда, а поиск и реализация тех форм и методов применения компьютеров, когда компьютерная система становится партнером преподавателя в достижении учебных целей.
На данный момент на рынке программных продуктов представлено множество программ для создания электронных учебников и курсов, но нет готового разработанного комплекса по дисциплине «Основы алгоритмизации и программирования». Заказчик обладает парком компьютеров, которые используются в учебном процессе и соответствуют всем техническим требованиям для внедрения подобного проекта.
ОСНОВАНИЕ ДЛЯ РАЗРАБОТКИ
Основанием для разработки служит задание на курсовое проектирование по дисциплине «Технология разработки программных продуктов», выданное преподавателем Хайрулиной Т.И. в рамках изучения дисциплины, а также заказ на разработку ЭРТ для проведения учебной практики по дисциплине «Основы алгоритмизации и программирования» для 3 курса.
Наименование работы: «ЭРТ для проведения учебной практики по дисциплине «Основы алгоритмизации и программирования» для 3 курса».
Исполнитель: студентка 431 группы, специальности 230105 Программное обеспечение ВТ и АС, ФГОУ СПО «ДТИИУ» Вершинина Евгения Андреевна.
НАЗНАЧЕНИЕ РАЗРАБОТКИ
Программный продукт предназначен для внедрения информационных технологий в процесс проведения учебной практики с целью автоматизации рабочего места студента при проведении практических занятий.
ТРЕБОВАНИЯ К ПРОГРАММЕ
Требования к функциональным характеристикам
Состав выполняемых функций
Программный продукт должен обеспечивать выполнение следующих функций:
— осуществление режима работы системы и вывод форм в зависимости от вошедшего в систему пользователя: преподавателя, студента;
— сохранение данных, вводимых пользователем;
— автоматизированное хранение информации;
— представление лекционных материалов и инструкционных карт на экране компьютера;
— распределение и сохранение результатов выполнения заданий в соответствующие папки;
— автоматизация процесса контроля знаний обучающихся с помощью тестирования;
— ведение статистики по результатам тестирования с выдачей необходимой информации по запросу;
— осуществление оперативного поиска;
— формирование отчетных документов.
Организация входных и выходных данных
Входными данными для разработки ЭРТ являются:
— инструкционные карты и учебный материал в бумажном формате;
— тестовые материалы для организации режима самоконтроля и контрольного тестирования знаний студентов по дисциплине;
— сведения о студенте, участвующем в режиме контрольного тестирования.
Выходными данными для разработки ЭРТ являются:
— страницы электронной рабочей тетради с данными, соответствующими входным;
— темы и варианты контрольного тестирования для их выбора;
— файлы с результатами выполнения заданий студентами в формате используемых приложений, размещённые в соответствующих папках.
Требования к надёжности
Надёжность программного средства должна соответствовать следующим требованиям:
— контроль целостности данных на уровне СУБД;
— защита от ошибочных действий пользователей на уровне пользовательского приложения;
— гарантирование сохранности данных при сбоях в работе внешних устройств на уровне СУБД;
— обеспечение обнаружения и диагностики ошибок с выдачей соответствующих сообщений пользователю на уровне пользовательского приложения.
Условия эксплуатации
Данное программное средство предназначено для пользователей с базовыми навыками владения ЭВМ. Программный продукт должен выполняться на исправном оборудовании. Условия эксплуатации носителя информации:
— температура -5-35 С°;
— влажность от 10-80%.
Требования к составу и параметрам технических средств
Программный продукт должен корректно работать на следующем и совместимым с ним оборудовании:
— тип процессора – Pentium III и выше;
— объём оперативного запоминающего устройства – 256 Мб и более;
— объём свободного места на жёстком диске – 40 Мб;
Требования к информационной и программной совместимости
ЭРТ не предъявляет никаких специальных требований к системе. Программный продукт разработан на языке Borland Delphi 7. В качестве СУБД использована MS Access 2003. Так как электронные модули скомпилированы с помощью свободно распространяемого компилятора Help https://megalektsii.ru/s74161t3.html» target=»_blank»]megalektsii.ru[/mask_link]
Как сформировать требования к информационной системе
В понятие «требования к информационной системе» можно вложить несколько смыслов. Первое определение требований — комплексное описание того, как информационная система повлияет на работу компании. Второе определение требований — описание желаемого поведения системы при ее использовании участниками деятельности. Эти требования нужны для того, чтобы и вы, и разработчик системы понимал, что должно получиться в итоге. Оба тезиса применимы к цифровизации уже существующей деятельности и цифровизации планируемой.
Бывают случаи, когда заказчик приходит на встречу с разработчиком не подготовив требования и начинает импровизировать. В таком случае заказчик вываливает не структурированный набор информации, пытается описать всё и сразу, зацикливается на неважных мелочах. Из-за этого, как правило, либо стоимость разработки увеличивается в разы, либо система не решает глобальную проблему.
Как начать формулировать требования
Для начала давайте придумаем пример, на котором будем рассматривать формулирование требований — пусть это будет заключение договора с клиентом.
Первое, что необходимо сделать, это описать контекст в котором находится компания и автоматизируемою деятельность. Например, нужно описать, что в заключении договора несколько сотрудников выполняют определенные операции, что эти операции несут следующий бизнес смысл, который объединяется в определенный результат.
Используя наш пример с заключением договора, можно описать следующее:
«Наша компания “Рога и Копыта” занимается производством молочной продукции, для реализации данной продукции мы заключаем договоры с оптовыми покупателями. Из-за популярности нашей продукции у нас большое количество потенциальных покупателей, отдел продаж слишком долго формирует и подписывает договоры.
Автоматизируемая деятельность выглядит следующим образом: менеджер формирует и подписывает с заказчиком договор, передает договор в бухгалтерию для выставления счета».
Второе, что необходимо осмыслить и описать, это проблемы, которые заставили вас задуматься об автоматизации деятельности. Это может быть, как набор кейсов, так и описание того, что затрудняет работу.
Первая проблема. Менеджеры не используют актуальный шаблон договора, потому что нет единого места, где хранится такой шаблон. Из-за этого наша компания может понести финансовые убытки.
Второй проблемой является то, что менеджеры долго формируют данный договор, подставляя данные во все нужные поля.
Третья проблема — договоры долго доходят до бухгалтерии, из-за чего процесс получения денег сильно затягивается.
Четвертая проблема — менеджеры приходят/звонят в бухгалтерию, чтобы уточнить статус договора и денег, а это отвлекает бухгалтеров и сильно замедляет работу.
Третье, что необходимо описать — какую цель затрагивает создание системы. Система может регламентировать деятельность, сократить время на подготовку документов или что-то иное.
Первое — мы хотим организовать учет всех договоров, чтобы они не терялись.
Второе — мы хотим ускорить процесс формирования договора, в идеале — формировать его автоматически.
Третье — мы хотим сделать работу сотрудников более размеренной».
Сформулировав для себя эти три аспекта, вы уже поймете свои слабые места и сможете начать вносить изменения в деятельность.
Выделение ролей и бизнес смысла ролей
После того как вы выяснили, что и для чего вы будете автоматизировать нужно понять кто участвует в деятельности.
Вам нужно выделить всех участников и понять, что они делают в бизнес-деятельности и что они будут делать в информационной системе. Под описанием бизнес-деятельности имеется в виду то, какие действия совершают участники, не обращая внимания на информационную систему.
Общение с ролями, которые будут задействованы в автоматизируемой деятельности очень важно. Оно поможет глубже понять проблемы с которыми сталкиваются люди и описать систему подробнее, а также заложить фундамент для дальнейшего улучшения системы.
В нашем примере мы можем выделить трех участников — покупатель, менеджер и бухгалтер. Описание деятельности данных ролей может выглядеть следующим образом:
Покупатель. Бизнес-деятельность: оставляет запрос на предоставление некоторого количества товара, подписывает договор, оплачивает счет.
В системе: не выполняет никаких операций.
Менеджер. Бизнес-деятельность: общается с покупателем, заключает договор с покупателем, предоставляет информацию в бухгалтерию, контролирует статус сделки.
В системе: формирует договор, загружает подписанный скан для бухгалтерии.
Бухгалтер. Бизнес-деятельность: ведет учет обязательств покупателей и перед покупателями. В системе: меняет статус, отображающий состояние сделки, прикладывает к сделке документы — счета и акты.
Выделение периферийных систем
С деятельностью и информационной системой связаны не только люди. С ней могут быть связаны еще и другие системы и сервисы, что не менее важно.
Вам требуется понять, что задействовано в автоматизируемой деятельности. Например, это может быть телефония, 1С и электронная почта.
После того, как выяснили, что вы используете, надо подумать над тем, хотите ли вы интегрировать эти системы между собой, и если да, то какой результат должен быть. Это может помочь отказаться от использования продукта, который будет дублировать функции.
Продолжая рассматривать наш пример, давайте опишем взаимодействия систем:
Телефония. Необходимо настроить возможность принимать и осуществлять звонки из информационной системы, данная возможность должна быть только у менеджеров. Так же необходимо хранить записи разговоров, чтобы руководитель мог их прослушивать для оценки качества.
Почта. Необходимо, чтобы при формировании договора, система автоматически отправляла сгенерированный договор покупателю для ознакомления.
1С. С данной системой нет необходимости интегрироваться на данном этапе. В будущем возможно информационная система будет выступать источником сигналов, о полученных платежах по контрактам.
Что будет, если составить требования неправильно
К формулированию требований следует подходить ответственно. Если вы сформулируете требования некорректно или не полностью, то полученный вами продукт не будет соответствовать ожиданиям и вместо упрощения деятельности усложнит её.
Например, выше мы указали, что доступ к звонкам в системе имеет только менеджер. Если бы мы не указали этого, то звонки поступали бы не только им, а еще и в бухгалтерию, что сильно отвлекало бы бухгалтеров от работы и замедляло бы темп отдела.
Другим примером может быть следующее: вы можете запланировать, что будете работать по определенному алгоритму, который вы придумали, но в ходе реализации системы, решили поменять деятельность сотрудников, не проинформировав разработчиков. В данной ситуации вы попадаете на деньги и время, ведь вероятно придется переделывать функционал полностью.
На чем не стоит зацикливаться
Частая проблема при формулировании требований — погружение на уровень отдельных действий, внешнего вида или «кнопочек» в системе. Уделяя слишком много времени тому, как будет выглядеть та или иная кнопка, вы отдаляетесь от важного — цели создания системы.
Всегда помните, что вы формулируете требования, а не пишите техническое задание по ГОСТу. Не надо описывать требования слишком формальным языком, поскольку с данными требованиями будет знакомится такой же живой человек как и вы.
Важно формулировать мысли понятно и стараться избегать слишком поверхностного описания. В таком случае придется потратить время на разъяснение пунктов разработчикам.
Другой проблемой может быть, когда вы совмещаете уровень «кнопочек» и максимально широкое описание функционала. Например, заказчик говорит, что хочет нажать на кнопку и «увидеть всё». Но он сам не понимает, что имеет в виду под этим «всё».
Как мы помогаем формировать требования к системе в Бипиуме
Чем же сотрудники Бипиума помогают в формировании требований? Для начала, общаясь с вами мы помогаем понять проблему и цели создания системы.
Во время сбора требований мы стараемся выяснить, почему вы решили цифровизовать деятельность, какие проблемы возникают у компании в целом и у сотрудников в частности.
После чего, совместно с вами выделяем всех участников деятельности — людей и системы. А после всего этого помогаем в следующем — рассматриваем не идеальную ситуацию, когда всё у всех получается, а изучаем, что должно быть, если всё идет не по плану. После чего, мы готовим для вас документ где текстом и в виде схем описаны ваши пожелания к информационной системе. Оставьте заявку и мы поможем вам сформулировать требования.
Краткое резюме
Процесс формирования требований можно разделить на несколько этапов:
1. Выяснить, для чего система и какие проблемы она должна решить.
2. Понять, кто и как в ней будет работать.
3. Сформулировать требования к интеграциям с другими системами.
4. Расписать все возможные пути развития событий.
После того, как вы пройдете эти этапы, а заодно и все 5 стадий принятия необходимости это сделать, вы сможете рассчитывать на то, что у вас будет система, удовлетворяющая вашим запросам.
А еще вы можете обратиться к нам и мы поможем вам сформировать требования.
Источник: bpium.ru