залежностей між ними, в третіх дозволяє зв'язати графічну форму подання з текстовою. Модель включає акторів і ВІ, показує, як система взаємодіє з акторами і що вона робить в кожному ВІ.
В· Специфікація вимог (Software Requirements Specification) - основний документ, використовуваний при проектуванні і розробці ПС. Вона включає модель вимог і додаткові специфікації, які представляють собою текстовий опис вимог до кінцевого продукту, але не до процесу його розробки і не містять деталей реалізації вимог.
В· Прототип користувальницького інтерфейсу забезпечує візуальне представлення інтерфейсу користувача з ПС.
В· Словник - текстовий документ, що містить визначення основних понять і термінів, які повинні однаково розумітися замовником і розробником. Джерелами даних для створення перерахованих артефактів можуть, зокрема, служити артефакти, створені при бізнес-аналізі (див. статтю В«RUP. Обстеження організації (Бізнес-аналіз) В». <В
Процес
В
У процесі аналізу і моделювання вимог можна виділити кілька основних етапів (див. рис.1).
В
Рис.1 Технологічний процес управління вимогами.
Початок аналізу.
Спочатку слід визначити коло зацікавлених осіб. Якщо проводився бізнес-аналіз, то вони вже відомі. Збираються побажання зацікавлених осіб до майбутньої ПС. Ці побажання аналізуються, визначаються основні властивості і кордону ПС, досягаються угоди про те, які проблеми мають бути вирішені.
Результати. Повинен бути складений документ В«Попередня угодаВ», який буде відправною точкою для виконання всіх наступних робіт. На цьому етапі починається створення глосарію. Якщо глосарій був створений при бізнес-аналізі, то він використовується як відправною документ. Оскільки тут мова йде про виявлення вимог до ПС, в глосарій можуть включатися терміни, пов'язані з реалізації (наприклад, броузер, сервер та ін.) Визначення цих термінів повинні сприяти кращому розумінню системи зацікавленими особами.
Побудова моделі вимог
Ця робота передбачає виявлення акторів, ВІ і взаємодій між ними. Якщо було проведено обстеження організації, то в якості джерела для визначення акторів і ВІ може служити бізнес-модель.
Якщо число ВІ занадто велике, то для спрощення читабельності і підтримки моделі доцільно розділити їх по пакетах. Це також спрощує розуміння моделі і розподіл відповідальності шляхом призначення розробників, відповідальних за пакети ВІ. Пакети дозволяють організувати ієрархію вимог. Верхній рівень ієрархії зазвичай визначається, виходячи з основних видів діяльності організації. Якщо був виконаний бізнес-аналіз, то основні види діяльності вже представлені в бізнес-моделі у вигляді пакетів, і вони можуть бути просто скопійовані в модель вимог. Пакетів верхнього рівня не повинно бути багато. Доцільно виділити пакет адміністрування і пакет допоміжних дій, і 2 - 4 пакети, основних видів діяльності. У свою чергу, пакети верхнього рівня можуть включати пакети наступного рівня і т. д.
Коли ви окресліть вихідну модель вимог, ви повинні уважно перевірити, що вона покриває усі заявки зацікавлених осіб, представлені в документі В«Попередня угодаВ».
Деталізація моделі вимог
Цілі даної діяльності:
В· витяг з ВІ характерних фрагментів, які можуть розглядатися як окремі абстрактні ВІ. Прикладами таких частин можуть бути спільні фрагменти, необов'язкові фрагменти і виключення;
В· виявлення нових абстрактних акторів, які грають ролі, колективні кількома акторами;
В· реструктуризація моделі вимог;
В· детальне опис потоків подій для ВІ;
В· завдання пріоритетів ВІ.
Коли ви просунетеся досить далеко, ви можете захотіти переглянути вихідну модель, оскільки існує тенденція вводити на перших порах занадто багато акторів. Слід пам'ятати, що будь-яка модифікація акторів може викликати істотні зміни в системному інтерфейсі і поведінці.
Деталізація ВІ передбачає розробку діаграм послідовностей, кооперацій або діяльностей, описують виконання основної та допоміжних робіт у конкретному ВІ.
Визначення пріоритетів означає, що всі ВІ ранжуються на критичні, важливі та допоміжні. Критичні ВІ, представляють основну системну функціональність або мають істотне архітектурне значення. Важливі ВІ визначають такі системні функції, як збір статистики, складання звітів, контроль і функціональне тестування. Якщо вони не реалізовані, то система може виконувати своє призначення, але зі значно гіршою якістю сервісу. Допоміжні ВІ визначають зручність використання ПС. p> Складання додаткових специфікацій
Додаткові специфікації являють собою текстові описи вимог. Вони доповнюють модель вимог і поряд з нею включаються в підсумковий документ - специфікацію вимог до ПС. Слід чітко розуміти, що кожен ВІ є деяке ієрархічне вимога до ПС. Дуже важливо, щоб між моделлю вимог і описом вимог в специфікації було точну відпо...
