Студопедия

КАТЕГОРИИ:


Архитектура-(3434)Астрономия-(809)Биология-(7483)Биотехнологии-(1457)Военное дело-(14632)Высокие технологии-(1363)География-(913)Геология-(1438)Государство-(451)Демография-(1065)Дом-(47672)Журналистика и СМИ-(912)Изобретательство-(14524)Иностранные языки-(4268)Информатика-(17799)Искусство-(1338)История-(13644)Компьютеры-(11121)Косметика-(55)Кулинария-(373)Культура-(8427)Лингвистика-(374)Литература-(1642)Маркетинг-(23702)Математика-(16968)Машиностроение-(1700)Медицина-(12668)Менеджмент-(24684)Механика-(15423)Науковедение-(506)Образование-(11852)Охрана труда-(3308)Педагогика-(5571)Полиграфия-(1312)Политика-(7869)Право-(5454)Приборостроение-(1369)Программирование-(2801)Производство-(97182)Промышленность-(8706)Психология-(18388)Религия-(3217)Связь-(10668)Сельское хозяйство-(299)Социология-(6455)Спорт-(42831)Строительство-(4793)Торговля-(5050)Транспорт-(2929)Туризм-(1568)Физика-(3942)Философия-(17015)Финансы-(26596)Химия-(22929)Экология-(12095)Экономика-(9961)Электроника-(8441)Электротехника-(4623)Энергетика-(12629)Юриспруденция-(1492)Ядерная техника-(1748)

Додавання нового запису




Виклик наряду.

3.15.1. Опис і пріоритет.

Операція виклику наряду має високий пріоритет. Система передбачає можливість керування швидким викликом наряду.

3.15.2. Причинно – наслідкові зв’язки.

Користувач Наслідки
Користувач на пункт меню “Викликати наряд”. Система проводить оповіщення охоронної фірми банку, а також автоматично повідомляє в відділок міліції про надзвичайний стан.

 

3.15.3. Функціональні вимоги.

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

 

3.16.1. Опис і пріоритет.

Операція додавання нового запису має середній пріоритет. Система передбачає керування базою даних з відеозаписами за певний період.

3.16.2. Причинно – наслідкові зв’язки.

Користувач Наслідки
Користувач натискає на підпункт “додати новий запис” пункту меню “Керування базою відеозаписів”. Система відображає форму внесення нового запису.
Користувач заповнює форму (ПІБ, касирів та опис дій, що відбулися). Система перевіряє коректність інформації в заповнених полях.
Користувач натискає на кнопку “Добавити”. Система відправляє запит на додавання (або якщо запис вже існує на редагування) запису.

 

3.16.3. Функціональні вимоги.

В разі коли трапляється помила обробки запиту система повідомляє користувачу про невдалу операцію. Якщо користувач не заповнив всі необхідні поля та натиснув на кнопку додавання запису, то відбувається виведення відповідного повідомлення, незаповнені, або неправильно заповнені поля підсвічуються.

 

3.17. Підтвердити перевірку терміналу.

3.17.1. Опис і пріоритет.

Операція підтвердження справності терміналу має середній пріоритет. Зазвичай біля відділень банків є термінали, що обслуговуються банком, для того, щоб користувачі були впевнені в справності певного банкомату їх необхідно перевіряти та підтверджувати справність.

3.17.2. Причинно – наслідкові зв’язки.

Користувач Наслідки
Користувач натискає на пункт меню “ Підтвердити перевірку терміналу ”. Система автоматично оновлює дані про час перевірки терміналу, що підведений до банку.  

 

3.17.3. Функціональні вимоги.

В разі коли трапляється помила обробки запиту система повідомляє користувачу про невдалу операцію.

 

3.18. Перегляд історії записів

3.17.1. Опис і пріоритет.

Операція перегляду історії записів має середній пріоритет. В базі даних міститься саме відео, дата та години зйомки, зазначається ПІБ охоронця, касирів а також опис.

3.17.2. Причинно – наслідкові зв’язки.

Користувач Наслідки
Користувач натискає на підпункт меню “Переглянути записи” пункту “Керування базою відеозаписів”. Система відображає форму перегляду історії відеозаписів.
Користувач вибирає певний запис. Система відображає опис відео, та починає програвати відеозапис з можливістю прокрутки та зміни камери.

3.17.3. Функціональні вимоги.

В разі коли трапляється помила обробки запиту система повідомляє користувачу про невдалу операцію.

4. Вимоги до зовнішнього інтерфейсу.

4.1. Інтерфейси користувачів.

Стандартом для шрифтів буде Times New Roman 14 шрифт, значки повинні бути не надто яскравими, для піктограми рекомендовано використовувати два кольори. Назви кнопок повинні повністю відповідати виконуваній дії, рекомендовано, щоб кнопки містили як можна менше тексту, але були зрозумілими. Щодо послідовності вкладок пунктів меню в підсистемі для охоронців першим повинен йти пункт меню “Блокування дверей”, слідом пункт “Виклик наряду”, а після них пункти “Керування базою”, “Допомога” та “Вихід”. Для підсистеми клієнту колір повинен бути монохромним, рекомендується зелений. Між візуальним засобом перегляду інформації та блоком пошуку повинен існувати розмежувач. Прикладами інтерфейсу для користувача підсистеми клієнту можуть бути ілюстрації, що зображують головне вікно[Див. Рис.4.1], та вікно, що з’являється після натискання на пункт конфіденціальної інформації та введення правильного коду з смс – повідомлення[Див. Рис.4.2]. Також для прикладу наведено вигляд карти терміналів[Див. Рис.4.3], що з’являється після натискання на пункт “Карта терміналів”. Основними елементами управління в інтерфейсі є кнопки (на головній формі), на прототипі відображення депозитів повинен бути візуальний засіб для перегляду кредитів та випадаючі списки для пошуку.

 

