Sep reqm-lec1
•Télécharger en tant que PPT, PDF•
0 j'aime•1,515 vues
Управление требованиями
![Структура курса ,[object Object],[object Object],[object Object],1-](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)
Recommandé
Contenu connexe
Tendances
Tendances (20)
En vedette
En vedette (20)
Similaire à Sep reqm-lec1
Similaire à Sep reqm-lec1 (20)
Plus de Natalia Zhelnova
Plus de Natalia Zhelnova (20)
Sep reqm-lec1
- 1. Управление требованиями и изменениями Курс читает: Наталья Желнова TEKAMA 1-
- 11. Вопросы? Пожелания? ? ! ? ! 1-
- 12. Базовые понятия Категории требований. Границы системы и ПО. Образ продукта и граница проекта 1-
- 21. Граница продукта Создаваемое программное обеспечение Пользователи Компьютерное оборудование Внешняя база данных Производственное оборудование Другое ПО Граница продукта 1-
- 22. Граница проекта Команда разработчиков Требования и проектные документы Аналитики Пользователи Менеджеры Заказчики 1-
- 26. Вопросы? ? ! ? ! 1-
- 27. Проблема определения требований Влияние требований на проект. Важность требований в разработке. 1-
- 31. Нет проблем ! ? Когда можно построить дом? 1-
- 32. Понимание 1-
- 35. Цена ошибок в требованиях Относительная стоимость исправления ошибок в требованиях 20 40 60 80 100 Требования Использование Проект Кодирование Тестирование Фазы разработки [ Карл Видгерс ] 1-
- 36. Характерный взгляд на процесс разработки 1-
- 37. Вопросы? ? ! ? ! 1-
- 38. Спецификация требований Роль спецификации в проекте. Содержание спецификации. Структура спецификации 1-
- 40. Роль спецификации требований Спецификация требований. ( СТПО ) Бизнес Пользователи Система Ограничения Управление проектом Проектирование Программирование Тестирование .............. Подрядчик Заказчик Разработка требований Использование требований 1-
- 52. Структуризация по пользователям 3. Детальные требования 3.1 Требования внешнего интерфейса 3.2 Функциональные требования 3.2.1 Класс пользователя 1 3.2.1.1 Функциональное требование 1.1 .... 3.2.1. n Функциональное требование 1. n .... 3.2. m Класс пользователя m 3.2. m . 1 Функциональное требование m . 1 .... 3.2. m . n Функциональное требование m . n 3.3 Требования к производительности 3.4 Ограничения проектирования 1-
- 53. Структуризация по функциям 3. Детальные требования 3.1 Требования внешнего интерфейса 3.1.1 Интерфейсы пользователей 3.1.2 Интерфейсы с оборудованием 3.1.3 Интерфейсы с ПО 3.1.4 Коммуникационные интерфейсы 3.2 Функциональные требования 3.2.1 Информационные потоки 3.2.1.1 Описание группы функций (Связь функций через потоки данных) … .. 3.2.2 Описания функций 3.2.2.1 Функция 1 Входные и выходные данные, Алгоритм … ... 3.2.3 Структуры данных 3.2.3.1 Структура 1 (Тип записи, Поля) ...... 1-
- 56. Вопросы? ? ! ? ! 1-
- 57. Представление информации Характеристика пользователей. Контекстная диаграмма. Словарь данных Требования в ХР программировании 1-
- 59. Контекстная диаграмма (пример) Система «Полиграф» Менеджер Бухгалтер Технолог Система «1С» Интернет Ксерокс Клиенты и заказы Расчеты и отчеты Материалы и работы Заказы Показатели эксплуатации Данные об оплате Финансовые отчеты Платежи Расчеты для клиентов 1-
- 60. Словарь данных (пример) – физическое или юридическое лицо делающее Запрос на производство печатной продукции. Может заключать Договор на длительный срок. Может быть неизвестное лицо, для которого нужно рассчитать Заказ . Пример Карточки клиента см. в Приложении 1. Клиент + Название - имя или название клиента [ Текст(30) ] + Дата - дата регистрации клиента [ Дата (дд.мм.гг) ] + Категория - категория клиента [ обычн. |VIP| новый | ...] + Адрес - адрес клиента [ Адрес ] + (Email) - адрес электронной почты [ Текст(30) ] + Контакт (1: N ) - список Контактных лиц [ Контактное лицо ] + Договор (1: N) - список Договоров [ Договор ] – почтовый адрес контрагента ( Клиент , Подрядчик ). Адрес + Индекс - почтовый индекс [ Целое(6) ] + Улица - название улицы (справ. БТИ) [ Текст(20) ] + Дом - номер дома, корпуса, строения [ Текст(10) ] 1-
- 61. Формат словаря данных – физическое или юридическое лицо делающее Запрос на производство печатной продукции. Клиент + Название - имя или название клиента [ Текст(30) ] + Дата - дата регистрации клиента [ Дата (дд.мм.гг) ] + Категория - категория клиента [ обычн. | VIP |...] + Адрес - адрес клиента [ Адрес ] + (Email) - адрес электронной почты [ Текст(30) ] + Контакт (1: N ) - список контактных лиц [ Контактное лицо ] + Договор (1: N) - список договоров [ Договор ] Обозначение сущности Описание сущности Ссылка на сущность Обозначение атрибута Названиеатрибута Необязательный атрибут Повторяемость значения атрибута Простой тип данных, его формат или список допустимых значений Ссылки на сущности 1-
- 63. История пользователя 214 Отображение 2 отсканированной единицы товара После сканирования упаковки вверху терминала появляется краткое описание товара и его цена. Номер истории Трудоемкость в пунктах. 1пункт=1чел/неделя На обратной стороне – описание приемочного теста 1-
- 64. Иерархия требований в ХР Представление Цели и назначение создаваемого ПО История История История Задача Представление о системе Набор проекта Стек Цели Стек Стек Задачи и тесты для реализации историй 1-
- 65. Вопросы? ? ! ? ! 1-
Notes de l'éditeur
- Этот курс о том, что с требованиями происходит после того, как они сформулированы. Это непосредственно касается работы программиста или лидера группы программистов. Этот курс не о том, как требования создаются, что является предметом другого курса программы SE P по подготовке проектировщиков требований.
- Обсудить вопрос – в какой момент возникает необходимость управления требованиями? Ответ: после 5-10 минутного обсуждения сделать вывод: в любой.
- В ИТ-индустрии отмечается резкий рост интереса к модели качества СММ/CMMI, принятой сегодня во всем мире. По существу, СММ представляет собой систему оценки и проверки возможностей компании, зрелость которой соответствует одному из пяти уровней. Модель СММ Capability Maturity Model была разработана в 1991 году Институтом программной инженерии Университета Карнеги-Меллона (Software Engineering Institute, SEI) для разработки программных продуктов. С течением времени было выпущено целое семейство моделей: SW-CMM — для программных продуктов, SE-CMM — для системной инженерии, Acquisition CMM — для закупок, People CMM — для управления людскими ресурсами, ICMM —для интеграции продуктов. Разнообразные модели оказались достаточно сложными для понимания и внедрения. Поскольку они были созданы разными группами специалистов, содержание этих моделей не всегда согласовывалось друг с другом, а также с требованиями международных стандартов. Поэтому в 2002 году SEI опубликовал новую модель CMMI (Capability Maturity Model Integration), объединяющую ранее выпущенные модели и учитывающую требования международных стандартов. Внедрение СММ/CMMI позволяет улучшить структуру и качество процессов (основные проблемы в программных разработках — это проблемы управления, а не технические проблемы), обеспечить стабильно высокое качество разработок и освоить процессы, которые могут служить основой для повышения конкурентной способности и дальнейшего развития и расширения компании.
- В известном материале SWEBOK . Guide to the Software Engineering Body of Knowledge (Руководство по области знаний программной инженерии), 2004, подготовленном в IEEE Computer Society Professional Practices Committee и одобренном примерно 1000 представителями программистов со всего мира, область знаний "Требования" (" Requirements ") занимает самое первое место среди остальных дисциплин программной инженерии.
- Управление требованиями относится к процессам второго уровня зрелости, а разработка требований — к третьему уровню зрелости. Область процессов «Управление требованиями» подразумевает, что организация-разработчик получила требования от заказчика, а область процессов «Разработка требований» — что организации-разработчику известны потребности заказчика, но эти потребности должны быть трансформированы в требования.
- На определении требований к разрабатываемому ПО основываются практически все остальные процессы разработки ПО. Соответственно, связи от этого курса, так или иначе, тянутся практически во все остальные курсы программы SEP . Но особенно тесно этот курс перекликается с двумя другими: «Определение требований» и «Управление ожиданиями заказчика». Эти два курса и курс «Управление требованиями и изменениями» связаны общей системой основополагающих понятий, но каждый их них рассматривает разные аспекты одной и той же проблемы – проблемы определения требований.
- Требования к ПО выражают потребности и ограничения, связанные с программным продуктом, предназначенным для решения некоторой проблемы реального мира. Эти потребности возникают в некоторой организации, заказавшей ПО, или их наличие предполагается в ряде организаций или категорий отдельных пользователей при разработке ПО для рынка. Эти потребности могут касаться автоматизации всей или части некоторого бизнес процесса, управления некоторым устройством или сложной конструкцией, а так же обеспечения взаимодействия некоторых программ и т.п. Возможности ПО выражаются функциональными требованиями, а качество ПО - различными ограничениями по производительности, мобильности, соответствия законодательству и т.п. Необходимые свойства ПО приобретает в процессе проектирования и программирования (конструирования), а проявляются они в процессе его тестирования и использования. Различают несколько категорий требований, примеры которых представлены на следующих слайдах.
- Функциональные требования представляют нижний уровень требований, на основе которых выполняется проектирование и конструирование ПО. Каждое функциональное требование определяет, какую обработку определенных входных данных должно выполнять ПО, чтобы получить определенные выходные данные. Функциональные требования формулируются в форме: "ПО должно обеспечивать возможность выполнять такие-то действия с такими-то данными".
- Требования к интерфейсу определяют особенности взаимодействия ПО с различными элементами системы (люди, оборудование, ПО), в рамках которой оно должно функционировать
- Требования к качеству выражают требуемые эксплуатационные характеристики ПО. Они обычно налагают ограничения на архитектуру ПО и могут уточнять некоторые его функциональные требования.
- Ограничения представляют собой требования, чтобы ПО работало в соответствии с определенными положениями, стандартами, законами или реализовывалось с применением определенных технологий.
- Требования пользователей обычно выражаются перечнем возможностей, которые они получат для решения своих производственных задач при использовании нового ПО. Необходимость реализации той или иной возможности порождает одно или несколько функциональных требований. Возможность скорее формулирует то, что нужно получить пользователю, чем как это будет реализовано. Возможности могут формулироваться на нескольких уровнях абстракции (группироваться) и практически всегда предполагают детализацию в форме функциональных требований.
- Бизнес цели являются требованиями самого высокого уровня. Они определяют цели и необходимость разработки, доработки или приобретения ПО Бизнес цели обычно представляют требования не к ПО, а к системе, в рамках которой должно работать ПО. Это скорее требования к бизнес процессам, и их реализация предполагает выполнение определенных функций как со стороны ПО, так и со стороны его пользователей и других элементов системы.
- Разделение требований на категории позволяет более полно выявлять требования к ПО и определять условия его разработки. Знание категорий позволяет в процессе определения требований задавать вопросы типа "А нет ли еще требований такой-то категории к ПО?" Отнесение требования к определенной категории определяет способ его реализации и проверки. Требования всех категорий должны формулироваться в терминах прикладной области, чтобы быть понятыми пользователями.
- Любое ПО всегда работает в некотором окружении. Это окружение является источником требования к ПО и его пользователем. При разработке ПО основными вопросами являются: с какими объектами оно должно взаимодействовать, в чем это взаимодействие должно заключаться и по каким правилам оно осуществляется. Ответы на эти вопросы определяют «границу продукта». При определении требований ПО рассматривается как «черный ящик», а требования описывают его «поведение» в рамках использующей системы. Исключением являются только ограничения на архитектуру и инструменты реализации, если таковые диктуются интересами системы. Прочность «границы» определяется полнотой, детальностью и актуальностью требований. Описание границ продукта, его свойств и ограничений определяет "образ продукта" ( product vision ).
- Требования к ПО являются основным условием выполнения проекта, определяющим действия разработчиков. Вместе с другими условиями разработки (планы, бюджет, требования к процессам) требования образуют "границу проекта" (project scope). Граница проекта является "договором" между разработчиками, конструирующими ПО и остальными заинтересованными лицами. Наличие такого договора определяет зону ответственности разработчиков, обеспечивает свободу их действий и оценку результатов их деятельности. При отсутствии подтвержденного одинакового понимая требований, разработчики могут двигаться в разных направлениях (см. басню И. Крылова "Лебедь, рак и щука"), а проект в целом в направлении провала.
- Следует различать образ продукта , определяющий весь продукт и направляющий разработку, и границы проекта , реализующего на определенном отрезке времени при ограниченных ресурсах (время, деньги) в общем случае часть продукта. Образ продукта определяет, что хотелось бы иметь, а границы проекта – то, что на определенном отрезке времени реализуется и обладает определенной потребительской ценностью. ЛОВУШКА . Эти понятия часто смешивают, что ведет к "бесконечному" проекту. Образ продукта в жизненном цикле ПО может меняться, но в каждый момент времени должна быть явно определена та его часть, которая реализуется в текущем проекте. Управление границами проекта - задача планирования. Жизнь продукта в общем случае представляет собой последовательность проектов по реализации различных версий продукта. Если продукт удачный, то таких проектов может быть много.
- Границы продукта определяют порядок его взаимодействия с окружением ПО - среде, в которой ПО предполагается использовать. Набор требований является основой для планирования проекта (определения стоимости разработки, сроков и выделения ресурсов, контроля за продвижением проекта). Требования являются основным, в идеале единственным, внешним источником информации для разработчиков программ в конкретном проекте. Остальные источники (инструменты и методы разработки) являются прерогативой профессии разработчика и не связаны с конкретным проектом и прикладной областью. Требования к ПО являются основой соглашения между заказчиком и исполнителем. На основе требований к продукту оцениваются результаты разработки ПО.
- Сложность выявления требований и возможная строгость их изложения различаются для различных видов ПО. Наиболее сложными с этой точки зрения являются ПО для управления бизнес процессами в различных производственных областях, когда ПО разрабатывается для различных категорий пользователей, потребности которых могут различаться даже на предприятиях одной отрасли.
- Почему программа может не делать того, что нужно пользователю? – Скорее всего, при ее разработке у разработчиков были неправильные представления о том, что нужно пользователю! Почему программа может быть не удобна в использовании? – Вероятно, разработчики интерфейса слабо представляли то, как будет реально использоваться программа! Почему программа может трудно осваиваться? – Возможно, разработчики имели неправильное представление об уровне компьютерных навыков у пользователей. Почему программа может постоянно изменяться? – Скорее всего, первая версия программы учитывала только незначительную часть требований! Почему программа может не дойти до своего пользователя? – Часто, потому, что имеют место все перечисленные выше факторы, плюс затянувшаяся во времени, из-за постоянных изменений требований, разработка В качестве основных источников перечисленных на слайде проблем являются: - недостаточная полнота требований; - недостаточное вовлечение пользователей к разработке; - частое изменение требований; - разное понимание требований всеми заинтересованными сторонами; Это подтверждают постоянно проводимые исследования (см. следующий слайд)
- С 1986 года компания Standish Group International, Inc. проводит исследования причин провалов (задержка поставки, превышен бюджет, прекращены работы) и успехов проектов. В их отчетах разработка ПО сравнивается со строительством мостов, которые делаются по плану, в выделенном бюджете и долго стоят. Основное отличие в том, что мосты делаются по предельно детальным проектам, которые фиксируются и строители не могут отклоняться от утвержденной спецификации. Еще одно отличие в том, что причины провалов программистских проектов не анализируются и ошибки повторяются вновь и вновь. В США ежегодно тратится $250 000 000 000 на разработку ПО в примерно 175 000 проектах, из которых 31% проектов останавливаются, не достигнув результата и 52% превышают запланированный бюджет вдвое. Как видно из таблицы (она представляет результат обследований около 8000 проектов) причины провалов так или иначе связаны с определением требований ("Неполнота требований", "Недостаточное привлечение пользователей", "Изменение требований", "Нереалистические ожидания", "Потеря необходимости". Итого 41.8%).
- Аналогично провалам, причины удач также связаны с определением требований ("Вовлечение пользователей", "Четкая и ясная постановка требований", "Реалистичные ожидания", "Владение требованиями". Итого 42.4%).
- Этот рисунок (подобных существует много) иллюстрирует основную проблему создания ПО – планирование разработки в условиях отсутствия полного понимания разработчиками истинных потребностей заказчика. На вопрос «Когда можно что-то построить?» можно корректно ответить после того, как известно «что нужно построить».
- В своей знаменитой статье "Нет серебряной пули: сущность и привнесенность в программной инженерии" Фредерик Брукс отмечает важность требований (перевод этой статьи можно найти в последнем издании его книге "Мифический человеко-месяц"). И это не единственное высказывание на эту тему от гуру программирования.
- Эта диаграмма взята из книги К.Вигерса. Она показывает относительную стоимость работ по исправлению ошибок в требованиях на разных фазах жизненного цикла ПО. Если в требованиях обнаружена ошибка, то относительная стоимость ее исправления на этапе определения требований оценивается примерно в 5%, обнаружение той же ошибки на фазе тестирования - в 18%, а на фазе использования исправление ошибки в требованиях обойдется в 20 раз дороже, чем ее исправление на фазе определения требований. Такое лавинообразное увеличение стоимости исправления ошибки на каждой более поздней фазе включает стоимость работ, которые нужно выполнить для этого на всех более ранних фазах и за счет увеличения объем материалов, которые нужно исправлять на более поздних фазах (проект, коды, тесты, документация, инструкции пользователей).
- Этот слайд иллюстрирует один характерный (с точки зрения требований) взгляд на процесс возникновения ПО с точки зрения требований. Здесь: Окружение - социально-техническая среда использования создаваемого ПО Идея - желание что-то улучшить в этом окружении Бизнес цели - что даст окружению создаваемое ПО, зачем его создавать Потребности - перечень потребностей различных категорий будущих пользователей Возможности - которые создаваемое ПО предоставит для удовлетворения потребностей Спецификация – зафиксированные, согласованные детализированные требования к ПО Архитектура - совокупность, подсистем, модулей, компонент и требования к интерфейсу между ними, возможно, дизайн экранных форм Исходный код - коды и структуры на языке программирования или инструмента разработки Код - скомпилированный или интерпретируемый код программы Компьютер - аппаратная платформа вычислительной машины Разработку можно представить как процесс детализации и формализации информации о ПО. Сначала это требования к системе, затем требования к ПО, затем проект ("требования" к архитектуре и внешнему виду интерфейсов), затем исходный код ("требования" к компилятору), и, наконец объектный или загрузочный код, который он должен выполняться ("требования" к компьютеру). Если доводить эту идею до логического конца, созданное ПО предъявляет свои "требования" к пользователям, которые они должны выполнять при использовании программ. То, что было задумано, бумерангом возвращается пользователю! Конечный результат, даже для небольшой разработки, представляют собой сложнейший информационный объект - огромный набор взаимосвязанных байтов, в котором изменение одного байта может привести к полной неработоспособности всего ПО. Основная идея всех методов разработки - наращивать объем информации постепенно, обеспечивая должное качество на каждом уровне представления. Реально это не однонаправленный, а итеративный процесс, так как с понижением уровня возрастают требования к качеству информации и приходится уточнять ее на более высоком уровне, и в процессе спуска могут меняться условия, в которых должно работать ПО.
- Основной закон процесса определения требований: требования должны быть документированы !!! Результатом разработки требований является документ (возможно электронный), с детальной информацией о том, что должно выполнять создаваемое ПО и какими свойствами оно должно обладать. Такой документ обычно называют "Спецификация требований к ПО" (software requirements specification, SRS ), "Функциональная спецификация", "Спецификация продукта" и т.п. Далее "Спецификация требований к ПО" будет упоминаться просто как Спецификация или СТПО. Суть не в названии, а в содержании. В идеале, содержащейся в нем информации должно быть достаточно для выполнения конструирования ПО без использования других источников требований.
- СТПО обеспечивает высокое качество передачи информации и сохранение результатов выявления и анализа требований. СТПО дает возможность правильно понять требования до начала проектирования ПО СТПО позволяет эффективно организовать параллельную работу различных участников разработки. На ее основе: Менеджеры - могут определять затраты, ресурсы, графики работ Проектировщики - могут создать архитектуру ПО Дизайнеры - могут проектировать экранные интерфейсы Программисты - могут писать программы Тестировщики - могут готовить тесты Пользователи - могут контролировать функциональность ПО Полезность СТПО не зависит от числа разработчиков. Даже при индивидуальной разработке нужна точка в проекте, которая позволяет задуматься о том, какое ПО должно быть разработано, и которая будет играть роль "соглашения" с заказчиком или руководством.
- Отсутствие СТПО или плохое ее качество: - увеличивает риск разного понимания требований участниками разработки; - создает большую опасность разработки ПО, не отвечающего потребностям заказчика или покупателя, которые могут не согласиться оплатить усилия разработчиков - затрудняет оценку трудоемкости и сроков разработки; - может больно ударить по проекту при смене разработчиков, увеличив трудозатраты (стоимость и время) на разработку. В отсутствии СТПО ее роль выполняют образы человеческой памяти со всеми их особенностями: расплывчатость, ненадежность, неустойчивость, подверженность эмоциям. Эти образы слабо соотносятся с точными и формальными конструкциями программ. При выборе того, какую информацию включать в СТПО всегда нужно помнить, что очевидно одному человеку не обязательно "очевидно" другому. Восприятие информации зависит от личного опыта, который у всех различен. Здесь лучшее правило: «очевидно то, что можно увидеть очами».
- Следует четко различать понятие "содержания" и "структуры" СТПО. Содержание определяет состав информации (что следует отразить в документе), а структура определяет организацию этой информации в документе (в каком порядке эту информацию следует представить). Содержание является более важным моментом, на который следует прежде всего обращать внимание. ЛОВУШКА. Слишком сильная ориентация на структуру часто приводит к появлению неинформативного, формального (в худшем смысле этого слова) документа.
- Функциональные требования являются основной частью СТПС, которая может включать описание сотен функций. Разбиение на функции в требованиях должно быть достаточно детальным, чтобы позволить программистам независимо выполнять свою работу. Описание каждой функции включает краткое наименование, перечень входных и выходных данных и краткое, полное и точное, описание того, что нужно сделать с входными данными, чтобы получить нужные выходные. В общем случае под входом понимается любое возможное воздействие пользователя или другой системы, а под выходом - любая возможная реакция ПО. ЛОВУШКА . Часто при определении требований упоминают только названия функции, не выделяя входные и выходные данные (полагая, что они "очевидны") и не поясняя характер обработки. Описанию каждого функционального требования присваивается постоянный уникальный идентификатор. Маркированные списки текстового редактора не годятся. Идентификатор удаленного требования повторно не используется. Если некоторая функция, обеспечивает выполнение другой функции более высокого уровня, то в ее описание включается соответствующая ссылка. Верхние функциональные уровни обычно представляют функциональные возможности разрабатываемого ПО и не описываются детально. Если у заказчика/пользователя есть жесткие требования к виду экранного интерфейса для выполнения функции или к отчету, то они включаются в описание функции. Если функция связана с реализацией известного алгоритма, то приводится его описание или дается соответствующая ссылка.
- Описание интерфейсов включает информацию о том, как ПО взаимодействует с элементами внешней системы, в которой ПО предполагается использовать. Здесь описываются типы поддерживаемых устройств и программ, форматы данных для обмена и элементы управления. Обычно это ссылка на описание API или техническую документацию уже существующих программ или устройств. Это описание не включает проектную информацию о том, как должны взаимодейст ဂ 䑃 ь между собой отдельные компоненты разрабатываемого ПО.
- При описании интерфейсов с пользователем можно ограничиться описанием общие соглашения о графическом интерфейсе: разрешение, шрифты, кнопки и иконки, цвет, элементы навигации, быстрые клавиши. Самый простой способ указать, что интерфейс должен быть похож на интерфейс некоторого известного ПО. Детали экранного интерфейса обычно рассматриваются, когда целью проекта является улучшение существующего ПО. ЛОВУШКА. Детальное описание экранного интерфейса с пользователем в требованиях может повредить, так как при согласовании требований с пользователями внимание последних может сосредоточиться на вопросах интерфейса, а не более важных вопросах функциональности. Если вопросы интерфейса важны для реализации некоторой функциональности, то детальное описание интерфейса лучше вынести в отдельную спецификацию.
- Описание свойств, которыми должно обладать разрабатываемое ПО, представляет нефункциональные требования. Эти требования могут повлиять на выбор архитектуры системы и ее функциональность, которая напрямую не должна ощущаться пользователями и определение которой отдается на откуп разработчиков. Надежность обычно характеризуется временем наработки на отказ и предполагает дополнительный контроль входных данных и поддержание целостности БД. Доступность определяет режим использования системы во времени, допустимость временного прекращения работы, время восстановления системы после сбоев. Безопасность важна для критических систем (оборона, транспорт, технологические процессы, медицина. финансы). Требования к безопасности связаны с обеспечением безопасности людей и оборудования в составе системы. Здесь описываются ограничение доступа, целостность и сохранность данных, необходимость включения функций контроля и аудита. использование определенных криптографических методов, ведение специального журнала или истории наборов данных, ограничение по взаимодействию некоторых областей программы. Производительность характеризует время реакции системы на запросы при определенных объемах данных. При описании требований к производительности важно указать в каких условиях предполагается эксплуатировать разрабатываемое ПО: - Возможное число терминалов; - Возможное число одновременно работающих пользователей; - Объем обрабатываемой информации; - Интенсивность транзакций при обычной и пиковой нагрузке; - Число транзакций; - Время отклика при выполнении отдельных операций. Мобильность касается вопросов переноса ПО на другие аппаратные платформы и операционные системы. (выделение машинозависимых компонент, использование проверенных портируемых языков программирования, определенного компилятора или подмножества языка, операционной системы и т.п.) Сопровождаемость касается вопросов простоты сопровождения (требования к модульности, интерфейсам, сложности и т.п.) ЛОВУШКА . Часто эти требования выражают словами "много", "мгновенно", "предельно точно". Эти требования нельзя проверить и их следует, по возможности, определять количественно.
- В качестве ограничений выступают факторы, напрямую ограничивающие свободу разработки: - регулирующие законодательные акты, - отраслевые стандарты и положения, - языки программирования и инструменты, - базы данных и операционные системы, - компьютерное оборудование и его характеристики, - совместимость с другими программными продуктами.
- В СТПО не включается проектная информация, если она не представляет обоснованные ограничения, с точки зрения окружающей ПО системы. При подготовке СТПО создаваемое ПО рассматривается как «черный ящик» и его внутренняя структура не должна обсуждаться в составе требований. Разработка архитектуры является прерогативой программистов. На правильность ее выбора влияет вся совокупность требований и ее не следует предлагать преждевременно до утверждения СТПО. БОЛЬШАЯ ЛОВУШКА 1 . Подмена требований проектом отвлекает внимание от выявления действительных требований и ограничивает свободу разработчиков при реализации выдвигаемых требований. Проектные решения часто включаются в требования «продвинутыми» пользователями, обычно владеющими предметом весьма поверхностно. БОЛЬШАЯ ЛОВУШКА 2 . Проектные решения могут включаться в требования самими разработчиками, если они участвуют в этом процессе. Продумывание и фиксация архитектуры ПО при подготовке требований подменяет изучение предметной области и увеличивает последующий поток изменений требований. Проектные решения следует исключать из СТПО, чтобы их место заняли настоящие требования. Правильно сформулированное требование это такое, по которому разработчик может предложить несколько решений. Иначе это не требование, а проект.
- Требования к процессу разработки или требования к организации проекта являются важной контрактной информацией. Они определяет стратегию разработки и влияют на объемы и последовательность выпуска версий, сроки реализации, организацию работ. Требования к проекту должны включаться не в СТПО, а в другие документы, такие как План проекта, Гарантии качества, Положение о проекте и т.п. ЛОВУШКА. Фиксация такой информации до утверждения требований подвергает проект риску. Ее лучше определять после того, как требования будут выявлены в полном объеме, рассмотрены участниками разработки и утверждены.
- СТПО является основой взаимодействия практически всех участников разработки, и этот документ нужно организовать так, чтобы его можно было систематически просматривать, оценивать, утверждать и изменять. Разнообразие ПО не позволяет использовать единую структуру (шаблон) СТПО. Однако, некоторые требования к структуре и содержанию спецификации (своего рода спецификация требований к СТПО) можно сформулировать. Хорошей рекомендацией по структуре СТПО является стандарт IEEE «Рекомендованная практика для спецификации программного обеспечения» ( IEEE Std 830-1998, IEEE Recommended Practice for Software Requirements Specifications , 1998). В соответствии с этим стандартом СТПО включает следующие разделы: 1. Введение . Здесь идентифицируется разрабатываемый продукт (название, версия, назначение), предполагаемый круг читателей, характеризуется содержание всего документа и даются рекомендации по порядку его изучения. Здесь же перечисляются использованные для представления требований стандарты, обозначения, сокращения и даются ссылки на другие документы и ресурсы, необходимые для понимания спецификации (название, автор, дата, место нахождения).
- Наиболее объемным и трудно поддающимся структуризации является раздел «Детальные требования». Он может включать описание сотен функций, число которых имеет тенденцию увеличивается. Поэтому, следует тщательно продумать организацию этого раздела для упрощения изучения и модификации, содержащейся в нем информации. Для контроля за требованиями и их изменениями сложные требования разбиваются на более простые, которые группируются для простоты изучения. Общие требования к продукту (обычно это нефункциональные требования) выделяются в отдельные группы. Каждому типу ПО можно подобрать свой способ группировки функций, основанный на: режиме работы - для системы управления технологическим процессом функции можно сгруппировать по режимам работы: "обучающий", "нормальный", "аварийный". категориях пользователей – для системы управления лифтами отдельные группы функций можно выделить для пассажиров, ремонтников и пожарных.
- Стандарт IEEE Std . 830-1998 дает 8 примеров структуры раздела «Детальные требования». На этом слайде представлен пример группировки требования по категориям пользователей. На следующем слайде представлен пример группировки по функциональному принципу.
- Техническое задание в соответствии с «ГОСТ 19.201-78. ЕСПД. Техническое задание. Требования к содержанию и оформлению» должно содержать следующие разделы: Введение : краткая характеристика области применения программы или программного изделия и объекта, в котором используют программу или программное изделие. Основания для разработки: документы, на основании которых ведется разработка. Назначение разработки: функциональное и эксплуатационное назначение программы или программного изделия. Требования к программе или программному изделию : требования к функциональным характеристикам; состав функций, организация входных и выходных данных, временные характеристики и т. п. требования к надежности и устойчивому функционированию, контроль входной и выходной информации, время восстановления после отказа и т.п.
- В отечественной практике разработки ПО в качестве документа, определяющего требования к ПО используется «Техническое задание» (ТЗ). Содержание этого документа часто довольно свободно трактуется. Однако в разработках, выполняемых за счет бюджетных средств, требуется буквальное соблюдение соответствующего стандарта ГОСТ 19.201. Этот стандарт имеет ряд особенностей, которые могут снизить эффективность процесса определения требований. И этому есть причины: 1. ГОСТ 19.201 рассматривает программу не как информационный, а как материальный объект (в условия эксплуатации предлагается указывать температуру и влажность окружающего воздуха, варианты и способы упаковки, условия транспортирования, места и условия хранения, складирования, сроки хранения в разных условиях), 2. ГОСТ 19.201 основное внимание уделяет структуре документа, а не на его содержанию (содержание разделов описано не достаточно детально) 3. ГОСТ 19.201 предлагает только один вариант структуры документа, а не метод ее формирования как IEEE Std . 830. 4. ГОСТ 19.201 не содержит критериев качества подготовки документа;
- Характеристика категорий пользователей разрабатываемого ПО не входит в набор требований, но позволяет более точно их понимать и правильно выбирать технические решения. Поэтому такую информацию полезно включить в текст СТПО.
- Контекстная диаграмма является самым простым, но очень полезным представлением требований. Она показывает окружение, в котором должно работать создаваемое ПО, и наглядно представляет границу продукта. Хороший стиль включать контекстную диаграмму в состав СТПО. Для обозначения внешних элементов можно использовать различные пиктограммы или просто прямоугольники. Важным является ее содержание, которое включает наименование разрабатываемого продукта, перечень всех элементов системы, с которыми продукт должен взаимодействовать и потоки данных к продукту и от него. На слайде приведен пример контекстной диаграммы для системы автоматизации управления полиграфическим производством. ЛОВУШКА . Часто при изображении контекстной диаграммы не указывают названия «стрелок», которые обозначают потоки данных. Выбрать подходящие названия на соответствующем уровне абстракции бывает не просто, но это необходимо делать для того, чтобы в дальнейшем детализировать потоки данных.
- Описание функций ПО органически связано с упоминанием данных, которые представляют в памяти компьютера объекты реального мира или некоторые абстракции. Для описания этих объектов используется понятие сущностей , определяющих классы объектов. Каждая сущность характеризуется набором атрибутов , которые, в свою очередь, могут являться сущностями. Описания функций обычно кратко ссылаются на сущности и формат этого описания не позволяет пояснить все тонкости, нужные для понимания и реализации функций. Кроме того, одни и те же сущности могут присутствовать в описании разных функций. Для детального описания сущностей есть такой полезный инструмент, как Словарь данных. Словарь данных (data dictionary) представляет собой некоторый материал (документ, база данных), в который заносится детальная информация о сущностях, важная с точки зрения автоматизации системы. Эта информация выявляется в ходе определения требований к ПО. В Словаре информация представляется в терминах прикладной области, при этом нежелательно использовать обозначения в стиле языков программирования, так как эта информация подлежит согласованию с пользователями.
- Словарь можно готовить как текстовый документ или держать в базе данных, он может входить в СТПО в качестве приложения или существовать в виде отдельного документа. Описание каждой сущности включает ее имя, краткое определение и перечень ее атрибутов. Словарь данных представляет набор таких описаний, обычно упорядоченных по алфавиту, часто сгруппированных по тесно связанным сущностям. Формат Словаря имеет второстепенное значение, но выбранному формату следует придерживаться. Можно взять какую-нибудь известную нотацию для его представления или разработать свою. Важно, чтобы правила записи были известны и позволяли правильно его понимать.
- Особенности работы с требованиями при использовании принципов и методов Экстремального программирования ( Extreme Programming , XP ). [Дэвид Астелс и др. Практическое руководство по экстремальному программированию. Пер. с англ.2002.] Определение требований выполняется в рамках процесса " Концептуализации системы ", которое в ХР происходит на протяжении всего проекта. Однако, много времени занимает создание первоначального видения системы, представляющего базовые требования. Разработка в ХР происходит в условиях постоянных изменений требований (в правой части "кривой стоимости изменений" на слайде «Цена изменений требований») . В ходе определения требований предлагается использовать понятие " метафоры ". Метафора не является требованием или объектом, а определяет то, на что объект похож (или не похож). Это скорее подсказка, в какую сторону двигаться
- Возможности создаваемого ПО в ХР представляются в форме " Историй пользователей ". История - простое описание отдельного аспекта будущего ПО. Истории формулируются заказчиками на совместном собрании с разработчиками и записываются на карточках. Истории уникально нумеруются и оцениваются с точки зрения трудоемкости реализации в " пунктах " - идеальных человеко/неделях. История больше 3 пунктов ("эпопея") разбивается на несколько более простых с тем же номером, но пометкой "Часть1","Часть2". Номер Истории и оценка трудоемкости записывается на карточку, на обратной ее стороне пишется "приемочный" тест. Краткость Историй, их довольно высокий уровень абстракции с отсутствием деталей компенсируется постоянным участием в проекте Заказчика. Таким образом, детали требований передаются «оральным» способом.
- Роль документа об Образе продукта играет " Карточка представления о системе " (20-30 слов), которая отвечает на вопрос "Зачем заказчику разрабатываемое ПО". Все Истории проекта образуют " Набор проекта ", они представляют текущее понимание продукта Заказчиком. Истории можно добавлять и выбрасывать. ХР разработка выполняется итерациями (2-6 недель). Набор Историй для очередной итерации называется " Стеком " (карточки стека обвязываются резинкой). Истории во всех стеках имеют сквозную нумерацию. Другой способ управления объемом историй - удаление " декораций " - несущественных свойств Истории, без которых можно обойтись. Для оперативного планирования и реализации Истории методом мозгового штурма разбиваются на " Задачи ". Задач может быть много. Часть из них вытекает из Историй, а часть неочевидна и связана с реализацией. Задачи являются инструментом детализации требований и инструментом планирования. Перед реализацией Задачи, для нее пишутся автоматизированные "модульные" тесты, по которым определяется готовность включения модулей в продукт.