Читайте также:
|
Документ SRS – однозначний і повний результат процесу специфікації інформаційної системи. Грамотно складений документ SRS надає наступні основні можливості:
Для замовника: точний опис того, що він хоче отримати
Для розробника: однозначне тлумачення і розуміння того, що хоче отримати замовник.
Контроль версій - це важливий аспект управління специфікаціями вимог та іншими проектними документами. Кожній версії слід присвоїти унікальний ідентифікатор. У кожного члена команди повинен бути доступ до поточної
версії вимог, а зміни необхідно ясно документувати і передавати всім зацікавленим сторонам. Щоб мінімізувати плутанину, конфлікти і нерозуміння, потрібно призначити право поновлення вимог строго певним особам і переконатися, що ідентифікатор версії змінюється при кожній зміні вимоги.
Кожна версія документу повинна містити історію переробки, де вказуються внесені зміни, дата кожної з них, особу, що внесла зміни, а також причина.
Найпростіший механізм управління версіями - іменувати вручну кожну версію специфікації вимог до ПЗ згідно з угодою.
Спроба розрізняти версії документів за датою зміни часто призводить до помилок і плутанини, її не рекомендовано використовувати. Деякі команди доволі успішно застосовували таку угоду: перша версія будь-якого нового документа називається «Версія 1.0, начерк 1». Наступна називається «Версія 1.0, начерк 2». Автор послідовно збільшує номер начерку при кожній зміні і так до тих пір, поки документ не буде затверджена базова версія документа. Тоді назва змінюється на «Версія 1.0, затверджена». Наступні версії називаються «Версія 1.1, начерк 1» при невеликій зміні або «Версія 2.0, начерк 1» при значній зміні. При застосуванні цієї схеми ясно розрізняються начерки й версії базового документа, однак необхідно дотримуватися суворий порядок у веденні документації.
Варто додавати номер версії до назви кожної окремої вимоги і послідовно збільшувати її при модифікації.
Для документування версій використовуються текстові процесори, електронні таблиці.
Найбільш надійний метод контролю версій полягає в зберіганні вимог у базі даних комерційного засоби управління вимогами. Ці засоби відстежують повну історію змін вимог, що особливо важливо, якщо потрібно
повернутися до більш ранньої версії вимоги. Такий засіб дозволяє вносити коментарі, де можна розумно обґрунтувати рішення про додавання, зміну або видалення вимоги; ці коментарі можуть виявитися корисними при необхідності обговорення вимоги у майбутньому.
Специфікація вимог до ПЗ – закінчений опис поведінки системи, яку потрібно розробити.
Специфікація вимог до ПЗ інколи називають функціональною специфікацією, специфікацією продукту, документом про вимоги і системну специфікацію. В цьому документі точно вказуються функції і можливості, якими повинно володіти ПЗ, а також необхідні обмеження. Саме на основі спеки складаються плани розробки проекту і написання коду, а також особливості тестування системи і користувальницької документації. Вона повинна містити опис поведінки системи при різноманітних умовах. Деталі дизайну, збірки, тестування або управління проектом, зафіксовані в спеці, не повинні суперечити обмеженням розробки і розгортання.
Специфікація вимог до ПЗ необхідна різним учасникам проекту:
9. Клієнтам – відділ маркетингу і спеціалісти з продажу хочуть мати уявлення про кінцевий продукт
10. Менеджерам проекту – за даними спеки розраховуються графіки, витрати і необхідні ресурси
11. Команді розробників ПЗ – отримує представлення про створюваний продукт
12. Групі тестування – складає плати тестування, варіанти використання і процедури.
13. Спеціалістам по обслуговуванню і підтримки – отримують представлення про функціональності кожної складової частини продукту
14. Укладачам документації – створюють керівництва для користувачів і вікна довідки на основі специфікації вимог до ПЗ і дизайну користувацького інтерфейсу
15. Спеціалістам, що відповідають за інструктування (навчання) персоналу – необхідна спека вимог до ПЗ і документація для користувачів для розробки навчальних матеріалів
16. Персоналу, що займається юридичною стороною продукту – перевіряє, чи відповідають вимоги до продукту існуючим законам і постановам.
Основні питання, що розглядаються SRS:
11. Функціональні можливості. Які передбачувані функції ПЗ?
12. Зовнішні інтерфейси. Як ПЗ взаємодії з користувачем, апаратними засобами системи, іншими апаратними засобами і іншим ПЗ?
13. Продуктивність (робочі характеристики). Яка швидкодія, досяжність, час відгуку, час відновлення різних функцій ПЗ?
14. Атрибути. Яка мобільність, правильність, зручність супроводження, захищеність ПЗ і інші критерії?
15. Можливі проектні обмеження, що накладаються на реалізацію. Чи існують необхідні стандарти на ефективні мові реалізації, політика по збереженню цілісності БД, обмеження ресурсів, операційне середовище (ща) і т.д.?
Требования к внешним интерфейсам
a. Интерфейсы пользователя (UX)
b. Программные интерфейсы
c. Интерфейсы оборудования
d. Интерфейсы связи и коммуникации
Дата добавления: 2015-07-11; просмотров: 118 | Нарушение авторских прав