Рис.4.1 – Головна форма додатку та форма конфіденційної інформації (справа)

 

Рис.4.2 – Форма перегляду депозитів

 

Рис.4.3 – Форма з картою терміналів

 

Також для прикладу наводиться вигляд головного вікна підсистеми для охоронців[Див. Рис.4.4]. Отже головне вікно додатку повинно включати заголовок “AvalSecurity”, головне меню, робочі області згідно до розділення форми, на кожній робочій області повинна бути можливість перемкнутись на іншу камеру (за допомогою лічильника чи випадаючого списку), кожна робоча область при отримуванні фокусу повинна мати можливість збільшення чи зменшення зображення, останнім елементом є піктограми вигляду,які дозволяють налаштувати вигляд робочих областей та їх кількість.

 

Рис.4.4 – Головна форма підсистеми для охоронців

 

4.2. Апаратні інтерфейси.

Типи пристроїв, що будуть використовуватись для взаємодії користувача з системою: підсистема для охоронців буде використовувати мишу та клавіатуру для отримання даних від користувача, а для виведення даних підключений до комп’ютеру монітор, а підсистема для клієнтів банку буде використовувати сенсорний екран для отримання даних від користувача, для виведення буде застосовуватись вбудованй екран. Ще однією особливістю є те, що додаток для охоронців буде взаємодіяти з автоматичними дверима при виборі пункту меню блокування дверей, також буде викликатися наряд фірми охорони, здійснення виклику відбувається стандартним чином, аналогом такої реалізації є червона кнопка в більшості банків, яку натискають при пограбуванні, з повторенням при невдалому виклику наряду. Для прикладу наведено діаграму розгортання, що відображає загальну топологію системи та фізичний взаємозв’язок між програмними та апаратними компонентами[Див.Рис.А2].

 

4.3. Програмні інтерфейси.

Як вже зазначалося вище для взаємодії підсистеми для клієнтів банку та бази даних буде використано SQLite, а для підсистеми для охоронців та бази даних буде використано SQL Compact 4.0. Необхідно зазначити, що додаток для клієнтів банку буде використовувати зовнішнє застосування, а саме “ЯндексКарти”, для того, щоб відобразити всі термінали та години їх роботи. Для прикладу наведено діаграму компонентів, що здійснює перехід від логічного зображення системи до реалізації проекту в формі програмного коду[Див.Рис.А3].

 

4.4. Інтерфейси передачі інформації.

Для передачі даних будуть використовуватись протоколи TCP/IP та SSH. Підсистема для охоронців також буде використовувати канальне шифрування (коли дані шифруються/дешифруються на кожному комутаторі), в той час як додаток для клієнтів банку буде здійснювати тільки шифрування на прикладному рівні (між додатками), через те, що неможливо наперед передбачити з якої мережі буде під’єднаний користувач. Для прикладу наведено діаграму потоків даних яка надасть змогу переглянути вхідні та вихідні дані процесів [Див.Рис.А4].

 

5. Інші не функціональні вимоги.

5.1. Вимоги до продуктивності.

Кількість одночасно підтримуваних користувачів (підсистеми для клієнтів банку) повинна складати не менше п’яти тисяч. Тип інформації, що буде оброблюватись в підсистемі для клієнтів банку буде текстовим, тобто це наприклад таблиця з заповненими полями про депозити, кредити або іншу інформацію, також це може бути карта з терміналами (при відкритті якої необхідно визначати місцезнаходження клієнту). Інформація, що буде оброблюватись в підсистеми для охоронців буде переважно відеозаписами, з невеликою долею тексту (наприклад при додаванні нового запису до БД), отже обсяг інформації в підсистемі буде досить великий якщо враховувати, що може відбуватись передача відео одразу з декількох відеокамер. Для підсистеми клієнтів банку необхідно, щоб запити оброблювалися не більше 15 секунд. Для підсистеми охоронців затримка між відеозаписом та камерою не повинна перевищувати 5 секунд.

 

5.2. Проектні обмеження.

До обмежень, що накладаються апаратними складовими, є обмеження можливостей апаратних систем користувачів, так наприклад підсистема для охоронців повинна добре працювати на тих процесорах, що зазначені в пункті 2.4.




Поделиться с друзьями:


Дата добавления: 2015-05-24; Просмотров: 585; Нарушение авторских прав?; Мы поможем в написании вашей работы!


Нам важно ваше мнение! Был ли полезен опубликованный материал? Да | Нет



studopedia.su - Студопедия (2013 - 2024) год. Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав! Последнее добавление




Генерация страницы за: 0.016 сек.