- •1.Введення.
- •1.1. Призначення.
- •1.2. Угоди прийняті в документах.
- •1.3. Передбачувана аудиторія і рекомендації з читання.
- •1.4. Границі проекту.
- •1.5. Посилання.
- •2.Загальний опис.
- •2.1.Загальний погляд на продукт.
- •2.5.Обмеження, правила та стандарти.
- •2.6.Документація для користувачів.
- •2.3.Класи і характеристики користувачів.
- •2.7.Припущення і залежності.
- •Функціональні вимоги.
- •Причинно - наслідкові зв’язки.
- •Функціональні вимоги.
- •Переглядання кредитів.
- •3.4.1. Опис і пріоритет.
- •Причинно - наслідкові зв’язки.
- •3.11.3. Функціональні вимоги.
- •3.17.3. Функціональні вимоги.
- •Вимоги до зовнішнього інтерфейсу.
- •4.1. Інтерфейси користувачів.
- •Апаратні інтерфейси.
- •Програмні інтерфейси.
- •Інтерфейси передачі інформації.
- •Інші не функціональні вимоги.
- •5.1. Вимоги до продуктивності.
- •Проектні обмеження.
- •Атрибути системи.
Програмні інтерфейси.
Як вже зазначалося вище для взаємодії підсистеми для клієнтів банку та бази даних буде використано SQLite, а для підсистеми для охоронців та бази даних буде використано SQL Compact 4.0. Необхідно зазначити, що додаток для клієнтів банку буде використовувати зовнішнє застосування, а саме “ЯндексКарти”, для того, щоб відобразити всі термінали та години їх роботи. Для прикладу наведено діаграму компонентів, що здійснює перехід від логічного зображення системи до реалізації проекту в формі програмного коду[Див.Рис.А3].
Інтерфейси передачі інформації.
Для передачі даних будуть використовуватись протоколи TCP/IP та SSH. Підсистема для охоронців також буде використовувати канальне шифрування (коли дані шифруються/дешифруються на кожному комутаторі), в той час як додаток для клієнтів банку буде здійснювати тільки шифрування на прикладному рівні (між додатками), через те, що неможливо наперед передбачити з якої мережі буде під’єднаний користувач. Для прикладу наведено діаграму потоків даних яка надасть змогу переглянути вхідні та вихідні дані процесів [Див.Рис.А4].
Інші не функціональні вимоги.
5.1. Вимоги до продуктивності.
Кількість одночасно підтримуваних користувачів (підсистеми для клієнтів банку) повинна складати не менше п’яти тисяч. Тип інформації, що буде оброблюватись в підсистемі для клієнтів банку буде текстовим, тобто це наприклад таблиця з заповненими полями про депозити, кредити або іншу інформацію, також це може бути карта з терміналами (при відкритті якої необхідно визначати місцезнаходження клієнту). Інформація, що буде оброблюватись в підсистеми для охоронців буде переважно відеозаписами, з невеликою долею тексту (наприклад при додаванні нового запису до БД), отже обсяг інформації в підсистемі буде досить великий якщо враховувати, що може відбуватись передача відео одразу з декількох відеокамер. Для підсистеми клієнтів банку необхідно, щоб запити оброблювалися не більше 15 секунд. Для підсистеми охоронців затримка між відеозаписом та камерою не повинна перевищувати 5 секунд.
Проектні обмеження.
До обмежень, що накладаються апаратними складовими, є обмеження можливостей апаратних систем користувачів, так наприклад підсистема для охоронців повинна добре працювати на тих процесорах, що зазначені в пункті 2.4.
Атрибути системи.
А)Система повинна бути надійною, тобто безвідмовною, а для цього необхідно, щоб додаток мав якомога менше помилок, а також, щоб система мала велику кількість виключних ситуацій які оброблюються, щоб не було частин коду не покритих перевіркою. Також повинно бути 100% покриття тестами всього програмного коду, щоб уникнути помилок.
Б)Доступність. Прикладом контрольної точки або відновлення можна вважати карту, тому що в випадку коли немає зв’язку з мережею або є певні збої зі з’єднанням відбувається завантаження карти, що була збережена перед оновленням. Також в системі передбачено
В)Безпека. Чинником, що захищає програмне забезпечення від зловмисного доступу є шифрування, так наприклад в підсистемі для охоронців застосовується шифрування на канальному рівні, що захистить відеозаписи з банку.
Г)Супроводжуваність. Весь програмний код додатку повинен бути повністю коментований, тобто коментарі повинні бути перед кожним методом, якщо необхідно, можливі пояснення всередині методів, а також перед класом.
Д)Перенесення. Підсистема для клієнтів банку повинна мати можливість легко переноситись на Windows.
Додаток А
Рис.А1 – Діаграма використання
Рис.А2 – Діаграма розгортання
Рис.А3 – Діаграма компонентів
Рис.А4 – Діаграма потоків даних нульового рівня
Додаток В
Банк — кредитно-фінансова установа, яка здійснює грошові розрахунки, акумулює грошові кошти та інші цінності, надає кредити та здійснює послуги за фінансовими операціями.
Банківська безпека — це стан стійкої життєдіяльності, за якого забезпечуються реалізація основних інтересів, пріоритетних цілей банків, захист від зовнішніх і внутрішніх дестабілізуючих факторів незалежно від умов їх функціонування.
База даних (скорочено — БД) — впорядкований набір логічно взаємопов'язаних даних, що використовуються спільно та призначені для задоволення інформаційних потреб користувачів.
Інформаційна безпека — формування інформаційних ресурсів банку та організація гарантованого їх захисту. Досягається створенням у банку системи збору та обробки інформації, проведенням відповідних заходів шодо їх зберігання та розподілу, визначенням категорій і статусу банківської інформації, порядку і правил доступу до неї, дотриманням усіма працівниками, клієнтами та акціонерами банку норм і правил роботи з банківською інформацією.
Оперативна пам'ять ( Random Access Memory, дослівно — пам'ять з довільним доступом, первинна пам'ять) — пам'ять ЕОМ, призначена для зберігання коду та даних програм під час їх виконання.
Постійний запам'ятовувальний пристрій (ПЗП)( ROM - Read Only Memory) — енергонезалежна пам'ять, з якої може проводитись тільки зчитування даних.
Автоматизована система (АС) (automated system) — сукупність керованого об'єкта й автоматичних керуючих пристроїв, у якій частину функцій керування виконує людина.
Висновок: Під час виконання лабораторної роботи розробив специфікацію вимог до розроблюваної системи застосовуючи стандартну структуру її створення.
