МІНІСТЕРСТВО ОСВІТИ І НАУКИ УКРАЇНИ НАЦІОНАЛЬНИЙ УНІВЕРСИТЕТ «ЛЬВІВСЬКА ПОЛІТЕХНІКА» ІНСТИТУТ КОМП’ЮТЕРНИХ НАУК ТА ІНФОРМАЦІЙНИХ ТЕХНОЛОГІЙ КАФЕДРА АВТОМАТИЗОВАНИХ СИСТЕМ УПРАВЛІННЯ
Звіт до лабораторної роботи №1 з дисципліни «Проектування інформаційних систем» на тему: «Формулювання вимог до інформаційної системи. Розробка технічного завдання» ЛЬВІВ 2018 Лабораторна робота №1 Тема роботи: Ознайомлення із фреймворками для побудови інформаційної системи. Формулювання вимог до інформаційної системи. Розробка технічного завдання. Мета роботи: Відповідно до вивчених фреймворків побудови ІС, проаналізувати та розробити архітектуру ІС для обраної предметної області. Сформулювати вимоги для розроблюваної ІС та оформити їх за існуючими стандартами. 1. Теоретичні відомості Способів формулювання вимог є кілька:  документація, в якій використовується чітко структурований і акуратно використовуваний природний мову;  графічні моделі, що ілюструють процеси перетворення, стану системи і їх зміни, взаємозв’язки даних, а також логічні потоки тощо .;  формальні специфікації, де вимоги визначені за допомогою математично точних, формальних логічних мов. Специфікація вимог до ПЗ Специфікацію вимог в різних компаніях називають по-різному, при цьому в цих компаніях назви не використовуються однаково. Специфікацію вимог до ПЗ іноді називають документом бізнес-вимог, функціональної специфікації, специфікацією продукту або просто документом про вимоги. Оскільки «специфікація вимог до ПЗ» є галузевим стандартом, ми називаємо її саме так (ISO / IEC / IEEE 2011). У специфікації вимог до ПЗ вказуються функції і можливості, якими має володіти ПЗ, а також необхідні обмеження. Вона повинна містити досить докладний опис поведінки системи за різних умовах, а також необхідні якості системи, такі як продуктивність, безпеку і зручність використання. Специфікація вимог є основою для подальшого планування, дизайну і кодування, а також базою для тестування користувальницької документації. Однак вона не повинна містити подробиці дизайну, проектування, тестування і управління проектом за винятком відомих обмежень дизайну і реалізації. Навіть тим, хто працює над проектами гнучкої розробки потрібна та чи інша інформація, що міститься в хорошій специфікації вимог до ПЗ. Зазвичай такі розробники не збирають всю цю інформацію у вигляді цілісного матеріалу, але шаблон специфікацій вимог служить зручним нагадуванням, які знання може знадобитися зібрати. Вимоги до найменування У кожного вимоги повинен бути унікальний і незмінний ідентифікатор. Це дозволить вам посилатися на певні вимоги в запиті на зміни, в хронології змін, в перехресних посиланнях або матриці зв'язків вимог. При цьому також спрощується повторне використання вимог в декількох проектах. Унікальна ідентифікація вимог спрощує взаємодію між членами команди під час обговорення вимог на зустрічі з взаєморецензування вимог. Прості нумеровані або маркіровані списки для цих цілей не використовуються. 1.Нумерація за порядком Найпростіший спосіб - дати кожному вимогу унікальний порядковий номер, наприклад UR-9 або FR-26. Серійні засоби управління вимогами присвоюють такий ідентифікатор, коли користувач додає нову вимогу до бази даних. Префікс позначає тип вимоги, наприклад FR означає «functional requirement» (тобто «функціональне вимога»). При видаленні вимоги номер повторно не використовується, тому читачеві не доведеться плутатися між вихідною вимогою FR-26 або новою вимогою FR-26. 2.Ієрархічна нумерація Це найбільш поширений спосіб. Якщо функціональні вимоги наводяться в розділі 3.2 специфікації, то все їх номери будуть починатися з 3.2. Чим більше цифр, тим більше рівень деталізації вимоги, так що відразу зрозуміло, що 3.2.4.3 є нащадком по відношенню до 3.2.4. Це спосіб відрізняється простотою, компактністю і очевидністю. Ваш текстовий редактор, швидше за все зможе призначати номера автоматично. Якщо розробнику не вистачає інформації, він не завжди звертається для вирішення проблеми до ...