Иллюзия требований при разработке программного обеспечения

Пол Ральф, 2012
Paul Ralph. The illusion of requirements in software development
DOI 10.1007/s00766-012-0161-4

Аннотация

В этой статье рассматривается возможность того, что многие проекты по разработке программного обеспечения могут не иметь полезных требований. В частности, для проблем (например, выгорание работников сферы знаний), имеющих два совершенно разных подхода к решению (например, улучшить инструментальную поддержку или нанять больше сотрудников), аналитик может сформулировать цель (например, сократить рабочее время), но более конкретные пожелания стейххолдеров (desiderata) будут зависеть от выбранного подхода. Кроме того, не исследовав полностью пространство решений, проектировщик не может быть уверен, что не найдётся другой подход, который позволит достичь поставленной цели без каких-либо пересечений с подходами, известными до этого. В ситуациях, когда настоящих требований в проекте практически нет, аналитики могут ошибочно выдавать проектные решения за требования, создавая иллюзию требований при разработке программного обеспечения.

Ключевые слова: Требование, Цель, Проектирование, Основы, Философия, Онтология, Эпистемология

Введение

Широко признаётся, что понимание требований к системе является важным условием успешности проекта разработки программного обеспечения [1, 2]. Иначе говоря, широко признано, что провал в понимании требований связан с провалом проекта [3, 4]. Идея о том, что программные артефакты обычно имеют набор обнаруживаемых, документируемых требований, укоренилась в отраслевых стандартах [5], процессах разработки [2] и учебных программах [6, 7].

В более широком смысле требования являются основополагающим компонентом рациональной модели проектирования (Rational Model of Design) [8–10] — доминирующего взгляда на то, как специалисты подходят к разработке программного обеспечения и информационных систем.
Тем не менее, применение хороших практик работы с требованиями не обязательно является необходимым и/или достаточным условием для достижения успеха проекта [11, 12].

Предположение о том, что у программных проектов есть обнаруживаемые и документируемые требования, послужило основанием для появления разнообразной литературы по инженерии требований (ИнжТр, RE) — процессу выявления, анализа, моделирования, верификации и управления требованиями. Основной вклад вносят подходы к инженерии требований, такие как целе-ориентированная инженерия требований (goal-oriented RE) [13], инженерия требований, ориентированная на пользователя (user-centered RE) [14] и типы требований — например, нефункциональные требования [15], ранние требования [16].

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

Некоторые явные допущения

Разные авторы определяют «требование» по-разному: «структурное или поведенческое свойство, которым должен обладать объект проектирования» [17, с.108], «утверждение, определяющее возможности или функции, необходимые системе для удовлетворения потребностей заказчика» [18, с.205] и «свойство, которое должно быть проявлено для решения некоторой проблемы в реальном мире» [19, разд. 1.1].

Требования часто отделяют от целей и проектных решений. «Цель — это результат, которого должна достичь рассматриваемая система» [13, с. 2]. Если «цели описывают желаемые воздействия объекта проектирования на окружающую среду» [17, с. 110], то «требования обычно понимаются как изложение того, что должна делать система, в отличие от того, как она должна это делать» [20, с. 226]. Похожим образом утверждалось, что «спецификации требований определяют желаемые функциональные и эксплуатационные характеристики некоторого компонента независимо от их фактической реализации» [21, с. 14]. Аналогично, в стандарте IEEE 830–1998 говорится, что «требования определяют видимую извне функцию или атрибут системы, а проект (design) описывает конкретный субкомпонент системы и/или его интерфейсы с другими субкомпонентами» [5, с. 9]. Понимание взаимосвязи между целями, требованиями и проектными решениями составляет суть задачи прослеживаемости требований (requirements traceability — см. [22, 23]).

Эти различные определения указывают на необходимость более чёткого определения онтологических предпосылок, лежащих в основе инженерии требований. Для целей данной статьи я предполагаю, что в рамках проекта по разработке программного обеспечения создается артефакт, называемый объектом проектирования (design objects) и имеющий свойства, также называемые характеристиками (features). Участники проекта или заинтересованные стороны могут предъявить объекту проектирования одну или несколько целей — утверждений о желаемом, описывающих изменения в среде, которые должен произвести объект проектирования.

