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