Студопедия

КАТЕГОРИИ:


Архитектура-(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)

Обмеження, правила та стандарти




Автоматичне шифрування.

1. При всіх діалогах з користувачем система автоматично шифрує запити та відповіді на них, а також дані користувача.

Додаток для охоронців:

1. Система передбачає керування відеоспостереженням за банком.

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

3. Система передбачає автоматичний виклик наряду.

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

2.3.Класи і характеристики користувачів.

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

2.4.Операційне середовище.

Географічне місцеположення користувачів передбачається по всій Україні, а основна частина серверів та баз даних повинна розміщуватись в Києві. Система повинна бути сумісна для різних версій платформи Android. Середовище в якому буде використовуватись підсистема для охоронців банку:

· Процесор: Intel Pentium IV 1.70GHz, також система повинна функціонувати на Intel Pentium T2370 1,73 ГГц, Intel Pentium T2390 1,86 ГГц, Intel Celeron E1500 2,20 ГГц, Intel Celeron E1600 2,40 ГГц, Intel Core i5 760 2.80 ГГц.

· ОЗП: 512МБ – 8ГБ.

· ПЗП: 20МБ місця на жорсткому диску для програми та додатково приблизно 400 МБ для встановлення додаткового програмного забезпечення за необхідності.

· Графічний адаптер сумісний з операційними системами сімейства Microsoft Windows.

· Пристрої вводу: клавіатура, миша.

· Операційна система: Microsoft Windows XP Service Pack 3, Windows 7, Windows 8,Windows 8.1.

· Розповсюджувані пакети: Microsoft NET Framework 4.0 Client, Microsft Visual C++ 2010 Redistribute, Microsoft SQL Server Compact 4.0.

Середовище в якому буде використовуватись підсистема для клієнтів:

· ОЗП: 512МБ-2ГБ.

· ПЗП: 100-400МБ вільного місця для програми та додаткового програмного забезпечення за необхідності.

· Спосіб взаємодії: Сенсорний екран(транзисторний чи ємкісний).

· Операційна система: Android версії 3.х(Honeycomb), 4.0(Ice Ceram Sandwich), 4.1,4.2,4.3(JellyBean),4.4(KitKat).

Обмеженням, що накладається на розробку є вибір середовища програмування, в даному випадку це повинна бути Visual Studio 2012. Обмеженням щодо мови програмування буде те, що програмувати необхідно на мові програмування C#, але дозволяється робити асемблерні вставки для покращення ефективності коду. Платформа, що буде використовуватись Net Framework 4.0. Основним обмеженням, що буде накладатись на бази даних, буде використання Sql Server Compact 4.0, для підсистеми охоронців, а також SQLite для користувачів підсистеми клієнтів. Обмеження та сумісність щодо апаратних компонент наведена в пункті 2.4.

2.6.Документація для користувачів.

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

2.7.Припущення і залежності.

Зовнішніми факторами від яких залежить система можуть бути нова версія операційної системи Windows 10 (для підсистеми охоронців) та нова версія для Android пристроїв 5.0(Lolipop), для підсистеми клієнтів. Також одним з факторів залежності є версія SQLite оскільки з часом підтримка певної версії може бути припинена. Система повинна бути доставлена в заданий термін, щоб запобігти виходу нових законопроектів, що можуть вплинути на функції системи, термін для повної розробки закінчується 30 червня 2015 року.

 

3.Функції системи.

3.1. Внесення обмежень на вхід.

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

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

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

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

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

При натисненні на кнопку “внести пристрій”, якщо аналогічний пристрій вже існує в переліку вибраних пристроїв, тобто обраний повторно, то на екрані користувача повинна з’являтися вспиваюча підказка чи вікно з повідомленням. Повідомлення повинно бути наступним: “Вибраний пристрій вже занесено до вибраного вами списку на обмеження”. В випадку коли користувач вибрав поле з секретним питанням, але залишив його пустим система повинна підсвічувати поле червоним та всередині повинно відображатися повідомлення про те, що поле обов’язкове для заповнення. Якщо клієнт натискає на кнопку “Зберегти налаштування”, але перевірки відповіді на секретне питання була невдалою (тобто відповідь не правильна), поле відповіді стає пустим, підсвічується червоним та всередині міститься контекстний текст, або відображається вспливаюча підказка, що відповідь неправильна. В разі помилки при транзакції, що оновлює дані користувача, а саме пристроїв з яких можна здійснювати вхід до системи, відбувається закриття форми налаштування обмеження, а також виведення користувачу повідомлення, що дана операція була неуспішною, та прохання повторити дану операцію пізніше.

 

3.2. Перегляд історії активності.

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

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

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

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

 

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

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

 

3.3. Перегляд історії операцій.

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

Операція перегляду історії операцій має високий пріоритет. Дана функція передбачає відображення історії всіх операцій, надходжень на рахунок та списань з нього. Кожне поле містить дату та час виконання операції, суму та назву умовних одиниць. Також можна переглянути більш конкретну інформацію про дію натиснувши на потрібну операцію, в додатковій інформації вказується отримувач(відправник) коштів та описання операції (наприклад на поповнення рахунку мобільного телефону 380…). Перед отриманням інформації користувачу необхідно здійснити вхід до системи та підтвердити особу за смс-повідомленням.

 

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

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

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

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

 

3.4. Переглядання кредитів.

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

Операція перегляду кредиту має високий пріоритет. Даний пункт передбачає функцію при зверненні до якої користувач отримує повний перелік здійснених платежів по кредиту, загальну суму кредиту яку необхідно погасити, та суму для погашення на даний місяць. Також користувач може проглянути історію зміни реквізитів кредиту(суми кредиту) та з чого саме складається сума кредиту (наприклад відсоток, сама сума, додаткові послуги). Перед отриманням інформації користувачу необхідно здійснити вхід до системи та підтвердити особу за смс-повідомленням (підтвердження особи за смс-повідомленням описано в пункті 3.3, що відображає функцію перегляду історії операцій, тому далі воно повторно не розглядається).

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

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

 

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

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

 

3.5. Переглядання депозитів.

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

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

 

 

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

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

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

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

 




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


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


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



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




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