Srs что это: SRS что это такое в машине? — Определение и принцип работы

Как работает ЭБУ системы SRS

21.02.2020

SRC — Supplementary Restraint System — это система пассивной безопасности, то есть все в вашем автомобилей, что обеспечивает защиту в экстренной ситуации. В современных машинах это довольно сложная система, включающая в себя множество элементов, таких как: фронтальные и боковые подушки, модули управления, датчики ускорения и различные сенсоры, отслеживающие положение людей в салоне, активные подголовники, модуль системы SRS, преднатяжители ремней безопасности.

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

Правильную работу и своевременное оповещение о проблемах контролирует ЭБУ системы SRC. Обычно она располагается под блоком отопителя или рычагом стояночного тормоза, причем управление установки блока SRSCM как правило обозначено стрелкой на крыше корпуса.

Принцип работы данной системы приблизительно такой:

1. В датчик ускорение X/Y встроен электрический акселерометр, который трансформирует ускорение машины вдоль продольной оси (X) в электрический сигнал. При боковых подушках безопасности вдоль поперечной (Y).
2. Полученный сигнал обрабатывается микроконтроллером.
3. Если порог срабатывания (он устанавливается для каждой модели отдельно) перейден, то блок SRSCM запускает транзисторы преобразователя мощности соответствующих цепей активации подушек безопасности.
4. В зависимости от вида столкновения, разные датчики выступают в качестве датчиков удара. При фронтальном таковым является датчики ускорения (X), при боковом — датчики бокового удара, а датчик ускорения (Y) служит предохранительным датчиком. Это необходимо, чтобы автомобиль мог «определить» какие именно подушки безопасности следует включить.

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

← Выбери себе мужской подарок на 23 февраля! График работы магазина 22-24 февраля →

Подбор оборудования:

Марка автомобиляAbarthAcuraAlfa RomeoAston MartinAudiBentleyBMWBrillianceBuickBYDCadillacCheryChevroletChryslerCitroenDaciaDaewooDaihatsuDodgeDSExeedFAWFerrariFiatFordFotonGeelyGMGreat WallHavalHondaHummerHyundaiInfinitiIsuzuJaguarJeepKiaLamborghiniLanciaLand RoverLexusLifanLincolnLotusMaseratiMaybachMazdaMercedes-BenzMiniMercuryMitsubishiNissanOldsmobileOpelPeugeotPlymouthPontiacPorscheRenaultRolls-RoyceRoverSAABSaturnScion SeatSkodaSmartSsangYongSubaruSuzukiTeslaToyotaVolkswagenVolvoГАЗИжТагАЗУАЗЛада (ВАЗ)

Выберите вид оборудованияНе важноАвтосканеры для личного использованияПрофессиональные автосканерыПрограмматорыОборудование для чип-тюнингаКорректировкa одометровПереходники для автосканеровШлейфы для приборных панелейДилерское диагностическое оборудованиеБортовые компьютерыСпецинструментГаражное оборудование

Модель автомобиляГод1980198119821983198419851986198719881989199019911992199319941995199619971998199920002001200220032004200520062007200820092010201120122013201420152016201720182018201920192020202020212021202220222023

Что такое SRS AIRbag или подушка безопасности

25 октября, 202125 октября, 2021 adminЗапчастиNo Comment on Что такое SRS AIRbag или подушка безопасности

Airbag в дословном переводе с английского – воздушный мешок, но в русском языке за системой пассивной безопасности SRS состоящей из множества компонентов закрепилось название подушка безопасности.

Что такое SRS AIRbag или подушка безопасности – Изготовление авто ключей. Корректировка пробега. Прошивка SRS AirBAG

Ситема  SRS  – Supplemental Restraint System  в дословном переводе с английского языка Дополнительная Удерживающая Система состоит из множества различных устройств, механизмов, электронных датчиков и сенсоров. Любая система подушек безопасности состоит из передних и боковых датчиков удара, блока управления SRS, пиропатронов и газогенераторов. Работа всех датчиков и устройств взаимосвязана друг с другом. Важно чтобы при ДТП срабатывали не все устройства одновременно, а только необходимые подушки и ремни. Датчики, расположенные в разных частях кузова автомобиля, фиксируют удар, направление удара, его силу, контакты датчиков замыкаются и электронные импульсы от датчика поступают на блок управления.

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

Например, Воздушная подушка срабатывает вместе с ремнем безопасности снижая вероятность получения травм водителем и передним пассажиром о какую-либо часть кузова автомобиля.  Во многих моделях автомобилей подушка не сработает если пассажир или водитель не пристегнут. Но последнее время у некоторых водителей особой популярностью пользуются различные заглушки замков безопасности. Чаще всего их покупают, когда лень пристегиваться, а постоянный зуммер сигнализатора не пристёгнутых ремней безопасности надоедает своим писком. Эксплуатация автомобиля, оснащенного подушками AIRbag с не пристегнутым водителем или пассажиром запрещена. При возникновении ДТП при фронтальном ударе не пристёгнутый водитель или пассажир может получить удар в голову подушкой безопасности намного сильнее чем о приборную панель. Скорость раскрывающейся подушки безопасности может достигать 300км/час. Максимальная безопасность и эффективность от сработавших подушек безопасности при столкновении возможна только при условии, что водитель и передний пассажир пристегнуты ремнями безопасности.

