Требования к программному обеспечению

Глава 23

Резюме

Итак, мы постарались подробно объяснить процесс определения требований. Мы

увидели, как бизнес-модели и модели предметной области помогают определить

контекст системы и как из бизнес-модели можно получить варианты использования.

Мы увидели, что для определения требований используются варианты использования.

К этому моменту мы вернемся в следующей главе. В последующих

главах мы рассмотрим, как варианты использования и дополнительные требования

помогают нам проводить анализ, разрабатывать архитектуру, проектировать,

создавать и тестировать систему так, чтобы она гарантированно выполняла требования

заказчиков.

Основные положения

· Полный набор требований можно получить, определив вводы, выводы, функции и атрибуты системы, а также атрибуты ее окружения.

· В требования не следует включать общую информацию (графики, планы разработки, выделенные средства, тесты), а также информацию. касающуюся проектирования.

· Процесс разработки требований/ проектирования является итеративным; выявленные требования ведут к выбору конкретных вариантов проектирования, которые в свою очередь приводят к возникновению новых требований.

· Ограничения проектирования касаются вариантов проектирования системы или процессов, с помощью которых система разрабатывается.

В предыдущих частях мы намеренно оставили определенные для системы функции на высоком уровне абстракции с тем, чтобы удобнее было выполнить следующие действия.

• Понять форму системы, сосредоточив внимание на ее функциях и на том, как они выполняют потребности пользователя.

• Оценить полноту и целостность системы, а также ее соответствие среде.

• Использовать данную информацию для определения возможности построения системы и управления ее масштабом перед тем. как будут производиться значительные инвестиции.

Кроме того, оставаясь на высоком уровне абстракции, мы воздерживаемся от преждевременного принятия чрезмерно ограничительных решений по требованиям, т. е. до того, как люди непосредственно занимающиеся реализацией системы, получат возможность внести свой вклад в определение системы. В части 5, "Уточнение определения системы," мы переходим к разработке функций системы до уровня детализации, достаточного, чтобы гарантировать, что в ходе проектирования и кодирования будет создана система, полностью соответствующая потребностям пользователя. При этом мы переходим на следующий уровень конкретизации и создаем более полную, глубокую модель требований к разрабатываемой системе. Конечно, количество информации, которой надо управлять, также увеличивается, и нам необходимо подготовиться к работе с ней.

Уровень конкретизации, необходимый на этом шаге, зависит от множеств факторов, среди которых содержание приложения и профессиональные навыки команды разработчиков. Для высокобезопасных систем программного обеспечения в медицине, авиации или интерактивной торговле уровень конкретизации особенно высок. Процесс уточнения может включать в себя использование формальных средств обеспечения качества, просмотры, ревизии, моделирование и т.п. В системах, где последствия сбоев не столь катастрофичны, уровень трудоемкости более умеренный. В этих случаях просто необходимо сформулировать определение системы достаточно четко, чтобы его могли понять все участники процесса, а также для того, чтобы обеспечить эффективные условия разработки и "достаточно высокую" вероятность успеха. Руководствуясь прагматическими и экономическими соображениями, следует создать достаточное количество спецификаций требований, чтобы разрабатываемая программа была именно тем, чего хочет пользователь.

Точно так же, как не существует языка программирования, подходящего для всех без исключения приложений, нет и универсального способа разработки более детальных спецификаций. В различных средах требуются различные методы, и тем, кто пишет требования и управляет ими, необходимо овладеть, разнообразными профессиональными приемами. Нам приходилось и своей практике применять множество методов — от применения достаточно строгих документов требований, традиционных баз данных или архивов требований до использования моделей прецедентов и более формальных методов. Но всегда главное внимание уделялось спецификации на естественном языке, написанной достаточно ясно, чтобы ее могли понять все заинтересованные лица, заказчики, пользователи, разработчики и тестологи, но также достаточно конкретно ("Максимальная горизонтальная скорость оси 4 должна составлять 1м/с"), чтобы можно было выполнить верификацию и продемонстрировать соответствие. Перед тем как организовывать требования к системе, рассмотрим саму природу этих требований.