Функции продукта или системы

Методы выявления требований

Для достижения лучшего понимания потребностей пользователя нам нужно переместиться из области битов и байтов, где многие разработчики чувствуют себя более комфортно, в область, где нужно общаться с реальными людьми и понимать проблемы реального мира. Существует множество методов, которые можно использовать для анализа и проектирования программных решений. Аналогично существует множество методов для понимания требований пользователей и заинтересованных лиц.

В главах 4-6 мы начали свой путь с анализа проблемы, рассмотрели ряд вопросов, которые можно задать относительно налагаемых на систему ограничений, описали моделирование бизнес-процесса, которое можно использовать для многих приложений, а также ознакомились с методами системной инженерии, которые можно применить к сложным системам со встроенным программным обеспечением. В следующих главах будут описаны методы, доказавшие свою эффективность в преодолении трех перечисленных выше синдромов.

• Интервьюирование и анкетирование

• Совещания, посвященные требованиям

• Мозговой штурм и отбор идей

• Раскадровки

• Прецеденты

• Обыгрывание ролей

• Создание прототипов

Выбор конкретного метода будет зависеть от типа приложения, опыта и уровня по;. готовки команды разработчиков, заказчика, масштаба проблемы, критичности приложения, используемой технологии и уникальности приложения.

Основные положения

• Команда разработчиков должна играть более активную роль в выявлении требований к системе.

• Функции системы или продукта являются высокоуровневым выражением, желаемого поведения системы.

• Количество функций системы должно находиться в пределах 25-99; предпочтителтьно, чтобы оно не превышало 50.

• Атрибуты обеспечивают дополнительную информацию о функции

В предыдущих главах мы описали ряд проблем, приводящих к тому. что команда разработчиков практически никогда не получает совершенной или. по крайней мере, достаточно хорошей спецификации, которую можно использовать в качестве основы для разработки системы. Один из выводов, который из этого следует, состоит в том, что если нам не дают хороших определений, мы должны сами пойти и добыть их. Другими словами, чтобы добиться успеха, команда разработчиков должна играть гораздо более активную роль в процессе выявления требований. Мы увидим, что хотя и можно возложить основную часть этой ответственности на руководителя, аналитика или менеджера продукта, в конечном итоге вся команда будет вовлечена в тот или иной этап данного процесс».