Требование — это характеристика объекта проектирования, необходимая для достижения цели. (Хотя это нетрадиционный способ определить требования, он значительно упрощает объяснение двух проблем, рассматриваемых ниже, которые не зависят от этого конкретного определения). Например, предположим, что команда разработчиков проектирует веб-сайт (объект проектирования) для продажи фотоаппаратов через интернет (цель). Сайт будет иметь много особенностей (например, выделение названия магазина жирным шрифтом), которые не вносят существенного вклада в достижение цели. Однако другие функции (например, корзина для покупок) могут быть необходимыми условиями для достижения цели — эти необходимые характеристики являются требованиями. Более точно, если задана цель g, то набор требований Rg можно определить как набор всех характеристик, необходимых объекту проектирования для достижения цели g. В рамках данной статьи я не делаю различий между требованиями ранней и поздней стадии [16], жёсткими/функциональными и мягкими/нефункциональными требованиями [15] или требованиями и ограничениями [17].

Рисунок 0. Иллюстрация онтологии автора от редактора перевода:

Онтологические и
эпистемологические вызовы

Предположим, что ровно два объекта проектирования D1 и D2 будут достигать цели g. Характеристики обоих объектов являются требованиями, поскольку без них невозможно достичь цели g (табл. 1). Свойства, присущие только D1, но не D2, не являются требованиями, так как g может быть достигнута без них (построением D2); свойства, присущие только D2, но не D1, не являются требованиями, так как g может быть достигнута без них (построением D1).

Свойства, отсутствующие у обоих объектов, не имеют значения. В более общем случае предположим, что g может быть достигнута с помощью n объектов проектирования (D1, D2, ... Dn), каждый из которых обладает характеристиками (F1, F2, ... Fn). Тогда множество требований Rg можно определить как пересечение свойств (Rg = F1 ∩ F2 ∩ ... ∩ Fn).

Таблица 1. Отношения между свойствами (решения) и требованиями:

Свойства, отсутствующие у обоих объектов, не имеют значения. В более общем случае предположим, что g может быть достигнута с помощью n объектов проектирования (D1, D2, ... Dn), каждый из которых обладает характеристиками (F1, F2, ... Fn). Тогда множество требований Rg можно определить как пересечение свойств (Rg = F1 ∩ F2 ∩ ... ∩ Fn).

Рисунок 2 редактора перевода:

Характеристика требований в таком виде выявляет два предположения. Во-первых, существование требований предполагает пересечение свойств объекта проектирования, которые могут обеспечить достижение цели (Rg = F1 ∩ F2 ∩ … ∩ Fn ≠ ∅). Напротив, если свойства не пересекаются (Rg = F1 ∩ F2 ∩ … ∩ Fn = ∅), то требований не существует (онтологическая проблема; см рис. 1 ниже). Во-вторых, формулировка требований предполагает, что все соответствующие объекты проектирования (или их классы) определены. Если может существовать другое решение, которое обеспечит достижение g без каких-либо общих с известными решениями свойств, то никакие свойства существующих наборов решений не являются требованиями (эпистемологическая проблема). Например, компания решила защитить свою сеть от вредоносных программ и написала спецификацию требований к сложной антивирусной системе. В процессе рассмотрения кто-то спрашивает: «А почему бы нам не перейти на Mac OS или Linux, ведь у них меньше проблем с вирусами?». Так выясняется, что кажущиеся «требования» — это всего лишь особенности одного решения.

Таким образом, если пространство решений неизвестно или не пересекается, требования не могут быть сформулированы. Это не то же самое, что признать неоднозначные, противоречивые или неполные требования. И отсутствие пересечения и эпистемическая неопределённость приводят к ситуации, где требований не существует.

Авторский рисунок 1:

Ограничения и работа без требований

