
- •1Поняття вимог до пз. Рівні вимог до пз.
- •1.1 Вимоги до програмного забезпечення
- •2Функціональні вимоги.2
- •9.2 Опитування потенційних користувачів і дискусії з ними4
- •9.2.1.Документи, де описаний вже працюючий або конкуруючий продукт5
- •9.2.2.Звіти про помилки і претензії до можливостей працюючої системи6
- •9.2.3.Маркетингові дослідження та опитування користувачів7
- •9.2.4.Спостереження за користувачами на робочих місцях8
- •9.2.5.Сценарій аналізу задач користувачів9
- •10Варіанти використання і сценарії використання
- •11Бізнес-правила і вимоги. Документування бізнес-правил
- •11.1 Бізнес-правила і вимоги
- •11.2 Документування бізнес-правил
- •20Стан вимог. Основні принципи контролю змін в пз. Шаблон опису контролю змін
- •20.1 Стан вимог
- •20.2 Основні принципи контролю змін в пз.
- •20.3 Шаблон опису контролю змін.
- •24.2 Огляд та переваги їх використання
9.2 Опитування потенційних користувачів і дискусії з ними4
Самий очевидний спосіб з'ясувати потреби потенційних користувачів нового програмного продукту – опитати їх. Потрібно вибрати тямущих представників користувалей і з'ясувати, що ж їм дійсно необхідно.
9.2.1.Документи, де описаний вже працюючий або конкуруючий продукт5
Ці документи можуть також містити корпоративні або галузеві стандарти, яких необхідно дотримуватися, а також постанови та закони, яким повинен відповідати продукт, Стануть в нагоді і опису вже реалізованих та майбутніх бізнес-процессов. Опубліковані порівняльні огляди дозволяють виявити недостатки інших аналогічних продуктів, на які варто вчасно привернути увагу, щоб отримати конкурентну перевагу у специфікації вимог до системи. Для продукту, що включає програмні і апаратні компоненти, створюється специфікація вимог системи, що описує продукт в цілому. Окремі вимоги до системи в цілому торкаються кожної підсистеми (Nelsen,1990). Аналітик може вичленувати додаткові, більш дрібні функціональні вимоги з вимог до конкретної підсистемі.
9.2.2.Звіти про помилки і претензії до можливостей працюючої системи6
Персонал внутрішньо корпоративної і виїздної служби підтримки – цінне джерело інформації. Вони в курсі проблем, з якими стикаються користувачі працюючої системи, і постоянно вислуховують ідеї клієнтів щодо вдосконалення її слідующей версії.
9.2.3.Маркетингові дослідження та опитування користувачів7
Опитавши масу потенційних користувачів продукту, ви отримаєте купу інформації. Проконсультуйтеся з експертом з планування та управлінню опитуваннями, щоб переконатися, що задаєте потрібні питання потрібним людям (Fowler, 1995). Опитування дозволяє перевірити, наскільки чітко ви розумієте вимоги, які збираєте або, як ви думаєті, вже виявили, однак це не найкращий спосіб стимулювати творчеське мислення. Перш ніж розпочати опитування, необхідно критично вивчити передбачувані питання. Велике ж буде ваше разочаровуетня, коли ви пізно виявите, що одне з питань сформулювативан неоднозначно або що важливого питання в списку не виявилося.
9.2.4.Спостереження за користувачами на робочих місцях8
Спостерігаючи «Один робочий день з життя користувача», аналітик виявляє особливості роботи діючої системи, а також потреби потенціальних користувачів майбутньої системи. Таке дослідження позволяет перевірити інформацію, зібрану в ході інтерв'ю, визналити теми нових опитувань, виявити проблеми діючої системи і зрозуміти, які функції нової системи необхідні для автоматизації операцій (McGraw та Harbison, 1997; Beyer і Holtzblatt, 1998). Спостерігадая за роботою користувачів, ви краще і повніше зрозумієте суть робочого процесу, ніж якщо просто попросіть їх описати всі етапи їх работи. Викладаючи і узагальнюючи дані, аналітик повинен абстрагуватися від ситуації і розглядати її кілька «зверху; це гарантує, що зібрані вимоги будуть представляти інтереси класу пользователя в цілому, а не окремих осіб. До речі, досвідчені аналітики зачасту здатні запропонувати щось вельми слушна для совершенствования поточних бізнес-процесів.
9.2.5.Сценарій аналізу задач користувачів9
Визначивши, які завдання користувачеві потрібно виконувати засобами системи, аналітик повинен виробити необхідні функціональні вимоги до системі. Це – суть підходу, заснованого на застосуванні варіантів користування. Особливо важливим є дані, які необхідно для генерування вході виконання завдання, а також дженики цих даних. Події та реакція на них перераховуються зовнішні події і відповідної реакції системи на них. Даний спосіб особливо хороший для систем реального часу, які зчитують і обрабатвають потоки даних, коди помилок, керуючі сигнали і сигнали переривання від зовнішніх пристроїв.