1-software_engineering_requirements (1133541), страница 3
Текст из файла (страница 3)
С точки зрения маркетинга программного обеспечения, как отмечаетВигерс, feature это «группа требований, узнаваемая заинтересованными лицами, которыевовлечены в процесс принятия решения по приобретению ПО – это список <отличительныхособенностей или возможностей, характеристик>, присутствующий в описании продукта».
В то жевремя, Леффингвелл и Видриг (D.Leffingwell, D. Widrig, Managing Software Requirements: A Use CaseApproach, Second Edition, 2003) определяют feature как “сервисы, которые оказывает система дляудовлетворения одной или более потребностей заинтересованных лиц (stakeholders needs)”. Имиже отмечается, что в реальных проектах могут быть не определены stakeholders needs (а их частовыделяют, особенно если у проекта/продукта есть много заинтересованных лиц со своимипотребностями, и эти потребности могут носить взаимоисключающий характер), но существоватьCopyright © Сергей Орлик, 2004-2010.http://swebok.sorlik.ru6Основы программной инженерии (по SWEBOK)Программная инженерия. Программные требования.features могут и самостоятельно (как и stakeholder needs), и конечно же возможно существование иstakeholder needs и features со взаимной трассировкой.Развивая тему features -- Kurt Bittner & Ian Spence в своей книге “Use Case Modeling” (Kurt Bittner, IanSpence.
Use Case Modeling, 2002), дают схожее, хотя и более формальное определение features.Они отмечают, что features могут быть как относящимся к функциональным, так и кнефункциональным требованиям. И могут изменяться от версии к версии продукта.Анализируя различные источники на предмет работы с features, следует отметить следующее:С точки зрения инженерии требований, features являются самостоятельным артефактом, которыйможет быть соотнесен как с функциональными требованиями, так и с нефункциональными (в т.ч. сограничениями проектирования или атрибутами качества).Необходимо также отметить, что Features обладают определенным дуализмом в своейинтерпретации, зависимым от контекста конкретного продукта – с одной стороны это может быть«тот самый список характеристик, указанный на коробке продукта» в случае создания «коробочногоПО», с другой стороны это может список высокоуровневых возможностей системы, например призаказной разработке ПО автоматизации бизнес-процессов конкретной организации.Features могут быть разного уровня детализации – от выражения высокоуровневых возможностейсистемы (например, «Расчет заработной платы …»), до достаточно конкретных требований(например, «Автоматическое уведомление Клиента по e-mail о резервировании товара на складе»)1.4 Независимые свойства (Emergent Properties) – эти свойства обозначают требования, которыеадресованы к системе в целом, и не могут быть соотнесены с отдельнымы ее элементами.
Т.е.данные требования относятся к тому синергетическому эффекту, которым может обладать такаясистема («целое больше, чем сумма его частей»). Примером может служить требования к«пропускной способности» коллцентра, которая будут зависеть от того, каким образом будутвзаимодействовать коммуникационное оборудование, оператор и программное обеспечение вконкретных условиях.1.5 Требования с количественной оценкой (Quantifiable Requirements) – требования, поддающиесяколичественному определению/измерению, например, система должна обеспечить пропускнуюспособность “столько-то запросов в секунду”; в то же самое время, крайне важно понимать, чтопостановка вопроса (то есть формулирование требования) в форме “система должна обеспечитьрост пропускной способности” без указания конкретных количественных характеристик являетсяпросто некорректно определенным требованием.По мнению авторов, при этом, например, требование “система должна вести журнал подключенийпользователей” может и должно детализироваться с точки зрения описания информации, которуюнеобходимо сохранять в журнале, однако, такое требование уже не будет являться количественнымтребованием.
А требование с формулировкой “система должна обладать интуитивно-понятнымпользовательским интерфейсом” - непроверяем. В определенных случаях, по мнению автора книги,это может выглядеть просто издевкой, даже не являясь изначально таковой – все зависит от точкизрения: например, в устах “целевого” пользователя специализированного программного обеспечения– системного администратора, привыкшего работать в kshell (популярной командной оболочкеUnix/Linux), объясняющего свои потребности аналитику, фиксирующему запросы пользователя ипривыкшего оперировать Microsoft Office ;) Может ли такое требование быть переформулированои/или детализировано для адекватности интерпретации? Да.
Например, так – средний показательошибок оператора не должен превышать 2% от объема вводимой информации и 85% пользователейдолжны дать положительную оценку прототипу пользовательского интерфейса на этапе опытнойэксплуатации.Такие требования должны однозначно отвечать на вопросы, предполагающие ответы с численнымивеличинами – как часто? насколько быстро? в каком количестве? и т.п.Большинство требований с количественной оценкой относится к атрибутам качества.В качестве примера можно привести реальное требование, присутствующее в реальном проекте поэлектронному документообороту: “Система должна производить поиск документов <определенноговида> за время, не превышающее 5 секунд”.
Это типичное требование с количественной оценкой, вкотором определена верхняя граница диапазона времени, за которое должен быть осуществленпоиск документов. Несомненно, этот атрибут качества системы существует в контекстеCopyright © Сергей Орлик, 2004-2010.http://swebok.sorlik.ru7Основы программной инженерии (по SWEBOK)Программная инженерия. Программные требования.определенного функционального требования о возможности поиска документов по определеннымкритериям. И этот контекст или связь должна быть определена либо явно, в рамках иерархиитребований, либо посредством трассировки, между требованиями разных видов (функционального иатрибута качества). Примечательно, что Вигерс в своей книге выделяет требования попроизводительности системы в отдельный вид требований, тем не менее входящих в понятиенефункциональных требований или атрибутов качества.1.6 Системные требования и программные требования (System Requirements and SoftwareRequirements) – данное разделение базируется на определении “системы”, данном INCOSE(International Council on Systems Engineering) “комбинация взаимодействующих элементов<созданная> для достижения определенных целей; может включать аппаратные средства,программное обеспечение, встроенное ПО, другие средства, людей, информацию, техники(подходы), службы и другие поддерживающие элементы”; таким образом, подразумевается, чтосистема является более ѐмким понятием, чем программное обеспечения и включает окружение, вкотором функционирует ПО, как таковое; отсюда, естественным образом, вытекают требования ксистеме в целом и программному обеспечению (или программной системе), в частности.
Часто влитературе по управлению требованиями встречается описание системных требований как“пользовательских требований” (user requirements), SWEBOK ограничивает применение понятия“пользовательское требование” требованиями к системе конечных пользователей/заказчиков.Системные требования по SWEBOK, в свою очередь, окружают пользовательские требования (илитребования других заинтересованных лиц – stakeholders, например, регулирование полномочий) безуказания идентифицируемого источника-человека.2.
Процесс работы с требованиями (Requirements Process)Данная секция вводит процессы, касающиеся вопросов работы с требованиями, и в определеннойстепени “сшивает” в единое целое оставшиеся пять секций области знаний, посвященнойтребованиям к программному обеспечению.Цель данной темы, в соответствии с SWEBOK, дать понимание того, что такое процесс работы стребованиями, как таковой. В русском языке также устойчиво используется его название как“процесс определения требований”. мы его будем использовать взаимозаменяемым образом,подразумевая весь процесс работы с требованиями по SWEBOK.Что ж, рассмотрим структуру декомпозиции тем процесса работы с требованиями:2.1 Модель процесса определения требований:Не является дискретным; это постоянно действующий процесс на всех этапах жизненногоцикла программного обеспечения.
Процесс работы с требованиями инициируется в началепроекта и продолжается на протяжении всего жизненного цикла, в плоть до завершенияпроекта. Например, функциональные тесты создаются в соответствии с функциональнымитребованиями к программной системе и обычно выполняются, в том числе, при проведенииприемочных испытаний. Как вы уже заметили, автор использовал все же “работа стребованиями” для акцентирования внимания на том факте, что требования не только“определяются” на начальных этапах работ, но и модифицируются и используются во всемжизненном цикле.Идентифицирует программные требования как элементы конфигурации (в терминахконфигурационного обеспечения) и контролирует их с использованием тех же практикконфигурационного управления, что и для других активов программных проектов (например,файлов или запросов на изменения).Требует адаптации к проектному и/или организационному контексту, в рамках котороговедется соответствующий программный проект.В частности, тема процесса определения требований касается тех вопросов, которые охватываютсяв рамках сбора, анализа, специфицирования и утверждения требований с точки зрения организацииэтих видов деятельности для различных типов проектов и значимости тех или иных ограничений поотношению к процессу.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
