Спецификация требований к программному обеспечению (Modern Software Requirements Specification)

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

Говоря коротко, изначально команда разработчиков располагает частями относительно полной концептуальной структуры, с помощью которой можно рассуждать о будущей системе. Скорее всего, ее еще нельзя «потрогать» (хотя, возможно, были представлены отдельные прототипы) но уже можно начать ее анализировать и проверять понимание системы, несмотря на то, что она до сих пор существует только на бумаге и в виде моделей.

Можно сказать, что в этот момент команда подходит к важному рубежу: созданию концептуальной модели системы, которую надо построить.

Пакет спецификаций требований к программному обеспечению (Modern SRS Package)

Исторически сложилось так, что наиболее популярный метод документирования требо­ваний состоял в упорядоченной их записи на естественном языке. Этот метод пересматривался и совершенствовался в ходе выполнения множества проектов и постпенно был разработан ряд стандартов для подобных документов, в том числе стандарт IEEE (Institute of Electrical and Electronics Engineers) 830: Standard for Software Requirements Specification (1994).

Но сегодня при наличии современных инструментальных средств и методов предпочтительно представлять спецификацию программных требований (SRS) в виде ло­гической структуры, а не физического документа. Различные детально описанные требо­вания к системе заключаются в пакет, который называют современным пакетом спецификаций требований к программному обеспечению (Modern Software Requirements Specification Package), в отличие от более ранних форм, которые именуются просто SRS. Пакет Modern SRS Package связан с документом видения, который служит исходной информацией для его создания.

Однако эти два артефакта служат разным целям и, как правило, пишутся разными ав­торами. На данной стадии проекта акцент смещается от общей формулировки потребно­стей пользователя, целей, задач, целевых рынков и функций системы к детальному опи­санию того, как эти функции предполагается реализовывать в решении.

На рис. 3.13 схематически представлены элементы пакета.

Рисунок 3.13. Элементы Modern SRS Package.

На данном этапе необходим пакет информации, полностью описывающий внешнее поведение системы, т.е. набор артефактов следующего содержания: "Вот то, что система должна делать, чтобы предоставить эти функции". Это и есть Modern SRS Package.

Итак, предполагается, что набор требова­ний образует пакет информации. Поэтому на рис. 3.13 изображены не только элементы этого пакета, но и их связи.

Пакет Modern SRS Package - это не том замороженной информации, созданный в со­ответствии с требованиями ISO 9000, который затем положат на полку. Это активный «живой» пакет, во многих случаях играющий чрезвычайно важ­ную роль при переходе к реализации.

Он служит основой для общения между всеми сторонами-участниками.

Формально или неформально, он представляет соглашение между этими различ­ными сторонами: если чего-то нет в пакете, разработчики не должны над этим ра­ботать. Но если это в пакете есть, они отвечают за то, чтобы предоставить данную функциональную возможность.

Список литературы

1. http://www.standishgroup.com

2. Davis A. Software requirements: Objects, Functions and States. Englewood Cliffs, NJ: Prentice-Hall, 1993.

3. Snyder T. and Shumate K. Kaizen Project Management. American Programmer 5, 10; December, 1992, pp. 12-22.

4. Gause D. and Weinberg G. Exploring Requirements: Quality before Design. New York: Dorset House Publishing, 1989.

5. Принципы работы с требованиями к программному обеспечению. Дин Леффингуэлл, Дон Уидриг.

6. Brooks F. The Mystical Man Month: Essay on Software Engineering. Reading, MA: Addison-Wesley, 1975.

7. Grady r. Practical Software Metrics for Project Management and Process Improvement. Englewood Cliffs, NJ: Prentice-Hall, 1992.

8. Karat C.-M. Guaranteeing Rights for the User. Communications of the ACM 41,12; December, 1998, p.29.

9. Business Rules Group. 1993. Defining Business Rules: What Are They Really? http://www.businessrulesgroup.org.

10. Von Halle, Barbara. 2002. Business Rules Applied: Building Better Systems Using the Business Rules Approach. New York: John Wiley & Sons.

11. Ross Ronald G. 1997. The Business Rule Book: Classifying, Defining and Modeling Rules, Version 4.0, 2d ed. Houston: Business Rule Solutions LLC.

12. J. Rumbaugh, I. Jacobson, and G. Booch, 1998. UML Reference Manual. Addison Wesley Longman.

13. Вигерс Карл. Разработка требований к программному обеспечению / Пер, с англ. — М.: Издательско-торговый дом «Русская Редакция», 2004. —576с.: ил.

14. IEEE. 1990. IEEE Std 610.12-1990: IEEE Standard Glossary of Software Engineering Terminology. Los Alamitos, CA: IEEE Computer Society Press.

15. Sommerville Ian, Pete Sawyer. 1997. Requirements Engineering: A Good Practice Guide. Chichester, England: John Wiley & Sons.