commit - e3b3be103c332a9662c829b24c37c06c2ab1b7a2
commit + dcaa803f0887dee08029ae7d380158de4dfc3960
blob - 49f2268b51feb173bf128407fb0d4fb5b7c5d9c6
blob + 933593d398673bf66ec035c76972b90db02dbe94
--- 1_software_requirements.markdown
+++ 1_software_requirements.markdown
Программные требования – 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. Такая структура
отмечаются его основные характеристики, например, верифицируемость
(проверяемость) требования.
-по мнению авторов, необходимо обратить внимание на следующие определения
-понятия “требование” (на основе работ вигерса и стандарта IEEE Standard
+По мнению авторов, необходимо обратить внимание на следующие определения
+понятия “требование” (на основе работ Вигерса и стандарта IEEE Standard
Glossary Of Software Engineering Terminology, 1990):
условие или возможность, требуемая пользователем для решения задач или
обеспечения.
- пользовательские требования (user requirements) – описывают цели/задачи
пользователей системы, которые должны достигаться/выполняться пользователями
-при помощи создаваемой программной системы. эти требования часто представляют в
+при помощи создаваемой программной системы. Эти требования часто представляют в
виде вариантов использования (use cases).
- функциональные требования (functional requirements) – определяют
функциональность (поведение) программной системы, которая должна быть создана
- бизнес-правила (business rules) – включают или связаны с корпоративными
регламентами, политиками, стандартами, законодательными актами,
внутрикорпоративными инициативами (например, стремление достичь зрелости
-процессов по cmmi 4-го уровня), учетными практиками, алгоритмами вычислений и
-т.д. на самом деле, достаточно часто можно видеть недостаточное внимание такого
+процессов по CMMI 4-го уровня), учетными практиками, алгоритмами вычислений и
+т.д. На самом деле, достаточно часто можно видеть недостаточное внимание такого
рода требованиям со стороны сотрудников ит-департаментов и, в частности,
-технических специалистов, вовлеченных в проект. business rules group дает
+технических специалистов, вовлеченных в проект. Business Rules Group дает
понимание бизнес-правила, как “положения, которые определяют или ограничивают
некоторые аспекты бизнеса. они подразумевают организацию структуры бизнеса,
-контролируют или влияют на поведение бизнеса”. бизнес-правила часто определяют
+контролируют или влияют на поведение бизнеса”. Бизнес-правила часто определяют
распределение ответственности в системе, отвечая на вопрос “кто будет
осуществлять конкретный вариант, сценарий использования” или диктуют появление
некоторых функциональных требований.
- в контексте дисциплины управления проектами (уже вне проекта разработки
+ В контексте дисциплины управления проектами (уже вне проекта разработки
программного обеспечения, но выполнения бизнес-проектов и бизнес-процессов)
такие правила обладают высокой значимостью и, именно они, часто определяют
ограничения бизнес-проектов, для автоматизации которых создается
соответствующее программное обеспечение.
- внешние интерфейсы (external interfaces) – часто подменяются
-“пользовательским интерфейсом”. на самом деле вопросы организации
+“пользовательским интерфейсом”. На самом деле вопросы организации
пользовательского интерфейса безусловно важны в данной категории требований,
однако, конкретизация аспектов взаимодействия с другими системами, операционной
средой (например, запись в журнал событий операционной системы), возможностями
- атрибуты качества (quality attributes) – описывают дополнительные
характеристики продукта в различных “измерениях”, важных для пользователей
-и/или разработчиков. атрибуты касаются вопросов портируемости,
+и/или разработчиков. Атрибуты касаются вопросов портируемости,
интероперабельности (прозрачности взаимодействия с другими системами),
целостности, устойчивости и т.п.
- ограничения (constraints) – формулировки условий, модифицирующих требования
-или наборы требований, сужая выбор возможных решений по их реализации. в
+или наборы требований, сужая выбор возможных решений по их реализации. В
частности, к ним могут относиться параметры производительности, влияющие на
выбор платформы реализации и/или развертывания (протоколы, серверы приложений,
баз данных, ...), которые, в свою очередь, могут относиться, например, к
- системные требования (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).
Бизнес-правила могут быть не только использованы при определении требований к
-разрабатываемому по, но и могут отдельно оформляться в дизайне по (класс или
+разрабатываемому ПО, но и могут отдельно оформляться в дизайне ПО (класс или
группа классов), отражаясь в конечном итоге в программном коде на определенном
-языке программирования. существуют специализированные инструментальные средства
+языке программирования. Существуют специализированные инструментальные средства
и библиотеки, позволяющие разрабатывать и поддерживать приложения, интенсивно
использующие бизнес-правила.
требований можно отметить, вернее дать одно из пояснений, почему бп относят к
нефункциональным требованиям: например, при написании определенного шага в
сценарии 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) разрабатываемого продукта. Иногда, такие
Цель данной темы, в соответствии с SWEBOK, дать понимание того, что такое
процесс работы с требованиями, как таковой. В русском языке также устойчиво
-используется его название как “процесс определения требований”. мы его будем
+используется его название как “процесс определения требований”. Мы его будем
использовать взаимозаменяемым образом, подразумевая весь процесс работы с
требованиями по SWEBOK.
