Важко зібрати воєдино думки кількох десятків користувачів, якщо немає добре структурованої організаційної схеми, наприклад, сценарію використання. Проблеми виникають, якщо вам доводиться вислуховувати кількох користувачів, а також якщо ви маєте справу з найголоснішим і найвпертішим клієнтом. Ви можете пропустити вимоги, які важливі для певного класу користувачів, або включити вимоги, які не відображають потреби більшості користувачів. Для того, щоб зберегти баланс, необхідно залучити кілька гарячих прихильників продукту, які мають повноваження говорити від імені відповідних класів користувачів, кожного з яких повинні підтримати кілька представників того ж класу користувачів. У процесі збору інформації іноді виявляється, що межі проекту визначені неправильно - вони або занадто широкі, або занадто вузькі. У першому випадку доведеться збирати додаткові дані, щоб сформулювати адекватні комерційні та клієнтські концепції, і при цьому процес неминуче затягнеться в часі. У другому випадку важливі потреби, висловлені користувачами, виходять за межі поточного проекту. Це означає, що певні межі можуть бути занадто вузькими для отримання задовільних результатів. Таким чином, процес збору інформації іноді тягне за собою зміну образу або меж проекту. Використання офшорного тестування програмного забезпечення означає зниження витрат на розробку без шкоди для якості продукту або проекту. Українські фахівці пропонують вам широкий спектр qa послуг для забезпечення успіху вашого проекту. Часто кажуть, що вимоги визначають, що повинна робити система, а те, як буде реалізовано обране рішення, залежить від дизайну проекту. Хоча таке формулювання спокусливо коротке, насправді воно примітивне. Процес збору інформації повинен бути зосереджений на цьому ІТО, але етапи аналізу і проектування розділені не чіткою межею, а розмитою лінією. Моделі аналізу, замальовки того, що бачиться на екрані, та прототипи допомагають у зборі інформації, щоб чіткіше висловити потреби користувачів та уникнути помилок і упущень. Сприймайте моделі та дизайнерські рішення, розроблені в процесі формулювання вимог, як концептуальні пропозиції, що спрощують ефективну взаємодію, а не як обмеження можливостей, доступних розробнику. Пояснювати користувачам, що ці інструменти слугують лише для ілюстрації ідей і не обов’язково повинні використовуватися на практиці.