Что такое SRS AIRbag или подушка безопасности – Изготовление авто ключей. Корректировка пробега. Прошивка SRS AirBAG

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

Основные причины почему на приборной панели может загорется индикатор AIRBAG:

– Нарушение целостности одного из элементов системы (датчика, устройства, механизма)

– Отсутствие сигнала в электроцепи системы

– Отключен или плохой контакт в одном из разъемов

– Повреждение проводки в результате короткого замыкания

– Повреждение датчиков удара в дверях или в кузове автомобиля

– Перегоревший предохранитель

– Обнуление памяти блока SRS при попытке перепрошить после ДТП

– Завышенное сопротивление в одной из подушек

– Низкое напряжение в сети или разряженный аккумулятор

– Намокание датчиков после мойки и намокание проводки, расположенной под передними сиденьями после химчистки

– превышен срок эксплуатации пиропатронов и подушки безопасности который составляет около 10 лет.

crash data, srs, пиропатнон, подушки безопасности, ремни безопасности

Что такое спецификация требований к программному обеспечению? (Определение)

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

Каковы компоненты спецификации требований к программному обеспечению (SRS)?

• Введение
• Описание продукта
• Требования к программному обеспечению
• Требования к внешнему интерфейсу
• Нефункциональные требования

 

Нужны ли нам спецификации требований к программному обеспечению?

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

Еще от Edorardo RomaniDataCamp: Что я узнал после 44 курсов и 308 часов

 

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

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

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

Произошла ошибка.

Невозможно выполнить JavaScript. Попробуйте посмотреть это видео на сайте www.youtube.com или включите JavaScript, если он отключен в вашем браузере.

Как написать SRS (спецификацию требований к программному обеспечению). | Видео: База знаний AK

 

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

Написание SRS так же важно, как и обеспечение того, чтобы все соответствующие участники проекта действительно рассмотрели документ и утвердили его перед началом этапа сборки проекта. Вот как структурировать свою собственную SRS.
 

Введение

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

 

Описание продукта

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

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

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

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

Оба варианта являются допустимым способом построения этого раздела.

 

Требования к внешнему интерфейсу

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

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

 

Нефункциональные требования

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

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

Как написать спецификацию требований к программному обеспечению (SRS) в 2021 году

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

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

Документ SRS — один из самых важных документов в разработке программного обеспечения. Он описывает, как должна быть разработана программная система. Проще говоря, SRS предоставляет всем участникам дорожную карту для этого проекта.

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

Содержание

Почему важен документ SRS?

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

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

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

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

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

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

Что включает в себя SRS?

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

Документ SRS обычно включает следующие элементы:

• Цель разрабатываемого программного обеспечения
• Общее описание программного обеспечения
• Функциональность программного обеспечения или то, что оно должно делать
• Производительность программного обеспечения в производственной ситуации
• Нефункциональные требования
• Внешние интерфейсы или то, как программное обеспечение будет взаимодействовать с оборудованием или другим программным обеспечением, к которому оно должно подключаться
• Конструктивные ограничения или ограничения среды, в которой будет работать программное обеспечение

Разница между функциональными и нефункциональными требованиями

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

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

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

Прочтите также, как составить техническое задание, документ RFI и RFP.

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

Лучше всего организовать процесс написания документа SRS, начав со скелета и общей информации о разрабатываемом вами программном обеспечении, а затем добавив детали в конкретизируйте свой черновик. Вот шесть шагов, связанных с созданием документа SRS в разработке программного обеспечения:

Создание схемы

Первым шагом в этом процессе является создание схемы документа SRS. Вы можете создать его самостоятельно или использовать существующий шаблон SRS в качестве отправной точки. Вот основной пример контура SRS:

1. Введение
2. Цель
3. Предполагаемая аудитория
4. Предполагаемое использование
5. Область
6. Определения
7. Общее описание
8. Пользовательские нужды
9. и зависимости
12. 0008
13. Системные характеристики и требования
    1. Функциональные требования
    2. Требования к внешнему интерфейсу
    3. Системные характеристики
    4. Нефункциональные требования

Определив цель, вы должны воплотить ее в жизнь2, 9000 Начните с определения цели продукта во введении вашей SRS. Здесь вы описываете целевую аудиторию и то, как они будут использовать продукт. Вот как вы должны структурировать цель:

• Определить объем продукта
• Описать ценность, которую он принесет
• Показать, кто будет использовать программное обеспечение
• Подробно описать, как оно поможет в работе предполагаемых пользователей

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

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

Описание функциональных и нефункциональных требований

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

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

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

Добавление дополнительных сведений

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

Получить одобрение

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

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

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

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

