3. Роль вимог у забезпеченні успішності проектів програмного забезпечення

Причини провалів проектів: 13,1% неповнота вимог; 12,4 % недостатнє залучення користувачів; 10,6% недостатність ресурсів; 9,9% не реалістичність очікувань, 9,3% недостатня підтримка керівництва; 8,7% недостатні вимоги/специфікації; 8,1% недостає планування; 7,5% втрата необхідності.

Перераховані проблеми можна поділити на: 1) вимоги, що погано організовані та написані, слабко пов’язані з потребами зацікавлених сторін. Можуть швидко змінюватись або змінюватись без необхідності. 2) Проблеми, пов’язані з недостатністю ресурсів, грошей, підтримки або повний провал проекту. 3) Мистецтво планування. Впливає 2 категорії.

Проблеми з зацікавленою стороною

Стів МакКоннел, в своїй книжці Швидка розробка, деталізує способи, якими користувачі можуть перешкоджати збору вимог:

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

• Користувачі не вкладуть нічого в набір письмових вимог

• Користувачі наполягають на нових вимогах після фіксації ціни та графіку розробки

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

• Користувачі вчасно не беруть участі у оглядах чи не мають змоги брати участь

• Користувачі неграмотні технічно

• Користувачі не розуміють процес розробки

• Користувачі не знають про сучасні технології

Це може привести до ситуації в якій вимоги користувача продовжують змінюватись навіть коли почалась розробка.

Проблеми з інженерами/розробниками

Можливі проблеми які можуть спричинити розробники та інженери протягом аналізу вимог:

• Технічний персонал та кінцеві користувачі можуть говорити різними мовами. Вони можуть помилково вірити в те, що вони перебувають в ідеальній згоді, поки не буде наданий закінчений продукт.

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

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

Можливі рішення

Технології представлені як прототипування, UML, прецеденти, та Гнучка розробка програмного забезпечення також вважаються рішеннями проблем пов'язаних з попередніми методами. Також, на ринок вийшов новий клас інструментів симуляції застосунків чи інструментів опису застосунків. Ці інструменти створені як міст через комунікаційний розрив між користувачами та IT - фірмами, і дозволяють застосункам бути "випробуваними ринком" перед тим як з'явиться перший код. Найкращі з цих інструментів надають:

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

• здатність фіксувати бізнес логіку та потреби даних

• здатність додавати контекстуальні вимоги та інші коментарі

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