начення для всього життєвого циклу розробки програмного продукту. На підставі SRS досягається згода між замовниками та виробниками програмного продукту. У специфікації SRS повністю описані функції, які повинен виконувати розроблюваний програмний продукт. Дозволяє потенційним користувачам визначити ступінь відповідності продукту їх потребам, а також шляхи модифікації продукту для того, щоб він був максимально корисний у вирішенні їхніх завдань.
За типом опис вимог здійснюється за наступними категоріями, які описані і представлені в таблиці 1.2.
Таблиця 1.2 - Категорії опису вимог
КатегоріяОпісаніеFТребованія до функцій (завдань), виконуваним сістемойCТребованія до системи в цілому; PТребованія до представленіюRТребованія, що визначають ризики, яким має бути приділено основну увагу при розробці системи
Категорія F (функціональні вимоги). Функціональні вимоги до системи визначають, дії системи, які вона повинна виконувати. Функціональні вимоги реалізуються через функції системи. Під функцією АС мається на увазі сукупність дій АС, спрямована на досягнення певної мети або аспект певної поведінки системи, а під завданням - функція або частина функції АС, що представляє собою формалізовану сукупність автоматичних дій, виконання яких призводить до результату заданого виду.
Опис функціональних вимог зображено в таблиці 1.3.
Таблиця 1.3 - Функціональні вимоги
ТребованіеТіпОпісаніеАвторізація пользователейFСістема повинна здійснювати авторизацію пользователей.Загрузка необхідних компонентів сістемиFСістема повинна завантажувати свої компоненти, залежно від типу співробітника, відділення до якого він належить. Його функцій і властивостей.
Друга категорія в описі вимог є категорія C (системні вимоги). Системні вимоги - деталізований опис системних функцій і обмежень. Описи системних вимог представлені в таблиці 1.4.
Таблиця 1.4 - Системні вимоги
ТребованіеТіпОпісаніе.АрхітектураCСервер даних (1C) .Язик программірованіяC1CОпераціонная сістемаC Windows XP.
Третя категорія - це вимоги до подання (Р). Вимоги до подання описують формування вимог до інтерфейсу програмного забезпечення для замовника. Опису вимог до подання зображені в таблиці 1.5.
Таблиця 1.5 - Вимоги до подання
ТребованіеТіпОпісаніе.Общій інтерфейсPОн не повинен бути перевантажений, простий для поніманія.Обязательние поля вводаPОбязательние поля для введення повинні бути виділені.
Четвертої категорією є вимоги до ризиків (R). Дана категорія вимог спрямована на те, щоб максимально поліпшити роботу користувача тобто зменшити ризик некоректного внесення даних в систему. Опису вимог до ризиків представлені в таблиці 1.6.
Таблиця 1.6 - Вимоги до ризиків
ТребованіеТіпОпісаніеСоответствіе полів з занесеними данниміRПредоставленние поля повинні відповідати типу введення данних.Результати пошуку даннихRПолное відповідність реальним данним.Сохранность даннихRСістема повинна забезпечувати схоронність даних.
Найважливішим документом на даному етапі, проектування є специфікація вимог до програмного забезпечення. Специфікація вимог є основним документом, що визначає вимоги та порядок створення ІС. Даний документ повинен містити склад і найменування комплексів задач, вимоги щодо зміни організаційної структури, складу забезпечують підсистем.
1.6 Атестація вимог
Атестація повинна продемонструвати, що вимоги дійсно визначають ту систему, яку хоче мати замовник. Перевірка вимог важлива, так як помилки в специфікації вимог можуть призвести до переробці системи і більших витрат, якщо будуть виявлені під час розробки системи або після введення її в експлуатацію.
Для атестації вимог буде використаний метод прототипування. У цьому випадку кінцевим користувачам і замовнику демонструється якийсь прототип системи.
Прототип головного меню представлений на малюнку 1.6.
Малюнок 1.6 - Прототип головного меню
1.7 Вибір методології проектування інформаційної системи
Існує дві базових методології проектування інформаційних систем: структурний і об'єктно-орієнтований аналіз.
Сутність структурного підходу до розробки інформаційної системи полягає в її декомпозиції на а?? томатізіруемие функції: система розбивається на функціональні підсистеми, які в свою чергу діляться на підфункції, що підрозділяються на завдання і так далі. Процес розбиття триває аж до конкретних ...
