Принципы работы с требованиями к ПО. Леффингуэлл (2002) (1186169), страница 48
Текст из файла (страница 48)
ный класс, называемый оеразьичениями проекэьи(зевания, звак что оно будет отделено от обычных требований, описывающих только внешзые поведение. Тем не менее это именно ог раничение реализации, налагаемое на команду разработчиков. (Кстати, если вы думаете, что этот. пример нереалистичен, напомним, что до конца 1990-х обычным требованием Министерства обороны США к разработчикам программного обеспечения было "создавать системы, используя язык Ада".) Однако рассуждая в этом примере о Ч!зиа! Ваз!с, мы можем пропустить более тонкий и, возможно, более важный момент анализа требования: почему инффмакия об обнару зкенных дефектах долзкна пфвдосвкзвляться е виде отчетадиаграммы? Почему не круговая диаграмма или другое представление информации? Подразумевает ли слово "отчет" некий бумажный документ или информация может отображаться на экране компьютера? Нужно ли хранить эту информацию с тем, чтобы ее можно было передавать другим прсг граммам или пересылать в корпоративную сеть? Функцию, описанную в документе- концепции, практически всегда можно осуществить множеством способов, причем нект торые из них имеют совершенно определенные реализационные последствия.
Во многих случаях на описание проблемы, которое служит основой формулирования требования, влияют представления пользователя о возможных способах ее решения. То же верно и по отношению к разработчикам, которые совместно с пользователем участвуют в процессе формулирования функций документа-концепции и требований. Как гласит старая пословица, если ваш единственный инструмент — молоток, все ваши проблеьзы похожи на гвозди. Но нам нужно проявлять бдительность, чтобы необязательные ограничения реализации не попадали в требования, и мы должны удалять подобные ограни.
чения везде, где это возможно. Больше внимания требованиям, а не проектированию До сих пор мы трактовали требования к программному обеспечению, решения и ог раничения проектирования так, как если бы они были различными сущностями, которые можно четко разграничить. Иными словами, мы предполагали следующее. ° Разработка требований предшествует проектированию. ° Пользователи и закаэчики принимают решения относительно требований.
° Разработчики принимают решения относительно проектирования, так как они лучше подготовлены к тому, чтобы выорать среди многих вариантов проектирования наиболее подходящий для удовлетворения конкретной потребности. Это удачная модель, от которой можно отталкиваться при решении задач управления требованиями. Дэвис (Лаъ!з, 1993) назвал ее парадиг мой "что вместо как", где "что" — это требования ("что" систелза должна делать), а "как" представляет собой проектное решение, которое следует реализовать для достижения этой цели. Для такого представления есть причины.
Действительно, лучше по. пять требования перед тем, как приступать к проектированию, а боль- 232 Часть 5. Уточнение определения системы шипство ограничений проектирования ("использовать ХЪЪбиблиотеку классов для доступа к базе данных") являются важными проектными решениями, записанными в активы требований с тем, чтобы мы знали, что онн получены по условиям контракта или по достаточно веским техническим причинам. Если мы не сможем произвести такую классификацию вовсе, картина будет очень запутанной, и мы не сумеем отделить разработку требований от проектирования.
Более то. го, мы не будем знать, кто эа что отвечает в процессе разработки. Или того хуже, ншви закаэчики будут диктовать иам проектные решения, а разработчики — требования. Однако существует пока невидимая, но достаточно серьезная проблема, которая противоречит представленной нами простой парадигме. Вернемся к нашему рабочелзу при. меру. Если команда принимает проектное решение использовать ПК-технологию для подсистемы "Центральный блок управления" (ЦБУ) системы НОЕ1$, это, вероятно, окажет некое внешнее воздействие на пользователя (он будет видеть подсказку или экран- приглашение). Если мы захотим воспользоваться некоторыми возможностями ОС, то соответствующие библиотеки классов будут, конечно же, демонстрировать внешнее поведение пользователю.
(Заметим, что его можно скрыть, но это не нужно.) Если воспользоваться предложенным в данной главе определением, возникает во. прос: если зфоехязное /мии»ие еоздейстеует»л о»еза»ее поеедтлзе, заметное полыоеателю, сяю»оеиззияли такое(зпне»»е (яе»о еоздтитеующее»а ееод пеи вывод с»стены) вз)зебоеаннем? Ответ ("да", "нет" или "ие имеет значения") будет зависеть от вашей интерпретации оп.
ределепия и проведенного нами анализа. Но это проливает свет на очень важный аспект, так как его понимание жизненно необходимо для уяснения природы итеративного про. цесса в целом. Давайте рассмотрим его более подробно. Итерационный цикл разработки требований и проектирования В реальности деятельности по разработке требований и проектированию должны осуществляться итеративно.
Вылеле»ие яз(зебоеа»пй, »х озз(зеделея»е» пр»»ятпе зфоект»ых реязе»»й цикз»зчески че)зедуювся. Процесс заключается в непрерывном кр)товороте. Имеющиеся требования приводят к выбору определенных вариантов проектирования, а те в свою очередь могут инициировать новые требования. Иногда появление новой технологии эзожет привести к тому, что мы отбросим лзножество предположений о том, какими должны быть требования; мы можем найти совершенно иной подход, перечеркивающий старую стратегию. (" Давайте целиком уберем модуль хл»е»сзззздоступ х да»ным/СИ и заменим его навигационным интерфейсом.") Это важный и праволзерззый источник изменения требований.
Такой процесс закономерен, попытка поступать по другому будет безрассудством. С друтой стороны, во всем этом есть серьезная опасность: если мы не достигли истинного понимания потребиостей заказчика »не привлекали его к процессу разработки требований (а иногда даже и к процессу зюнимаиия наших действий по ззроектироел»ию), может быль принято»еее(анас решение. При правильном осуществлении процесс "непрерывного пересмотра требований и проектирования" является просто фантастическим, так как позволяет постоянно совершенст. Глава 23.
требования к программному обеспечению 233 вовать пашу способность удовлетворить реальные потребности клиентов. Измияо я злым и го опоига суяв эффехяшвного ияираяяитого у~фааяеивя жрсбованнлми. Но если данный процесс осуществляется неправильно, мы постоянно "гоняемся эа хвостом нашей технологии", и результаты весьма плачевны. Мы никогда цс говорили, что это будет легко. Дальнейшая характеристика требований Итак, существуют различные "разновидности" требований, В частности, мы считаем полезным выделить следующие три типа (рис. 23.3).
° Функциональные требования к программному обеспечению ° Нефунюгиональные требования к программному обеспечению ° Ограничения проектирования гвс. ЗЗЗ. Тияы трсбоваяий Функциональные требования к программному обеспечению Функциональные требования описывают, как ведет себя система. Эти требования обычно ориентированы на действия (" Когда пользователь делает х, система будет делать у"). Большинство продуктов и приложений, предназначенных для выполнения полезной работы, содержит ьщожсство функциональных требований к программнолгу обеспечению.
Программное обеспечение используется для реализации большей части функциональных возможностей. Прн определении функциональных требований следует искать золотую середину между слишком конкретизированной формулировкой требования и слишком общей и неоднозначной. Например, как правило, пи к чему иметь обобщенное функциональное требование следующего вида; "Когда вы нажимаете зту кнопку, система включается и работает". С друтой стороны, формулировка требования, которая состоит из нескольких страниц текста, по видимому, слшпком конкретизирована, но может быть правомерной в некоторых частных слу ~аях. Мы вернемся к рассмотрению этого вопроса в главе 2б.
Оказывается, что большинство функциональных требований можно сформулировать в виде простых декларативных определений или в форме прецедентов, которым посвя- 234 Часть 5. Уточнение определения системы щсиа след>кэщая глава. Опыт свидетельствует, что определение требования, состоящее из одногсгдвух предложений, обычно является наилучшим, когда нужно соотнести потреб» остыэользователя с приемлемым для работы разработчика уровнем конкретизации. Нефункциональные программные требования Яо сих иор в д:шной главе приводились, в основном, примеры эюэедснчесиэх (фуякцнонольимх) трсбовшээ>йэ к системс, основное внимание в которых уделялось вопросам ввода, вывода и обэ!эаГхэткн.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