Описанные выше онтологические и эпистемологические проблемы концепции требований, очевидно, несколько упрощены. Во-первых, при обсуждении используется контрфактический подход к причинности [24], хотя более уместным был бы вероятностный подход (свойства решения могут увеличивать вероятность успеха, а не быть «необходимыми условиями»). Во-вторых, определение требования не учитывает другие некритические пожелания (потребности, предпочтения), которые, тем не менее, могут быть важны. В-третьих, определение необходимого свойства не всегда требует понимания всего пространства решения — для обоснования требования может быть достаточно комментария заслуживающего доверия информатора о том, что «совет директоров никогда не одобрит эту разработку, если она не будет работать на iPhone».

Однако, иллюстрация высвечивает две фундаментальные проблемы. Во-первых, можно представить себе ситуации (например, выгорание работников умственного труда), когда два совершенно разных подхода (например, улучшение инструментов поддержки или наём большего числа сотрудников) могут привести к достижению одной и той же цели (например, сокращению рабочего времени) — в таких случаях, когда решения мало совпадают, требования могут быть сформулированы в малом количестве, если вообще могут быть сформулированы. Кроме того, не исследовав полностью пространство решений, проектировщик не может быть уверен, что не найдётся другой подход, который позволит достичь поставленной цели без каких-либо пересечений с подходами, известными до этого.

Таким образом дальнейшие идеи по развитию инженерии требований могут пойти в только двух направлениях:

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

Второе направление заключается в том, что многие существующие подходы к разработке требований реализуют конструкцию требований в более общем виде — как пожелания (desiderata), которые могут быть или не быть строго необходимыми для достижения успеха. Это проблематично из-за сильной денотации и коннотации термина (денотация — это прямое значение слова, чаще всего зафиксированное в словарях). Слово «требование» обозначает то, что является обязательным. Перечисление требований подразумевает определённость и однозначность. Например, когда аналитик заявляет, что «кросс-платформенная совместимость» является требованием, начинающие разработчики и заинтересованные стороны, не знакомые с проблемами разработки требований, вряд ли интерпретируют это как «аналитик предполагает, что кросс-платформенная совместимость повысит вероятность достижения системой поставленных целей, но мы не будем знать наверняка, пока система не будет создана, если вообще будет» или «все возможные кандидаты на проектирование, созданные на данный момент, включают кросс-платформенную совместимость, но мы не полностью исследовали всё пространство возможных решений».

Широкий спектр когнитивных феноменов, включая эффект привязки [25], фиксации [26] и предвзятость подтверждения [27], позволяет предположить, что неправильное представление случайного свойства в качестве требования приведёт к сокращению исследования пространства решений и ограничению инноваций.

Аргументация данной статьи может быть оспорена, по крайней мере, по двум основаниям. Во-первых, можно провести различие между обязательными и необязательными требованиями. В ответ на это я повторяю психологический эффект неправильного обозначения свойств как «требований» (см. выше) и предполагаю, что обозначение «необязательное требование», скорее всего, усилит путаницу. Во-вторых, можно привести аргументы в пользу условных требований, когда некоторые характеристики становятся требованиями в зависимости от других характеристик. Например, «учитывая, что артефактом проектирования является веб-сайт, он должен быть совместим с HTML5». Однако, это создает редукционистскую спираль, в которой практически все проектные решения могут быть переформулированы в условные требования, что подрывает различие между требованиями и проектными решениями, ещё больше запутывает разработчиков и препятствует инновациям.

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

Ссылки на использованные источники

1. Boehm B (1991) Software risk management: principles and practices. IEEE Softw 8(1):32–41

2. Jacobson I, Booch G, Rumbaugh J (1999) The unified software development process. Addison-Wesley Longman Publishing Co., Inc., Boston

3. Ewusi-Mensah K (2003) Software development failures. MIT Press, Cambridge

4. Standish Group (2009) CHAOS summary 2009. Boston, MA, USA http://www.standishgroup.com/newsroom/chaos_2009.php

5. IEEE (1998) IEEE Standard 830-1998: recommended practice for software requirements specifications. http://standards.ieee.org/ findstds/standard/830-1998.html

