• Гідрологія і Гідрометрія
• Господарське право
• Економіка будівництва
• Економіка природокористування
• Економічна теорія
• Земельне право
• Історія України
• Кримінально виконавче право
• Медична радіологія
• Методи аналізу
• Міжнародне приватне право
• Міжнародний маркетинг
• Основи екології
• Предмет Політологія
• Соціальне страхування
• Технічні засоби організації дорожнього руху
• Товарознавство продовольчих товарів

Розподілені вимоги

Вимоги які визначені поділом, чи іншим перерозміщенням високорівневих вимог в кілька низькорівневих вимог. Наприклад стокілограмовий пристрій що складається з двох підсистем може спричинити вимоги ваги не більше 70 та 30 кілограм для конкретних систем нижчого рівня.^[1]

До відомих моделей категоризації вимог належать FURPS та FURPS+, розроблені в Hewlett-Packard.

[-]Проблеми аналізу вимог

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

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

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

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

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

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

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

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

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

Технології представлені в 1990-тих такі як прототипування, Unified Modeling Language (UML), прецеденти, та Гнучка розробка програмного забезпечення також вважаються рішеннями проблем пов'язаних з попередніми методами.

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

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

Читайте також:

1. II. Вимоги безпеки перед початком роботи
2. II. Вимоги безпеки праці перед початком роботи
3. II. Вимоги до складання паспорта бюджетної програми
4. III. Вимоги безпеки під час виконання роботи
5. III. Вимоги безпеки під час виконання роботи
6. III. Вимоги до учасників, складу груп і керівників туристських подорожей
7. IV. Вимоги безпеки під час роботи на навчально-дослідній ділянці
8. IV. ВИМОГИ ПРОФЕСIЇ ДО IНДИВIДУАЛЬНО-ПСИХОЛОГIЧНИХ ОСОБЛИВОСТЕЙ ФАХIВЦЯ
9. V. Вимоги безпеки в аварійних ситуаціях
10. V. Вимоги безпеки в екстремальних ситуаціях
11. Аналітичні реакції та вимоги, яким вони повинні відповідати.
12. Бланк документа, вимоги що пред'являються до нього.

Переглядів: 671