Hinweis: Die aktuelle OOP-Konferenz finden Sie hier!
SIGS DATACOM Fachinformationen für IT-Professionals

Managing Today's Challenges

München, 03. - 07. Februar 2014


How to Unveil »Unknown Unknowns« in Requirements? From Thinking Humans to Tools of Thinking

Uhrzeit:17:45 - 18:45
Vortrag: Di 7.4

In a 2002 press briefing U.S. Secretary of Defense Donald Rumsfeld mumbled: »But there are also unknown unknowns - the ones we don't know we don't know.« The same is valid esp. in early phases of requirements engineering: clients are often not capable to talk about issues they are not even conscious about. They lack a cognitive skeleton. We address this problem by means of a »normative« framework that was derived from education sciences. It helps to articulate »subconscious« issues and, thus, introduce them to the stream of the elicitation process.

Target Audience: avangarde software architects, open-minded developers, frustrated requirement engineers and clients
Prerequisites: curiosity, open-mindedness, requirements engineering techniques, unified process
Level: Practicing

You will learn:
- How can we improve a client’s commitment in requirements elicitation processes by providing a clearer picture of the »inherent character« of software?
-What is a better way to detect the »blind spots« in requirements elicitation?
- How can we identify work-arounds to avoid some major traps in the archetypical requirements engineering process?

Extended abstract:
One of the major problems in requirements engineering arises from the observation that clients often cannot imagine how a - yet unknown - software system will change and (in the better case) their existing working attitudes, improve their daily workload or enhance their cognitive and mental capabilities.

We think it is insufficient to just request and complete a »descriptive« software specification sheet that is solely based on verbally expressed requirements. Instead, we assume that clients dramatically benefit from a »normative« framework that helps them to reflect their ideas and integrate those in a bigger picture on how software actually is a cognitive enhancement of their thinking and reasoning capabilities. Customers usually lack such a kind of »cognitive skeleton« that helps them to interpret and balance feature options that should be offered by software in this regard.

Thus, we assume it is worth to consider software at all as a »cognitive tool« (Pea 1985, Jonassen 1992) that is supposed to accelerate and increase a user’s general cognitive experience. All software implementations share some common ground in the way they somehow are a »reflection« of human thinking and reasoning. From here, the ultimate question arises: how must a framework be designed that could serve as a guiding principle to unveil such »unknown unknowns« in software requirements elicitation?

We believe that Bloom's Taxonomy is poised to become a candidate for such a framework (Bloom 1956, Anderson & Krathwohl 2001, Churches 2007). Originally, Bloom's Taxonomy was developed to better understand processes of human learning. It is a rather simple way to categorize human cognitive processes by distinguishing six consecutive stages of learning that range from lower to higher order thinking skills. The theory is widely accepted and adapted as a guiding principle in education sciences for decades.

Presuming, that any software serves as a »cognitive tool« in human reasoning and learning on a very basic level (e.g. elaborate spreadsheets, edit and review text, create mindmaps), we suppose Bloom's Taxonomy could become the foundation of a »normative« framework that helps to mitigate some weak points in current techniques of requirements elicitation.

We will outline and elaborate an example on how to adapt Bloom's Taxonomy to the challenge of requirements elicitation. For that purpose, we have conducted a case study of a »post-mortem« software review (Dingsoyr 2004) and will present preliminary results.

Finally, we will show how Bloom's Taxonomy would fit in with existing methodologies like e.g. the Rational Unified Process and how it would improve even accepted and wide-spread techniques of requirements engineering.