42.Чинники успіху стратегічного етапу?

• Ефективність роботи. Будь-які затримки в роботі на цьому етапі можуть призвести до втрати контракту. Тому вимагається малу кількість людей, які можуть виконати роботу за короткий проміжок часу.

• Контакт з ключовими представниками клієнта. Невелике неприйняття методу може закінчитися невдачею.

• Розуміння всієї системи. Неправильно концентруватися на деталях або фрагментах системи. Розуміння складності всієї системи неможливе і може призвести до нерозуміння її найскладніших частин.

43.Результати стратегічного етапу?

Користувач отримує звіт, який містить в собі:

• мета проекту,

• область дії проекту,

• опис зовнішніх систем,

• формулювання основних вимог,

• модель системи,

• пропоноване рішення,

• попередній графік роботи.

Також отримує звіт про оцінку рішень, який обгрунтовує вибір один з них, список потрібних ресурсів: персонал, апаратура, ПЗ, офіси і т.д., стандартні визначення, список аналізів.

44.Причини складності формулювання вимог до системи?

Існує багато причин складності цього етапу:

• клієнт зазвичай не знає, як досягти мети,

• існує багато шляхів для рішення завдання,

• великі системи часто використовуються безліччю користувачів, і вони протирічать один одному,

• користувачі можуть спілкуватися, використовуючи різні словники,

• люди, що робили замовлення, і люди, що використовуватимуть систему, можуть бути різними. Люди, що роблять замовлення, можуть не розуміти до кінця всіх потреб.

45. Рівні опису вимог?

Визначення вимог - це форма основної загальної мови, що використовується для підготовчого спілкування з клієнтами.

Задоволення вимог - це структурована форма ясності вимог, що використовує загальну мову і базові структури.

Специфікація ПЗ - формальний опис вимог.

• Формальна специфікація припускає деталізовану декомпозицію вимог (використовуючи якусь форму) в секції, які можна буде легко зрозуміти і які не викликатимуть невизначеності.

46.Основні вимоги до опису вимог по системі?

Хороший опис вимог повинен задовольняти наступні вимоги:

• бути повним і послідовним,

• описувати зовнішній режим роботи,

• описувати обмеження системи,

• бути доступним для модифікування,

• брати до уваги можливі майбутні зміни,

• описувати швидкодію системи в екстремальних або небажаних ситуаціях.

47.У чому полягає правильність формулювання вимог до системи користувачем?

Вимоги повинні бути представлені критичним порівнянням з існуючим ПЗ і прототипами. Угода повинна бути складена між розробниками і користувачами. Знання і досвід розробників повинен бути втілені у проект і зрозумілими для замовника.

Вимоги користувача повинні бути:

• зрозумілими,

• унікальними,

• такими, щбо їх можна було перевірити,

• точними,

• реалістичними,

• виконуваними.

48.Методи ідентифікації вимог? Зустрічі і огляди (зустрічі повинні бути підготовлені у формі списку питань від різних сторін, що відносяться до даного проекти. Вони повинні проходити серед презентабельної групи користувачів, які прагнуть схвалення проекту).

• Вивчення існуючого ПЗ (часто нове ПЗ замінює старе. Вивчення повинне визначати слабкі і сильні сторони старого ПЗ і погоджувати з ними нові вимоги, якщо система повинна бути частиною старої).

• Вивчення досяжності (повинні бути визначені реалістичні цілі і методи).

• Прототипування (проектування прототипів систем з меншим об'ємом і спрощеним інтерфейсом).