commit dcaa803f0887dee08029ae7d380158de4dfc3960 from: Mike Voznesensky via: Sergey Bronnikov date: Sat Jan 20 11:36:22 2024 UTC Added Capitalizer and UPPERCASE * Many sentences started with a small letter * Proper names and terms started with a samll letter * Caption to the drawings started with a small letter commit - e3b3be103c332a9662c829b24c37c06c2ab1b7a2 commit + dcaa803f0887dee08029ae7d380158de4dfc3960 blob - 49f2268b51feb173bf128407fb0d4fb5b7c5d9c6 blob + 933593d398673bf66ec035c76972b90db02dbe94 --- 1_software_requirements.markdown +++ 1_software_requirements.markdown @@ -8,33 +8,33 @@ SWEBOK. Программные требования – software requirements – свойства программного обеспечени, которые должны быть надлежащим образом представлены в нём для -решения конкретных практических задач. данная область знаний касается вопросов +решения конкретных практических задач. Данная область знаний касается вопросов извлечения (сбора), анализа, специфицирования и утверждения требований. Опыт индустрии информационных технологий однозначно показывает, что вопросы, связанные с управлением требованиями, оказывают критически-важное влияние на программные проекты, в определенной степени - на сам факт возможности успешного -завершения проектов. только систематичная работа с требованиями позволяет +завершения проектов. Только систематичная работа с требованиями позволяет корректным образом обеспечить моделирование задач реального мира и формулирование необходимых приемочных тестов для того, чтобы убедиться в соответствии создаваемых программных систем критериям, заданным реальными практическими потребностями. На практике часто применяется подход, используемый в различных методологиях -разработки по и базирующийся на определении групп требований к продукту. такой +разработки по и базирующийся на определении групп требований к продукту. Такой подход обычно включает группы (типы, категории) требований, например: системные, программные, функциональные, нефункциональные (в частности, атрибуты -качества) и т.п. классический пример (см. рисунок 1) высокоуровневого +качества) и т.п. Классический пример (см. рисунок 1) высокоуровневого структурирования групп требований как требований к продукту описан в работах -одного из классиков дисциплины управления требованиями – карла вигерса. +одного из классиков дисциплины управления требованиями – Карла Вигерса. -![рисунок 1. уровни требований по вигерсу [вигерс, 2003, с.8, рис. 1-1]](images/requirements_wiegers.jpg) +![рисунок 1. Уровни требований по Вигерсу [Вигерс, 2003, с.8, рис. 1-1]](images/requirements_wiegers.jpg) SWEBOK охватывает не только вопросы структурирования и систематизации требований, но и различных процессов этапов и процессов работы с требованиями, а также некоторые практические соображения. -![рисунок 2. область знаний “программные требования” [swebok, 2004, с.2-2, рис. 1]](images/requirements_area_small.jpg) +![рисунок 2. Область знаний “Программные требования” [swebok, 2004, с.2-2, рис. 1]](images/requirements_area_small.jpg) Сама же структура обсуждаемой области знаний в большой степени совместима со стандартами IEEE 12207.x, ISO/IEC, ГОСТ Р ИСО/МЭК 12207. Такая структура @@ -67,8 +67,8 @@ SWEBOK охватывает не только вопр отмечаются его основные характеристики, например, верифицируемость (проверяемость) требования. -по мнению авторов, необходимо обратить внимание на следующие определения -понятия “требование” (на основе работ вигерса и стандарта IEEE Standard +По мнению авторов, необходимо обратить внимание на следующие определения +понятия “требование” (на основе работ Вигерса и стандарта IEEE Standard Glossary Of Software Engineering Terminology, 1990): условие или возможность, требуемая пользователем для решения задач или @@ -112,7 +112,7 @@ Glossary Of Software Engineering Terminology, 1990): обеспечения. - пользовательские требования (user requirements) – описывают цели/задачи пользователей системы, которые должны достигаться/выполняться пользователями -при помощи создаваемой программной системы. эти требования часто представляют в +при помощи создаваемой программной системы. Эти требования часто представляют в виде вариантов использования (use cases). - функциональные требования (functional requirements) – определяют функциональность (поведение) программной системы, которая должна быть создана @@ -124,25 +124,25 @@ Glossary Of Software Engineering Terminology, 1990): - бизнес-правила (business rules) – включают или связаны с корпоративными регламентами, политиками, стандартами, законодательными актами, внутрикорпоративными инициативами (например, стремление достичь зрелости -процессов по cmmi 4-го уровня), учетными практиками, алгоритмами вычислений и -т.д. на самом деле, достаточно часто можно видеть недостаточное внимание такого +процессов по CMMI 4-го уровня), учетными практиками, алгоритмами вычислений и +т.д. На самом деле, достаточно часто можно видеть недостаточное внимание такого рода требованиям со стороны сотрудников ит-департаментов и, в частности, -технических специалистов, вовлеченных в проект. business rules group дает +технических специалистов, вовлеченных в проект. Business Rules Group дает понимание бизнес-правила, как “положения, которые определяют или ограничивают некоторые аспекты бизнеса. они подразумевают организацию структуры бизнеса, -контролируют или влияют на поведение бизнеса”. бизнес-правила часто определяют +контролируют или влияют на поведение бизнеса”. Бизнес-правила часто определяют распределение ответственности в системе, отвечая на вопрос “кто будет осуществлять конкретный вариант, сценарий использования” или диктуют появление некоторых функциональных требований. - в контексте дисциплины управления проектами (уже вне проекта разработки + В контексте дисциплины управления проектами (уже вне проекта разработки программного обеспечения, но выполнения бизнес-проектов и бизнес-процессов) такие правила обладают высокой значимостью и, именно они, часто определяют ограничения бизнес-проектов, для автоматизации которых создается соответствующее программное обеспечение. - внешние интерфейсы (external interfaces) – часто подменяются -“пользовательским интерфейсом”. на самом деле вопросы организации +“пользовательским интерфейсом”. На самом деле вопросы организации пользовательского интерфейса безусловно важны в данной категории требований, однако, конкретизация аспектов взаимодействия с другими системами, операционной средой (например, запись в журнал событий операционной системы), возможностями @@ -153,12 +153,12 @@ Glossary Of Software Engineering Terminology, 1990): - атрибуты качества (quality attributes) – описывают дополнительные характеристики продукта в различных “измерениях”, важных для пользователей -и/или разработчиков. атрибуты касаются вопросов портируемости, +и/или разработчиков. Атрибуты касаются вопросов портируемости, интероперабельности (прозрачности взаимодействия с другими системами), целостности, устойчивости и т.п. - ограничения (constraints) – формулировки условий, модифицирующих требования -или наборы требований, сужая выбор возможных решений по их реализации. в +или наборы требований, сужая выбор возможных решений по их реализации. В частности, к ним могут относиться параметры производительности, влияющие на выбор платформы реализации и/или развертывания (протоколы, серверы приложений, баз данных, ...), которые, в свою очередь, могут относиться, например, к @@ -166,35 +166,35 @@ Glossary Of Software Engineering Terminology, 1990): - системные требования (system requirements) – иногда классифицируются как составная часть группы функциональных требований (не путайте с как таковыми -“функциональными требованиями”). описывают высокоуровневые требования к +“функциональными требованиями”). Описывают высокоуровневые требования к программному обеспечению, содержащему несколько или много взаимосвязанных -подсистем и приложений. при этом, система может быть как целиком программной, -так и состоять из программной и аппаратной частей. в общем случае, частью +подсистем и приложений. При этом, система может быть как целиком программной, +так и состоять из программной и аппаратной частей. В общем случае, частью системы может быть персонал, выполняющий определенные функции системы, например, авторизация выполнения определенных операций с использованием программно-аппаратных подсистем. -Необходимо сделать несколько важных замечаний по бизнес-правилам. бизнес +Необходимо сделать несколько важных замечаний по бизнес-правилам. Бизнес правила, как таковые, являются предметом пристального изучения различных специалистов в области как бизнес-моделирования, так и программной инженерии в -целом. практика разработки программных требований включает идентификацию и -описание бизнес-правил как самостоятельных артефактов. например, методология -rup выделяет отдельный артефакт business rule в рамках дисциплины business -modeling. все бизнес-правила, в рамках данной дисциплины, идентифицируются и -описываются в документе business rules document. при разработке требований, в +целом. Практика разработки программных требований включает идентификацию и +описание бизнес-правил как самостоятельных артефактов. Например, методология +RUP выделяет отдельный артефакт Business Rule в рамках дисциплины Business +Modeling. Все бизнес-правила, в рамках данной дисциплины, идентифицируются и +описываются в документе business rules document. При разработке требований, в сценариях use cases обычно включается ссылка на уже описанное бизнес-правило. -скотт амблер (см. www.agilemodeling.com/artifacts/) так же выделяет -бизнес-правило как один из артефактов, который используют в семействе agile +Скотт Амблер (см. www.agilemodeling.com/artifacts/) так же выделяет +бизнес-правило как один из артефактов, который используют в семействе Agile методологий. В настоящее время разработаны методы и подходы формального представления -бизнес-правил, вплоть до формальных языков описания (использование ocl – object -constraint language, brml – business rules markup language). +бизнес-правил, вплоть до формальных языков описания (использование OCL – Object +Constraint Language, BRML – Business Rules Markup Language). Бизнес-правила могут быть не только использованы при определении требований к -разрабатываемому по, но и могут отдельно оформляться в дизайне по (класс или +разрабатываемому ПО, но и могут отдельно оформляться в дизайне ПО (класс или группа классов), отражаясь в конечном итоге в программном коде на определенном -языке программирования. существуют специализированные инструментальные средства +языке программирования. Существуют специализированные инструментальные средства и библиотеки, позволяющие разрабатывать и поддерживать приложения, интенсивно использующие бизнес-правила. @@ -202,17 +202,17 @@ constraint language, brml – business rules markup l требований можно отметить, вернее дать одно из пояснений, почему бп относят к нефункциональным требованиям: например, при написании определенного шага в сценарии use case, используется ссылка на бизнес правило: «… система производит -расчет стоимости в соответствии с бизнес-правилом bp41 …». в свою очередь -данное бизнес-правило может определять алгоритм расчета стоимости. т.е. налицо +расчет стоимости в соответствии с бизнес-правилом BP41 …». В свою очередь +данное бизнес-правило может определять алгоритм расчета стоимости. Т.е. налицо «с соблюдением каких условий система делает расчет». -Одним из наиболее известных специалистов по br является рональд росс, автор -книги «principles of the business rule approach» (ronald g. ross. «principles -of the business rule approach», 2003). +Одним из наиболее известных специалистов по BR является Рональд Росс, автор +книги «Principles of the Business Rule Approach» (Ronald G. Ross. «Principles +of the Business Rule Approach», 2003). Наравне с представленной классификацией требований, могут использоваться и другие подходы. Даже в рамках этой классификации, существуют и различные взгляды на ее -интерпретацию и детализацию. Например, как результат определения целевой +интерпретацию и детализацию. Например, как результат определения целевой аудитории и в рамках маркетинговой стратегии продвижения тиражируемого решения, возможно определять высокоуровневые возможности (ключевые характеристики, особенности) – “фичи” (features) разрабатываемого продукта. Иногда, такие @@ -346,7 +346,7 @@ kshell (популярной командной обо Цель данной темы, в соответствии с SWEBOK, дать понимание того, что такое процесс работы с требованиями, как таковой. В русском языке также устойчиво -используется его название как “процесс определения требований”. мы его будем +используется его название как “процесс определения требований”. Мы его будем использовать взаимозаменяемым образом, подразумевая весь процесс работы с требованиями по SWEBOK.