- Главная
- Менеджмент
- Приемы создания требований. (Лекция 2)
Содержание
- 2. Анализ требований подразумевает их детализацию, гарантирующую, что требования понимают все заинтересованные лица, а также тщательное исследование
- 3. Создание контекстной диаграммы. Контекстная диаграмма — простая модель анализа, отображающая место новой системы в соответствующей среде.
- 4. Определение приоритетов требований. Определите относительные приоритеты реализации функций продукта, решаемых задач или отдельных требований. На основании
- 5. Создание словаря терминов. В нем соберите определения всех элементов и структур данных, связанных с системой, что
- 6. Контекстная диаграмма Уточнение рамок определяет границу и связи системы, которую мы разрабатываем, со всем остальным миром.
- 7. На рис. показана часть контекстной диаграммы для Chemical Tracking System. Вся система изображена кружком; на контекстной
- 8. Вы можете ожидать, что поставщики химикатов должны быть показаны на диаграмме в виде оконечных элементов. Ведь
- 10. Спецификации требований Независимо от способа выявления требований, документировать их нужно так, чтоб это обеспечивало удобный доступ
- 11. 2. Общее описание 2.1 Общий взгляд на продукт 2.2 Особенности продукта 2.3 Классы и характеристики пользователей
- 12. 5. Другие нефункциональные требования 5.1 Требования к производительности 5.2 Требования к охране труда 5.3 Требования к
- 13. Определение источников требований. Чтобы гарантировать, что все заинтересованные лица понимают, почему то или иное требование зафиксировано
- 14. Указание атрибутов качества. Выявляя качественные характеристики, удовлетворяющие потребности клиента, не ограничивайтесь только обсуждением функциональности. Выясните ожидаемые
- 15. Проверка требований Проверка гарантирует, что все положения требований корректны, отражают желаемые качественные характеристики и удовлетворяют потребностям
- 16. Тестирование требований. На основе пользовательских требований создают сценарии функционального тестирования и документируют ожидаемое поведение продукта в
- 17. Управление требованиями Начальные требования неизбежно корректируются в процессе работы клиентами, менеджерами, специалистами по маркетингу, разработчиками и
- 18. Анализ влияния изменений требований. Анализ влияния изменений помогает совету по управлению изменениями принимать обоснованные решения. Создание
- 19. Контроль за состоянием всех требований. Создайте БД, включающую по одной записи для каждого дискретного функционального требования.
- 20. Управление проектом Способы управления проектом ПО тесно связаны с работой над требованиями к нему. Планируйте ресурсы,
- 21. Планы реализации проекта должны быть основаны на требованиях. Разрабатывайте планы и графики работы над проектом постепенно,
- 23. Скачать презентацию
Анализ требований подразумевает их детализацию, гарантирующую, что требования понимают все заинтересованные
Анализ требований подразумевает их детализацию, гарантирующую, что требования понимают все заинтересованные
Цель анализа — достаточно качественно и подробно описать требования, позволяющие менеджерам реалистично оценить все затраты на проект, а техническому персоналу — начать проектирование, сборку и тестирование.
Отдельные требования стоит представить несколькими способами, например в текстовой и графической форме.
Создание контекстной диаграммы. Контекстная диаграмма — простая модель анализа, отображающая место
Создание контекстной диаграммы. Контекстная диаграмма — простая модель анализа, отображающая место
Создание пользовательского интерфейса и технических прототипов. Если разработчики или пользователи не совсем уверены насчет требований, создайте прототип — частичную, возможную или предварительную версию продукта, которая сделает концепции и возможности более осязаемыми. Оценка прототипа поможет всем заинтересованным лицам достичь взаимопонимания по решаемой проблеме.
Анализ осуществимости требований. Проанализируйте, насколько реально реализовать каждое требование при разумных затратах и с приемлемой производительностью в предполагаемой среде. Рассмотрите риски, связанные с реализацией каждого требования, включая конфликты с другими требованиями, зависимость от внешних факторов и препятствия технического характера.
Определение приоритетов требований. Определите относительные приоритеты реализации функций продукта, решаемых задач
Определение приоритетов требований. Определите относительные приоритеты реализации функций продукта, решаемых задач
Моделирование требований. В отличие от подробной информации, представленной в спецификации требований к ПО или пользовательского интерфейса прототипа, графическая модель анализа отображает требования на высоком уровне абстракции. Модели позволяют выявить некорректные, несогласованные, отсутствующие и избыточные требования. К таким моделям относятся диаграммы потоков данных, диаграммы «сущность — связь», диаграммы перехода состояний, называемые также автоматами, карты диалогов, диаграммы классов, диаграммы последовательностей, диаграммы взаимодействий, таблицы решений и деревья решений.
Создание словаря терминов. В нем соберите определения всех элементов и структур
Создание словаря терминов. В нем соберите определения всех элементов и структур
Распределение требований по подсистемам. Требования к сложному продукту, включающему несколько подсистем, следует соразмерно распределять между программными, аппаратными и операторскими подсистемами и компонентами. Как правило, это осуществляет системный инженер или разработчик.
Применение технологий развертывания функций качества. Технология развертывания функций качества — точная методика, соотносящая возможности и атрибуты продукта с их значимостью для клиента. Она позволяет аналитически выявить функции, которые максимально удовлетворят потребности клиента.
Технология развертывания функций качества рассчитана на три класса требований: ожидаемые, о которых клиент может не упомянуть, но будет расстроен, если их не окажется в продукте, обычные требования и отдельные, специальные требования, которые обеспечивают удобство работы клиентам, но отсутствие которых не влечет санкций со стороны клиента.
Контекстная диаграмма
Уточнение рамок определяет границу и связи системы, которую
Контекстная диаграмма
Уточнение рамок определяет границу и связи системы, которую
Контекстная диаграмма (contextdiagram) графически иллюстрирует эту границу. Она определяет оконечные элементы, расположенные вне системы, которые определенным образом взаимодействуют с ней, а также данные, элементы управления и материальные потоки, протекающие между оконечными элементами и системой. Контекстная диаграмма представляет собой высший уровень абстракции в диаграмме потока данных, разработанной по принципам структурного анализа, но эта модель полезна и в случае применения какой-либо другой методики разработки.
Можно включить контекстную диаграмму в документ об образе и границах, или определить ее как приложение к спецификации требований, или как часть модели потоков данных системы.
На рис. показана часть контекстной диаграммы для Chemical Tracking System.
На рис. показана часть контекстной диаграммы для Chemical Tracking System.
Вся система изображена кружком; на контекстной диаграмме намеренно не показывают внутренние объекты системы, процессы и данные. «Система» внутри кружка может иметь любую комбинацию ПО, оборудования или людских ресурсов. Оконечные элементы в прямоугольниках представляют классы пользователей («Химик» или «Покупатель»), отделы («Отдел охраны труда и техники безопасности»), другие системы («База данных по обучению») или аппаратные устройства («Считывающее устройство штрих-кода»). Стрелками показаны потоки данных («запрос химиката») или физические элементы («контейнер с химикатом») между системой и оконечными элементами.
Вы можете ожидать, что поставщики химикатов должны быть показаны на диаграмме
Вы можете ожидать, что поставщики химикатов должны быть показаны на диаграмме
Назначение таких средств, как контекстная диаграмма, заключается в стимулировании ясного и точного взаимодействия между заинтересованными в проекте лицами. Рекомендовано использовать схему, в качестве стандарта, для изображения контекстной диаграммы.
Спецификации требований
Независимо от способа выявления требований, документировать их нужно так, чтоб
Спецификации требований
Независимо от способа выявления требований, документировать их нужно так, чтоб
Шаблон для спецификации требований к ПО
на основе стандарта IEEE 830
1. Введение
1.1 Назначение
1.2 Соглашения, принятые документах
1.3 Предполагаемая аудитория и рекомендации по чтению
1.4 Границы проекта
1.5 Ссылки
2. Общее описание
2.1 Общий взгляд на продукт
2.2 Особенности продукта
2.3 Классы и характеристики пользователей
2.4 Операционная среда
2.5 Ограничения
2.1 Общий взгляд на продукт
2.2 Особенности продукта
2.3 Классы и характеристики пользователей
2.4 Операционная среда
2.5 Ограничения
2.6 Документация для пользователей
2.7 Предположения и зависимости
3. Функции системы
3.x Функция системы X
3.x.1 Описание и приоритеты
З.х.2 Последовательности «воздействие - реакция»
З.х.3 Функциональные требования
4. Требования к внешнему интерфейсу
4.1 Интерфейсы пользователя
4.2 Интерфейсы оборудования
4.3 Интерфейсы ПО
4.4 Интерфейсы передачи информации
5. Другие нефункциональные требования
5.1 Требования к производительности
5.2 Требования к охране труда
5.3 Требования к безопасности
5.4 Атрибуты
5. Другие нефункциональные требования
5.1 Требования к производительности
5.2 Требования к охране труда
5.3 Требования к безопасности
5.4 Атрибуты
6. Остальные требования
Приложение А. Словарь терминов
Приложение Б. Модели анализа
Приложение Г. Список вопросов
Определение источников требований.
Чтобы гарантировать, что все заинтересованные лица понимают, почему
Определение источников требований.
Чтобы гарантировать, что все заинтересованные лица понимают, почему
Присвоение уникальных идентификаторов всем требованиям,
Выработайте соглашение о присвоении уникальных идентификаторов требованиям, зафиксированным в спецификации требований к ПО Соглашение должно быть устойчивым к дополнению, удалению элементов и изменениям, вносимым в требования. Присвоение идентификаторов позволяет отслеживать требования и фиксировать вносимые изменения.
Указание атрибутов качества. Выявляя качественные характеристики, удовлетворяющие потребности клиента, не ограничивайтесь
Указание атрибутов качества. Выявляя качественные характеристики, удовлетворяющие потребности клиента, не ограничивайтесь
Документирование бизнес-правил. К бизнес-правилам относятся корпоративные политики, правительственные распоряжения и алгоритмы вычислений. Ведите список бизнес-правил отдельно от спецификации требований к ПО, поскольку правила обычно существуют вне рамок конкретного проекта. Для выполнения некоторых приходится создавать реализующие их функциональные требования, и поэтому необходимо определить связь между этими требованиями и соответствующими правилами.
Проверка требований
Проверка гарантирует, что все положения требований корректны, отражают желаемые качественные
Проверка требований
Проверка гарантирует, что все положения требований корректны, отражают желаемые качественные
Изучение документов с требованиями. Официальная проверка документирования требований — один из наиболее ценных способов, проверки качества ПО. Соберите небольшую команду, члены которой представляют различные направления (например, аналитик, клиент, разработчик и специалист по тестированию), и тщательно изучите спецификацию требований к ПО, модель анализа и соответствующую информацию на предмет недостатков. Данный прием — один из самых полезных.
Тестирование требований. На основе пользовательских требований создают сценарии функционального тестирования и
Тестирование требований. На основе пользовательских требований создают сценарии функционального тестирования и
Определение критериев приемлемости. Предложите пользователям описать, как они собираются определять соответствие продукта их потребностям и его пригодность к работе. Тесты на приемлемость следует основывать на сценариях использования
Управление требованиями
Начальные требования неизбежно корректируются в процессе работы клиентами, менеджерами, специалистами
Управление требованиями
Начальные требования неизбежно корректируются в процессе работы клиентами, менеджерами, специалистами
Определение процесса управления изменениями.
Определить процесс представления, анализа и утверждения или отклонения изменений. Применяйте его для управления всеми предлагаемыми изменениями. В контексте процесса управления изменениями полезно использовать коммерческие средства отслеживания недостатков.
Создание совета по управлению изменениями.
Из представителей заинтересованных в проекте лиц организуйте совет по управлению изменениями, который будет получать информацию о предполагаемых изменениях требований, оценивать ее, решать, какие изменения принять, а какие отклонить, и определять, в какой версии продукта будет внедрена та или иная функция.
Анализ влияния изменений требований.
Анализ влияния изменений помогает совету по управлению
Анализ влияния изменений требований.
Анализ влияния изменений помогает совету по управлению
Создание базовой версии и управление версиями требований.
Базовая версия содержит требования, утвержденные для реализации в конкретной версии продукта. После определения базовых требований изменения можно вносить только в соответствии с процессом управления изменениями. Присвойте всем версиям спецификации требование уникальные идентификаторы, чтобы избежать путаницы между черновыми вариантами и базовыми версиями, а также между предыдущей и текущей версиями требований. Более надежное решение — управлять версиями документов с требованиями при помощи соответствующих средств управления конфигурацией.
Ведение журнала изменений требований.
Фиксируйте даты изменения спецификаций требований, сами коррективы, их причины, а также лиц, вносивших изменения. Автоматизировать эти задачи позволяет утилита управления версиями или коммерческая утилита управления требованиями.
Контроль за состоянием всех требований. Создайте БД, включающую по одной записи
Контроль за состоянием всех требований. Создайте БД, включающую по одной записи
Оценка изменяемости требований. Еженедельно фиксируйте количество требований, внесенных в базовую версию, а также число предложенных и одобренных изменений (добавлений, модификаций и удалений).
Использование средств управления требованиями. Коммерческие утилиты управления требованиями позволяют хранить различные типы требований в БД. Для каждого требования можно определить атрибуты, отслеживать его состояние, а также выявить связи между требованиями и другими рабочими продуктами. Данный прием поможет вам автоматизировать прочие задачи по управлению требованиями, описанные ниже.
Создание матрицы связей требований. Создайте таблицу, сопоставляющую все функциональные требования с элементами архитектуры и кода, которые реализуют данное требование, и с тестами, проверяющими его. Матрица связей требований позволяет также сопоставить функциональные требования с требованиями более высоких уровней, на основе которых они созданы, и с другими родственными требованиями. Заполняйте эту таблицу в ходе, а не в конце работы над проектом.
Управление проектом
Способы управления проектом ПО тесно связаны с работой над требованиями
Управление проектом
Способы управления проектом ПО тесно связаны с работой над требованиями
Выбор цикла разработки ПО. Следует определить, несколько жизненных циклов разработки для проектов различного типа и различных степеней неопределенности требований. Каждый менеджер проекта должен выбрать и использовать цикл, оптимальным образом подходящий для его проекта. Включите в цикл операции по созданию требований. Если на ранних этапах работы над проектом требования или границы проекта определены нечетко, разрабатывайте продукт постепенно (небольшими этапами), начиная с наиболее понятных требований и устойчивых элементов архитектуры. По возможности реализуйте наборы функций, чтобы периодически выпускать промежуточные версии продукта и как можно раньше предоставлять клиенту работоспособные образцы приложение
Планы реализации проекта должны быть основаны на требованиях. Разрабатывайте планы и
Планы реализации проекта должны быть основаны на требованиях. Разрабатывайте планы и
Пересмотр обязательств по проекту при изменении требований.
Добавляя в проект новые требования, оцените, удается ли соблюдать обязательства, касающиеся графика и требований к качеству, при доступном объеме ресурсов. Если нет, обсудите реалии проекта с менеджерами и согласуйте новые, достижимые обязательства.