Loading presentation...

Present Remotely

Send the link below via email or IM


Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.


Desk - Avoiding the Requirements Trap


Thomas Merriman

on 17 June 2015

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of Desk - Avoiding the Requirements Trap

Abstraction and Decomposition
One of the foundational concepts of software engineering
How to Design Great Software and Web Pages
Tom Merriman
Avoiding the Requirements Trap
Business requirements
Web page request list
Functional requirements
Stakeholder requests
Customer requests
Tom Merriman
Business (Product) Manager
MSc Management, Information Systems and Digital Innovation
MSc Finance and Management
London & New York
2005 - 2013
Business/product manager for bond and derivative trading and inventory software
Built and managed team of senior business managers
UI / UX business lead
Experience creating and launching great products
World class information systems group
Research published in HBR, Sloan Management Review, Information Systems Research, Information Society
Expertise in cloud computing, big data, social computing, digital infrastructure, mobile technology, outsourcing, information systems in society
Jannis Kalinikos
Will Venters
Carsten Sørensen
Leslie Willcocks
Chrisanthi Avgerou
No Silver Bullet
Fred Brooks
Essence and Accidents of Software Engineering
Hardest part of building software is knowing what to build
Inherent problems with abstracting the real-world
Herbert Simon
Bounded Rationality and Human Problem Solving
1955, 1956, 1957, 1969, 1972, 1976, 1982
Traditionally, theory expects humans to behave rationally when faced with a set of choices or problem
In the real world, humans do not act rationally since the complexity in processing and evaluating information stops humans from choosing the best course. Their rationality is bounded
Allows complexity to be countered
Forms basis of traditional software design methodologies
Wasserman (1996)
Dijkstra (1972)
Prototypes versus Specifications
The Principle of Limited Reduction
Mathiassen & Stage
Abstraction (providing clarity by classification and codification)
Tries to reduce complexity
Creates uncertainty
Tries to reduce uncertainty
Increases complexity
Complexity and Uncertainty
1. Relying on analytical behaviour to reduce complexity introduces new sources of uncertainty that require experimental countermeasures

2. Relying on experimental behaviour to reduce uncertainty introduces new sources of complexity requiring analytical countermeasures
The Solution: You're already doing it!
Mixing prototypes and specifications
Best requirements when users engage with software / web page (Situated Practice)
Orlikowski (1996)
Big Data Can Help
The Data Revolution: Big Data, Open Data, Data Infrastructures & Their Consequences
Rob Kitchin
Very large, diverse survey samples
N = all (in some cases)
Encompass A/B testing employed by world's software and internet giants
Can help avoid requirements trap
Leveraging The First Mover
Stage 1
50,000 visits /day, 17,000 users
Implemented graduated opt-in, opt-out roll-out
Tracked usage
5% of users switch voluntarily
Stage 2
Split into three sections
Basic version to entice first movers
Collect usage data to guide main build
Use remaining budget to tweak product
Does it Match the Theory?
Fred Brooks
Essence and Accidents of Software Engineering
Mathiassen & Stage
The Principle of Limited Reduction
Wanda Orlikowski
Situated Practice
Problems are inherent, they will never disappear
Use big data techniques to mix specifications, prototypes and situated practice
Design great software and web pages!

Hard problem!
Big data can help!
Not a guide to agile or Scrum
Thanks for Watching
Split your project into three phases
Start with a basic version of your software/web page
Include just enough new/improved functionality to entice first movers
Gather detailed usage data on their behaviour
Use that data for the major build (phase 2)
Opt-in the rest of the user base and continue to gather data
Use phase 3 to fix as much of the "20%" as possible
The good and the bad...
The Good
Especially good when user behaviour is unknown
Software / web pages with high rates of human interaction
Building on a fixed budget
Environment supportive of beta versions
The Bad
First movers are not representative of wider audience
Very basic software / web page with minimal UI
Software / web pages with poor usage data gathering tools
When requirements / specifications are well known
Try it!
Full transcript