Как написать варианты использования программного обеспечения в SRS

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

Вот шаги, которые вы можете выполнить, чтобы написать вариант использования:

1. Опишите конечных пользователей вашего продукта.
2. Сосредоточьтесь на одном из этих пользователей.
3. Разбейте взаимодействие этого пользователя на варианты использования. Каждое взаимодействие — это вариант использования.
4. Опишите последовательность событий для каждого варианта использования.
5. Напишите подробное описание действий пользователя и того, как должна реагировать система.
6. Расширьте каждый вариант использования альтернативными действиями пользователя и ответами системы.
7. Повторить 1-6 для каждого типа конечного пользователя.

Каковы характеристики отличного SRS в разработке программного обеспечения?

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

Явный

Документ SRS должен быть простым для понимания. Ничто не должно быть расплывчатым, чтобы не было недопонимания между заинтересованными сторонами.

Измеримый

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

Завершено

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

Жизнеспособность

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

Гибкость

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

Поддающийся проверке

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

Соответствие

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

Нет ограничений реализации

Документ SRS должен быть достаточно подробным, чтобы завершить работу, но не должен быть слишком конкретным, поскольку это может ограничить разработку. Разработка во многом зависит от сторонних сервисов, которые разработчики не контролируют.

Точно

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

• Лазейки: «Приложение должно загрузиться через 3 секунды, если это возможно».
• Неоднозначность: «Продукт MVP должен быть выпущен как можно быстрее».
• Субъективность: «Пользовательский интерфейс должен быть удобным для пользователя».
• Превосходная степень: «Это должно быть лучшее приложение в своем классе».
• Сравнительный анализ: «Это приложение должно быть лучше, чем Slack».

Пример спецификации требований к программному обеспечению (SRS)

Ниже приведен урезанный пример документа SRS для корпоративного чат-приложения под названием eChat:

Введение

«Электронный чат».

Предназначен для разработчиков, дизайнеров и тестировщиков, работающих в «eChat», а также инвесторов проекта. Этот план будет включать в себя краткое изложение:

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

  Клиенты

  Клиентами будут корпоративные компании. Он не будет нацелен на широкую публику.

  Функциональность

  • Пользователи должны иметь возможность регистрироваться с корпоративными учетными записями LDAP.
  • Пользователи должны иметь возможность создавать специальные группы чата, состоящие из наборов пользователей, и отправлять личные сообщения отдельным пользователям.
  • Пользователи должны иметь возможность вести текстовые чаты, которые они могут разбивать на цепочки.
  • Приложение должно поддерживать групповой видеочат с участием до 100 пользователей одновременно.

  Платформа

  Приложение будет разработано в React Native, чтобы можно было создавать веб-приложение, мобильное приложение для iOS и мобильное приложение для Android.

  Эти приложения будут подключаться к REST API, созданному с помощью .NET Core, для хранения и извлечения данных из базы данных MySQL.

  Аутентификация будет осуществляться через существующие установки LDAP.

  Обязанности разработчиков

  Разработчики из команды «eChat» будут нести ответственность за написание всего кода для приложения, разработку базы данных и управление выпусками.

  Класс пользователя и характеристики

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

  • Создание каналов, на которых могут взаимодействовать несколько пользователей корпоративный или частный для группы людей
  • Удаление этих каналов
  • Архивирование этих каналов

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

  Особенности системы

  Функциональные требования

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

  User Interfaces

  • Front-end software: React Native
  • Back-end software: .NET Core
  • Database software: MySQL
  • LDAP connection: Authentication in an enterprise environment

  Hardware Interfaces

  • Both Операционные системы Mac и Windows через веб-браузер по умолчанию
  • iPhone
  • Android
  • Нефункциональные требования

  Требования к производительности

  • Приложение должно загружаться и быть готовым к использованию в течение 3 секунд
  • Приложение должно обновлять интерфейс при взаимодействии в течение 2 секунд
  • База данных должна быть нормализована для предотвращения избыточных данных и повышения производительности
  • База данных должна быть распределена для предотвращения простоев

  Требования безопасности

  • Базы данных должны использовать сегментирование для обеспечения избыточности во избежание потери данных.
  • Резервные копии баз данных должны выполняться ежечасно и храниться в течение одной недели.

  Требования безопасности

  • Любые ключи, используемые для REST API, должны храниться в безопасном месте.
  • Только REST API должен иметь возможность подключаться к базам данных.
  • Базы данных должны быть защищены брандмауэром.

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

  • Доступность: поскольку это приложение имеет решающее значение для делового общения, мы поставим перед собой цель обеспечить доступность на четыре девятки (99,99%).
  • Корректность: Приложение никогда не должно позволять никому читать сообщения или обсуждения, не предназначенные для этого человека.
  • Ремонтопригодность: приложение должно использовать непрерывную интеграцию, чтобы можно было быстро развертывать функции и исправления ошибок без простоев.
  • Удобство использования: интерфейс должен быть прост в освоении без учебника и позволять пользователям достигать своих целей без ошибок.