6. Topi H, Valacich JS, Wright RT, Kaiser KM, Nunamaker JF, Sipior JC, Vreede GJd (2010) IS 2010: curriculum guidelines for undergraduate degree programs in information systems. Communications of association for information systems 26:Article 18. http://aisel.aisnet.org/cais/vol26/iss1/18/

7. Joint Task Force on Computing Curricula (2004) Software engineering 2004: curriculum guidelines for undergraduate degree programs in software engineering. In: D ́ıaz-Herrera JL, Hilburn TB (eds). http://sites.computer.org/ccse/SE2004Volume.pdf

8. Simon HA (1996) The sciences of the artificial, 3rd edn. MIT Press, Cambridge

9. Brooks FP (2010) The design of design: essays from a computer scientist. Addison-Wesley Professional, Reading

10. Ralph P (2011) Introducing an empirical model of design. Paper presented at the 6th Mediterranean conference on information systems, Limassol, Cyprus, 3–5 Sep

11. Davis AM, Zowghi D (2006) Good requirements practices are neither necessary nor sufficient. Requir Eng 11(1):1–3

12. Shenhar AJ, Dvir D, Levy O, Maltz AC (2001) Project success: a multidimensional strategic concept. Long Range Plan 34(6):699–725

13. van Lamsweerde A (2001) A goal-oriented requirements engineering: a guided tour. In: Proceedings of the fifth IEEE international symposium on requirements engineering, Aug, pp 249–262

14. Sutcliffe A, Thew S, Jarvis P (2011) Experience with user-cen- tred requirements engineering. Requir Eng 16(4):267–280

15. Chung L, Nixon BA, Yu E (2000) Non-functional requirements in software engineering. Kluwer international series in software engineering, vol 5. Springer, Berlin

16. Fuxman A, Liu L, Mylopoulos J, Pistore M, Roveri M, Traverso P (2004) Specifying and analyzing early requirements in tropos. Requir Eng 9(2):132–150

17. Ralph P, Wand Y (2009) A proposal for a formal definition of the design concept. In: Lyytinen K, Loucopoulos P, Mylopoulos J, Robinson W (eds) Design requirements engineering: a ten-year perspective. Lecture notes on business information processing, vol 14. Springer, Berlin, pp 103–136

18. Bahill AT, Dean FF (2009) Discovering system requirements. In: Sage AP, Rouse WB (eds) Handbook of systems engineering and management, 2nd edn. Wiley, New York, pp 205–266

19. Bourque P, Dupuis R (eds) (2004) Guide to the software engineering body of knowledge (SWEBOK). IEEE Computer Society Press, Silver Spring

20. Yu E (1997) Towards modelling and reasoning support for early-phase requirements engineering. In: Proceedings of the third IEEE international symposium on requirements engineering, pp 226–235

21. Roman G-C (1985) A taxonomy of current issues in requirements engineering. Computer 18(4):14–23

22. Gotel O, Finkelstein A (1994) An analysis of the requirements traceability problem. In: First international conference on requirements engineering, Colorado Springs, CO, USA, IEEE Computer Society Press, pp 94–101

23. Ramesh B, Jarke M (2001) Toward reference models for requirements traceability. IEEE Trans Softw Eng 27(1):58–93

24. Gregor S (2006) The nature of theory in information systems. MIS Q 30(3):611–642

25. Parsons J, Saunders C (2004) Cognitive heuristics in software engineering: applying and extending anchoring and adjustment to artifact reuse. IEEE Trans Softw Eng 30:873–888

26. Jansson DG, Smith SM (1991) Design fixation. Des Stud 12(1):3–11

27. Oswald ME, Grosjean S (2004) Confirmation bias. In: Pohl RF (ed) Cognitive illusions: a handbook on fallacies and biases in thinking, judgement and memory. Psychology Press, Hove, pp 79–96

28. Ralph P (2011) Toward a theory of debiasing software development. In: Wrycza S (ed) Research in systems analysis and design: models and methods: In 4th SIGSAND/PLAIS EuroSymposium 2011. LNBIP, vol 93. Springer, Gdansk, Poland. pp 92–105