Выделение и анализ требований
После получения общего представления о деятельности и целях организаций, в которых будет работать будущая программная система, и о ее предметной области, можно определить более четко, какие именно задачи система будет решать. Кроме того, важно понимать, какие из задач стоят наиболее остро и обязательно должны быть поддержаны уже в первой версии, а какие могут быть отложены до следующих версий или вообще вынесены за рамки области ответственности системы. Эта информация выявляется при анализе потребностей возможных пользователей и заказчиков.
Потребности определяются на основе наиболее актуальных проблем и задач, которые пользователи и заказчики видят перед собой. При этом требуется аккуратное выявление значимых проблем, определение того, насколько хорошо они решаются при текущем положении дел, и расстановка приоритетов при рассмотрении недостаточно хорошо решаемых, поскольку чаще всего решить сразу все проблемы невозможно.
Формулировка потребностей может быть разбита на следующие этапы.
1.Выделить одну-две-три основных проблемы.
2.Определить причины возникновения проблем, оценить степень их влияния и выделить наиболее существенные из проблем, влекущие появление остальных.
3.Определить ограничения на возможные решения.
Формулировка потребностей не должна накладывать лишних ограничений на возможные решения, удовлетворяющие им. Нужно попытаться сформулировать, что именно является проблемой, а не предлагать сразу возможные решения.
Например, формулировки «система должна использовать СУБД Oracle для хранения данных», «нужно, чтобы при вводе неверных данных раздавался звуковой сигнал» не очень хорошо описывают потребности. Исключением в первом случае может быть особая ситуация, например, если СУБД Oracle уже используется для хранения других данных, которые должны быть интегрированы с рассматриваемыми: при этом ее использование становится внешним ограничением. Соответствующие потребности лучше описать так: «нужно организовать надежное и удобное для интеграции с другими системами хранение данных», «необходимо предотвращать попадание некорректных данных в хранилище».
При выявлении потребностей пользователей анализируются модели деятельности пользователей и организаций, в которых они работают, для выявления проблемных мест. Также используются такие приемы, как анкетирование, демонстрация возможных сеансов работы будущей системы, интерактивные опросы, где пользователям предоставляется возможность самим предложить варианты внешнего вида системы и ее работы или поменять предложенные кем-то другим, демонстрация прототипа системы и др.
После выделения основных потребностей нужно решить вопрос о разграничении области ответственности будущей системы, т.е. определить, какие из потребностей надо пытаться удовлетворить в ее рамках, а какие — нет.
При этом все заинтересованные лица делятся на пользователей, которые будут непосредственно использовать создаваемую систему для решения своих задач, и вторичных заинтересованных лиц, которые не решают своих задач с ее помощью, но чьи интересы так или иначе затрагиваются ею. Потребности пользователей нужно удовлетворить в первую очередь и на это нужно выделить больше усилий, а интересы вторичных заинтересованных лиц должны быть только адекватно учтены в итоговой системе.
На основе выделенных потребностей пользователей, отнесенных к области ответственности системы, формулируются возможные функции будущей системы, которые представляют собой услуги, предоставляемые системой и удовлетворяющие потребности одной или нескольких групп пользователей (или других заинтересованных лиц). Идеи для определения таких функций можно брать из имеющегося опыта разработчиков (наиболее часто используемый источник) или из результатов мозговых штурмов и других форм выработки идей.
Yandex.RTB R-A-252273-3- Предисловие
- Лекция 1. Проблемы разработки сложных программных систем
- Программы «большие» и «маленькие»
- Принципы работы со сложными системами
- Литература к Лекции 1
- Лекция 2. Жизненный цикл и процессы разработки ПО
- Понятие жизненного цикла ПО
- Модели жизненного цикла
- «Тяжелые» и «легкие» процессы разработки
- Унифицированный процесс Rational
- Экстремальное программирование
- Лекция 4. Анализ предметной области и требования к ПО
- Анализ предметной области
- Выделение и анализ требований
- Литература к Лекции 4
- Лекция 5. Качество ПО и методы его контроля
- Качество программного обеспечения
- Методы контроля качества
- Ошибки в программах
- Лекция 6. Архитектура программного обеспечения
- Анализ области решений
- Архитектура программного обеспечения
- Разработка и оценка архитектуры на основе сценариев
- Литература к Лекции 6
- Лекция 7. Образцы проектирования
- Образцы человеческой деятельности
- Многоуровневая система
- Литература к Лекции 7
- Лекция 8. Образцы проектирования (продолжение)
- Данные–представление–обработка
- Идиомы
- Шаблонный метод
- Образцы организации и образцы процессов
- Литература к Лекции 8
- Понятность
- Методы разработки удобного программного обеспечения
- Лекция 10. Основные конструкции языков Java и C#
- Платформы Java и .NET
- Целочисленные типы
- Инструкции и выражения
- Выражения
- Наследование
- Шаблонные типы и операции
- Описание метаданных
- Средства создания многопоточных программ
- Основные понятия компонентных технологий
- Общие принципы построения распределенных систем
- Лекция 13. Компонентные технологии разработки Web-приложений
- Web-приложения
- Платформа Java 2 Enterprise Edition
- Именование
- Работа с XML
- Отказоустойчивость
- Защита
- Работа с XML
- Литература к Лекции 13
- Уровень бизнес-логики и модели данных в J2EE
- Компоненты, управляемые сообщениями
- Уровень модели данных в .NET
- Уровень пользовательского интерфейса в J2EE
- Уровень пользовательского интерфейса в .NET
- Лекция 15. Развитие компонентных технологий
- Развитие технологий J2EE
- Java Data Objects
- Enterprise Java Beans 3.0
- Среда Spring
- Защита
- Литература к Лекции 15
- Лекция 16. Управление разработкой ПО
- Задачи управления проектами
- Окружение проекта
- Структура организации-исполнителя проекта
- Управление рисками