Методы выявления требований
Для достижения лучшего понимания потребностей пользователя нам нужно переместиться из области битов и байтов, где многие разработчики чувствуют себя более комфортно, в область, где нужно общаться с реальными людьми и понимать проблемы реального мира. Существует множество методов, которые можно использовать для анализа и проектирования программных решений. Аналогично существует множество методов для понимания требований пользователей и заинтересованных лиц.
В главах 4-6 мы начали свой путь с анализа проблемы, рассмотрели ряд вопросов, которые можно задать относительно налагаемых на систему ограничений, описали моделирование бизнес-процесса, которое можно использовать для многих приложений, а также ознакомились с методами системной инженерии, которые можно применить к сложным системам со встроенным программным обеспечением. В следующих главах будут описаны методы, доказавшие свою эффективность в преодолении трех перечисленных выше синдромов.
|
|
• Интервьюирование и анкетирование
• Совещания, посвященные требованиям
• Мозговой штурм и отбор идей
• Раскадровки
• Прецеденты
• Обыгрывание ролей
• Создание прототипов
Выбор конкретного метода будет зависеть от типа приложения, опыта и уровня по;. готовки команды разработчиков, заказчика, масштаба проблемы, критичности приложения, используемой технологии и уникальности приложения.
Основные положения
• Команда разработчиков должна играть более активную роль в выявлении требований к системе.
• Функции системы или продукта являются высокоуровневым выражением, желаемого поведения системы.
• Количество функций системы должно находиться в пределах 25-99; предпочтителтьно, чтобы оно не превышало 50.
• Атрибуты обеспечивают дополнительную информацию о функции
В предыдущих главах мы описали ряд проблем, приводящих к тому. что команда разработчиков практически никогда не получает совершенной или. по крайней мере, достаточно хорошей спецификации, которую можно использовать в качестве основы для разработки системы. Один из выводов, который из этого следует, состоит в том, что если нам не дают хороших определений, мы должны сами пойти и добыть их. Другими словами, чтобы добиться успеха, команда разработчиков должна играть гораздо более активную роль в процессе выявления требований. Мы увидим, что хотя и можно возложить основную часть этой ответственности на руководителя, аналитика или менеджера продукта, в конечном итоге вся команда будет вовлечена в тот или иной этап данного процесс».