1-software_engineering_requirements (1133541), страница 2
Текст из файла (страница 2)
рисунок 2). Кроме того, данная область знаний тесно связана соследующими областями: Software Design Software Testing Software Maintenance Software Configuration Management Software Engineering Management Software Engineering Process Software Quality1. Основы программных требований (Software Requirements Fundamentals)Эта секция включает определение программных требований как таковых и описывает основные типытребований и их отличия: к продукту и процессу, функциональные и нефункциональные требованияи т.п.Темы данной секции:1.1 Определение требований (Definition of a Software Requirement) – в данном случаеподразумевается не процесс определения (извлечения, сбора, формирования, формулирования)требований, а дается само понятие “требования”, как такового, и отмечаются его основныехарактеристики, например, верифицируемость (проверяемость) требования.По мнению авторов, необходимо обратить внимание на следующие определения понятия“требование” (на основе работ Вигерса и стандарта IEEE Standard Glossary of Software EngineeringTerminology, 1990): Условие или возможность, требуемая пользователем для решения задач или достиженияцелей. Условие или возможность, которые должны удовлетворяться системой/компонентом системыили которыми система/компонент системы должна обладать для обеспечения условийконтракта, стандартов, спецификаций или др.
регулирующими документами. Документальная репрезентация (зафиксированное представление, определение, описание)условий или возможностей, перечисленных в предыдущих пунктах.1.2 Требования к продукту и процессу (Product and Process Requirements) – проводитсяразграничение соответствующих требований как свойств продукта, который необходимо получить, ипроцесса, с помощью которого продукт будет создаваться; отмечается, что ряд требований можетбыть заложен неявно и программные требования могут порождать требования к процессу, например:работа в режиме 24x7 (как бизнес-требование) наверняка приведет к ограничению выбора тех илииных программных средств, платформ развертывания и архитектурных решений; в свою очередь,выбор платформы J2EE (Java 2 Enterprise Edition) и ее реализации в виде конкретного сервераприложений практически наверняка потребует применения модульного тестирования (Unit testing) какпрактики процесса разработки и JUnit, как инструмента реализации этой практики.1.3 Функциональные и нефункциональные требования (Functional and Non-functional Requirements) –функциональные требования задают “что” система должна делать; нефункциональные – ссоблюдением “каких условий” (например, скорость отклика при выполнении заданной операции)По мнению авторов, в определенной степени, систематизируя работы Вигерса, Лефингвелла иВидрига, Коберна, а также других экспертов, необходимо привести классификацию различныхкатегорий (видов) требований и связанных с ними понятий, важнейших с точки зрения их пониманияи дальнейшего практического применения:Потребности (needs) – отражают проблемы бизнеса, персоналии или процесса, которыедолжны быть соотнесены с использованием или приобретением системы.Copyright © Сергей Орлик, 2004-2010.http://swebok.sorlik.ru4Основы программной инженерии (по SWEBOK)Программная инженерия.
Программные требования.Группа функциональных требованийoБизнес-требования (Business Requirements) – определяют высокоуровневые целиорганизации или клиента (потребителя) – заказчика разрабатываемого программногообеспечения.oПользовательские требования (User Requirements) – описывают цели/задачипользователей системы, которые должны достигаться/выполняться пользователямипри помощи создаваемой программной системы. Эти требования часто представляютв виде вариантов использования (Use Cases).oФункциональные требования (Functional Requirements) – определяютфункциональность (поведение) программной системы, которая должна быть созданаразработчиками для предоставления возможности выполнения пользователямисвоих обязанностей в рамках бизнес-требований и в контексте пользовательскихтребований.Группа нефункциональных требований (Non-Functional Requirements)oБизнес-правила (Business Rules) – включают или связаны с корпоративнымирегламентами, политиками, стандартами, законодательными актами,внутрикорпоративными инициативами (например, стремление достичь зрелостипроцессов по CMMI 4-го уровня), учетными практиками, алгоритмами вычислений ит.д.
На самом деле, достаточно часто можно видеть недостаточное внимание такогорода требованиям со стороны сотрудников ИТ-департаментов и, в частности,технических специалистов, вовлеченных в проект. Business Rules Group даетпонимание бизнес-правила, как “положения, которые определяют или ограничиваютнекоторые аспекты бизнеса.
Они подразумевают организацию структуры бизнеса,контролируют или влияют на поведение бизнеса”. Бизнес-правила часто определяютраспределение ответственности в системе, отвечая на вопрос “кто будетосуществлять конкретный вариант, сценарий использования” или диктуют появлениенекоторых функциональных требований.В контексте дисциплины управления проектами (уже вне проекта разработкипрограммного обеспечения, но выполнения бизнес-проектов и бизнес-процессов)такие правила обладают высокой значимостью и, именно они, часто определяютограничения бизнес-проектов, для автоматизации которых создаетсясоответствующее программное обеспечение.oВнешние интерфейсы (External Interfaces) – часто подменяются “пользовательскиминтерфейсом”.
На самом деле вопросы организации пользовательского интерфейсабезусловно важны в данной категории требований, однако, конкретизация аспектоввзаимодействия с другими системами, операционной средой (например, запись вжурнал событий операционной системы), возможностями мониторинга приэксплуатации – все это не столько функциональные требования (к которым ошибочноприписывают иногда такие характеристики), сколько вопросы интерфейсов, так какфункциональные требования связаны непосредственно с функциональностьюсистемы, направленной на решение бизнес-потребностей.oАтрибуты качества (Quality Attributes) – описывают дополнительные характеристикипродукта в различных “измерениях”, важных для пользователей и/или разработчиков.Атрибуты касаются вопросов портируемости, интероперабельности (прозрачностивзаимодействия с другими системами), целостности, устойчивости и т.п.oОграничения (Constraints) – формулировки условий, модифицирующих требованияили наборы требований, сужая выбор возможных решений по их реализации.
Вчастности, к ним могут относиться параметры производительности, влияющие навыбор платформы реализации и/или развертывания (протоколы, серверыприложений, баз данных, ...), которые, в свою очередь, могут относиться, например, квнешним интерфейсам.Copyright © Сергей Орлик, 2004-2010.http://swebok.sorlik.ru5Основы программной инженерии (по SWEBOK)Программная инженерия. Программные требования.Системные требования (System Requirements) – иногда классифицируются как составнаячасть группы функциональных требований (не путайте с как таковыми “функциональнымитребованиями”). Описывают высокоуровневые требования к программному обеспечению,содержащему несколько или много взаимосвязанных подсистем и приложений.
При этом,система может быть как целиком программной, так и состоять из программной и аппаратнойчастей. В общем случае, частью системы может быть персонал, выполняющийопределенные функции системы, например, авторизация выполнения определенныхопераций с использованием программно-аппаратных подсистем.Необходимо сделать несколько важных замечаний по бизнес-правилам. Бизнес правила, кактаковые, являются предметом пристального изучения различных специалистов в области какбизнес-моделирования, так и программной инженерии в целом.
Практика разработки программныхтребований включает идентификацию и описание бизнес-правил как самостоятельных артефактов.Например, методология RUP выделяет отдельный артефакт Business Rule в рамках дисциплиныBusiness Modeling. Все бизнес-правила, в рамках данной дисциплины, идентифицируются иописываются в документе Business Rules Document. При разработке требований, в сценариях UseCases обычно включается ссылка на уже описанное бизнес-правило. Скотт Амблер (см.www.agilemodeling.com/artifacts/) так же выделяет бизнес-правило как один из артефактов, которыйиспользуют в семействе Agile методологий.В настоящее время разработаны методы и подходы формального представления бизнес-правил,вплоть до формальных языков описания (использование OCL – Object Constraint Language, BRML –Business Rules Markup Language).Бизнес-правила могут быть не только использованы при определении требований кразрабатываемому ПО, но и могут отдельно оформляться в дизайне ПО (класс или группа классов),отражаясь в конечном итоге в программном коде на определенном языке программирования.Существуют специализированные инструментальные средства и библиотеки, позволяющиеразрабатывать и поддерживать приложения, интенсивно использующие бизнес-правила.Рассматривая бизнес-правила, как артефакты относящиеся к области программных требованийможно отметить, вернее дать одно из пояснений, почему БП относят к нефункциональнымтребованиям: Например, при написании определенного шага в сценарии use case, используетсяссылка на бизнес правило: «… система производит расчет стоимости в соответствии с бизнесправилом BP41 …».
В свою очередь данное бизнес-правило может определять алгоритм расчетастоимости. Т.е. налицо «с соблюдением каких условий система делает расчет».Одним из наиболее известных специалистов по BR является Рональд Росс, автор книги «Principles ofthe Business Rule Approach» (Ronald G.
Ross. «Principles of the Business Rule Approach», 2003).Наравне с представленной классификацией требований, могут использоваться и другие подходы.Даже в рамках этой классификации, существуют и различные взгляды на ее интерпретацию идетализацию. Например, как результат определения целевой аудитории и в рамках маркетинговойстратегии продвижения тиражируемого решения, возможно определять высокоуровневыевозможности (ключевые характеристики, особенности) – “фичи” (features) разрабатываемогопродукта. Иногда, такие возможности детализируются в смысле функциональных требований внекоторых agile-техниках, например, FDD – Feature-Driven Development (как вы видите вплоть досамого названия целого комплекса практик, метода разработки).Вигерс, описывает feature как “множество логически связанных функциональных требований,которые предоставляют определенные возможности для пользователя и удовлетворяютбизнес-целям <организации>”.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
