Проектирование программного обеспечения. Николаев С.В. - 59 стр.

UptoLike

ВУЗ: 

ТТИ ЮФУ | Таганрог

Составители: 

Рубрика: 

59
ходных данных. Если не удается четко провести грань между существен-
ными и несущественными (а обычно так и бывает в начальной фазе)
требованиями, то их можно разделить (более "мягко") на две группы:
обязательные и желательные. Кроме того, для числовых характеристик
всегда предпочтительнее указывать диапазон (интервал) желаемых зна-
чений вместо одного единственного
и обязательного значения, все равно
редко когда такие строгие оценки имеют надежное обоснование на этапе
формулирования требований.
4.
Требованиями нужно управлять. Как правило, окончательные значения
параметров устанавливаются в результате баланса взаимно противоречи-
вых требований. Обычно достижение высоких характеристик по одним
параметрам вступает в противоречие с другими параметрами. Кроме то-
го, заказчик, если он участвует в совместном формировании требований,
будет вольно или невольно стремиться к завышению потребительских
качеств и
расширению функциональных возможностей. Задача разработ-
чика – найти разумные компромиссы по возникающим при этом проти-
воречиям. Для этого нужно уметь находить такие трансформации струк-
турных решений, при которых "жертвы" по одним параметрам удается
"перекачать" в достижения по другим параметрам.
5.
Требования должны быть адекватно задокументированы. В конеч-
ном итоге требования фиксируются в виде документа - спецификации
или технического задания, который становится официальным руково-
дством для последующих этапов разработки и оценки конечных резуль-
татов. При этом следует обращать внимание как на язык – точность и не-
двусмысленность формулировок, так и на форму подачи –
таблицы, гра-
фики, блок-схемы, формульные описания.
6.
Учет "обязательных" (скрытых) требований. Есть целый ряд
существенных требований, о которых на начальном этапе заказчик, как
правило, забывает, однако затем в процессе эксплуатации, когда
неизбежно выявляются несоответствия, "выставляет" претензии. Эти
претензии естественны и, хотя в исходное техническое задание они не
включены, все равно придется делать корректировки требований и
переделывать часть
проекта. Поэтому лучше, если разработчик,
руководствуясь своим опытом и знаниями, проявит инициативу и на
этапе формулирования общего перечня требований включит в его состав
и "обязательные" требования. Среди них могут быть:
–
требования к надежности функционирования;
–
требования к скорости реакции программы на действия оператора
или на другие внешние события;

Страницы