1.5 Введение в проектирование требований
В данном уроке мы будем разбираться, зачем нужно работать с требованиями :
- Статистика крупных проектов и основные причины провалов
- Проблема нечеткости целей
- Проблемы коммуникации. Область проблем и область решений
- Требования и цикл работы с требованиями
- Проектирование требований. Типичные проблемы
Статистика крупных проектов и основные причины провалов
Тезисы
- Небольшие проекты более успешны.
- Две группы причин приводящие к провалу проектов
- Нечеткие требования
- Плохая коммуникация
Согласно исследованиям Standish Group, успешными является только небольшая часть проектов. Как бы мы ни старались, какие бы новые технологии не появлялись, количество проектов, которые завершаются успешно (успешно – мы имеем ввиду с результатом, который предоставлен заказчику вовремя и в рамках бюджета), относительно невелико.
3SL Cradle — быстрый старт. Часть 4. Загружаем новые требования заказчика из документа
При этом, нужно обратить внимание на очень интересный аспект, который улучшает и видоизменяет статистику. Чем меньше проект, тем выше успешность проекта. Однако далеко не все проекты могут быть разбиты или декомпозированы на маленькие и значимые части. И среди проектов, которые действительно ставят перед собой амбициозные цели, доля успеха гораздо меньше.
Какие причины лежат в основе провалов проектов?
Согласно исследованиям немецкой компании , основная причина которую называют участники провалившихся проектов – это нечеткие требования и цели.
Вторая группа проблем – плохая коммуникация (политика, конфликты среди заинтересованных лиц).
Из наиболее важных факторов, с которые участники проектов связывают провалы или проблемы в проектах, половина так или иначе связана с управлением и проектированием требований.
Источник: requirements.ru
Методы сбора требований или «Как понять, что хочет заказчик?»
Данная статья будет полезна как аналитикам, так и менеджерам, занимающимся сбором и анализом требований. В ней описаны основные методики сбора требований, а также их плюсы и минусы. Возможно, что-то вы уже применяли на практике, а о чем-то, возможно, не знали. В общем, эта статья для всех тех, кто уже занимается бизнес — анализом или только планирует пополнить ряды аналитиков.
Сбор требований — это один из самых важных этапов процесса создания любой информационной системы, будь то десктопное, веб или мобильное приложение или же просто доработка уже существующего решения. Прежде, чем начать собирать требования, необходимо выявить всех заинтересованных лиц (стейкхолдеров), которые будут пользоваться системой. Чем точнее будет этот список, тем полнее будут требования. Итак, для начала, рассмотрим кто же такие стейкхолдеры.
Мастер-класс по сбору и анализу требований
Стейкхолдерами могут быть любые физические лица и/или организации, которые активно участвуют в нашем проекте, и чьи интересы могут быть затронуты не только в процессе создания системы, но и непосредственно по завершению самого проекта. Ими могут быть менеджеры, начальники отделов, директора, любые сотрудники организации, которые будут хоть как-то взаимодействовать с готовым решением, и чьи требования (пожелания, идеи, потребности, проблемы) будем собирать.
Существует множество различных техник сбора требований, которые помогут лучше понять, что же хочет заказчик.
Рассмотрим основные из них чуть подробнее:
Анкетирование
Список вопросов при сборе требований
# Список вопросов, который можно задать заказчику для опрделения требований
Перед тем, как написать эту статью, я поискал что-то подобное в сети. Но все ресурсы твердят, как мантру: задавайте вопросы заказчику, но не приводят никаких примеров. Я много раз повторял, что бизнесу нельзя задавать вопросы типа: какую базу данных вы хотите использовать? Список вопросов, возможно, будет со временем изменяться или дополняться.
Предлагаю рассматривать этот список как шпаргалку.
Предлагаю рассматривать этот список как шпаргалку.
Documentation Interoperability
- Есть ли данные, поступающие (идущие) из внешних систем?
- Как должен функционировать обмен данными со внешними системами: в режиме реального времени, ежечасно, ежедневно и т. д.?
- Есть ли какие-то ограничения на использования внешних систем?
System Modifications
* Какие части системы являются вероятными кандидатами для последующей модификации? * Какие части системы являются приоритетными кандидатами для последующей модификации?
Security
- Какие данные, управляемые системой, должны быть безопасными?
- Кто, когда и где должен иметь доступ к системе?
- Есть ли внешние системы, которые обслуживают аутентификацию, авторизацию, а также, аккаунты?
- Есть ли внешние системы, которые должны быть авторизированы в системе? Какие у них должны быть права и роли?