Этап 2. Анализ требований к программному обеспечению
Анализ требований подразумевает их очистку, гарантирующую, что требования понимают все заинтересованные лица, а также тщательное исследование требований на предмет ошибок, пробелов и других недостатков. Кроме того, анализ включает разбиение высокоуровневых требований на более детальные, создание прототипов, анализ осуществимости и согласование приоритетов. Цель анализа — достаточно качественно и подробно описать требования, позволяющие менеджерам реалистично оценить все затраты на проект, а техническому персоналу — начать проектирование, разработку и тестирование.
Очень хорошо представлять отдельные требования несколькими способами, в текстовой и графической форме или одновременно в виде требований и тестов. Это позволит выявить их особенности и проблемы, не заметные при представлении одним способом. Также это помогает всем заинтересованным лицам выработать согласованное представление об итогах разработки продукта.
Моделирование среды приложения
Контекстная диаграмма — простая модель анализа, отображающая место новой системы в соответствующей среде. Она определяет границы и интерфейсы между разрабатываемой системой и сущностями, внешними для этой системы, например пользователями, устройствами и прочими информационными системами. Карта экосистемы показывает различные системы в пространстве решения, которые взаимодействуют друг с другом, а также природу их взаимосвязей.
Создание пользовательского интерфейса и технических прототипов
Если разработчики или пользователи не совсем уверены насчет требований, создайте прототип — частичную, возможную или предварительную версию продукта, которая сделает концепции и возможности более осязаемыми. Оценка прототипа поможет разработчикам и пользователям достичь взаимопонимания по решаемой проблеме, а также проверить требования.
Анализ осуществимости требований
Аналитик совместно с разработчиками должен определить, насколько возможно реализовать каждое требование при разумных затратах и с приемлемой производительностью в предполагаемой среде. Это позволяет заинтересованным лицам понять риски, связанные с реализацией каждого требования, включая конфликты с другими требованиями, зависимость от внешних факторов и препятствия технического характера. Технически нереализуемые или очень дорогие в реализации требования можно попытаться упростить и в таком виде включить в проект для достижения бизнес-целей.
Определение приоритетов требований
Очень важно определить приоритеты требований, чтобы быть уверенным, что команда реализует самую важную и своевременную функциональность в первую очередь. Воспользуйтесь аналитическим подходом и определите относительные приоритеты реализации функций продукта, решаемых задач, пользовательских историй или отдельных требований. На основании приоритетов установите, в какой версии будет реализована та или иная функция или набор требований. В ходе работы над проектом периодически корректируйте приоритеты в соответствии с потребностями клиента, условиями рынка и бизнес-целями.
Создание словаря данных
В нем соберите определения всех элементов и структур данных, связанных с системой, что позволит всем участникам проекта использовать согласованные определения данных. На стадии работы над требованиями словарь должен содержать определения элементов данных, относящихся к предметной области, чтобы клиентам и разработчикам было проще общаться.
Моделирование требований
Модель анализа представляет собой диаграмму, которая визуально отображает требования, в отличие от текстового представления списка функциональных требований. Модели позволяют выявить некорректные, несогласованные, отсутствующие и избыточные требования. К таким моделям относятся диаграммы потоков данных, диаграммы «сущность-связь», диаграммы перехода состояний, таблицы состояний, карты диалоговых окон, деревья решений и другие.
Анализ интерфейсов между системой и внешним миром
Во всех программных системах существуют связи с другими частями, реализованные как внешние интерфейсы. Информационные системы имеют пользовательские интерфейсы и часто обмениваются данными с другими программными системами. Встроенные системы обеспечивают связь между программными и аппаратными компонентами. В приложениях с подключением к сети есть коммуникационные интерфейсы. Анализ всего этого позволит обеспечить гладкую интеграцию вашего приложения в среду.
Распределение требований по подсистемам
Требования к сложному продукту, включающему несколько подсистем, следует соразмерно распределять между программными, аппаратными и операторскими подсистемами и компонентами. В качестве примера такого продукта можно привести систему доступа для защиты здания, которая включает магнитные или оптические бейджи, сканеры, видеокамеры и регистраторы, дверные замки и охранников.
Очень хорошо представлять отдельные требования несколькими способами, в текстовой и графической форме или одновременно в виде требований и тестов. Это позволит выявить их особенности и проблемы, не заметные при представлении одним способом. Также это помогает всем заинтересованным лицам выработать согласованное представление об итогах разработки продукта.
Моделирование среды приложения
Контекстная диаграмма — простая модель анализа, отображающая место новой системы в соответствующей среде. Она определяет границы и интерфейсы между разрабатываемой системой и сущностями, внешними для этой системы, например пользователями, устройствами и прочими информационными системами. Карта экосистемы показывает различные системы в пространстве решения, которые взаимодействуют друг с другом, а также природу их взаимосвязей.
Создание пользовательского интерфейса и технических прототипов
Если разработчики или пользователи не совсем уверены насчет требований, создайте прототип — частичную, возможную или предварительную версию продукта, которая сделает концепции и возможности более осязаемыми. Оценка прототипа поможет разработчикам и пользователям достичь взаимопонимания по решаемой проблеме, а также проверить требования.
Анализ осуществимости требований
Аналитик совместно с разработчиками должен определить, насколько возможно реализовать каждое требование при разумных затратах и с приемлемой производительностью в предполагаемой среде. Это позволяет заинтересованным лицам понять риски, связанные с реализацией каждого требования, включая конфликты с другими требованиями, зависимость от внешних факторов и препятствия технического характера. Технически нереализуемые или очень дорогие в реализации требования можно попытаться упростить и в таком виде включить в проект для достижения бизнес-целей.
Определение приоритетов требований
Очень важно определить приоритеты требований, чтобы быть уверенным, что команда реализует самую важную и своевременную функциональность в первую очередь. Воспользуйтесь аналитическим подходом и определите относительные приоритеты реализации функций продукта, решаемых задач, пользовательских историй или отдельных требований. На основании приоритетов установите, в какой версии будет реализована та или иная функция или набор требований. В ходе работы над проектом периодически корректируйте приоритеты в соответствии с потребностями клиента, условиями рынка и бизнес-целями.
Создание словаря данных
В нем соберите определения всех элементов и структур данных, связанных с системой, что позволит всем участникам проекта использовать согласованные определения данных. На стадии работы над требованиями словарь должен содержать определения элементов данных, относящихся к предметной области, чтобы клиентам и разработчикам было проще общаться.
Моделирование требований
Модель анализа представляет собой диаграмму, которая визуально отображает требования, в отличие от текстового представления списка функциональных требований. Модели позволяют выявить некорректные, несогласованные, отсутствующие и избыточные требования. К таким моделям относятся диаграммы потоков данных, диаграммы «сущность-связь», диаграммы перехода состояний, таблицы состояний, карты диалоговых окон, деревья решений и другие.
Анализ интерфейсов между системой и внешним миром
Во всех программных системах существуют связи с другими частями, реализованные как внешние интерфейсы. Информационные системы имеют пользовательские интерфейсы и часто обмениваются данными с другими программными системами. Встроенные системы обеспечивают связь между программными и аппаратными компонентами. В приложениях с подключением к сети есть коммуникационные интерфейсы. Анализ всего этого позволит обеспечить гладкую интеграцию вашего приложения в среду.
Распределение требований по подсистемам
Требования к сложному продукту, включающему несколько подсистем, следует соразмерно распределять между программными, аппаратными и операторскими подсистемами и компонентами. В качестве примера такого продукта можно привести систему доступа для защиты здания, которая включает магнитные или оптические бейджи, сканеры, видеокамеры и регистраторы, дверные замки и охранников.