TYPO3 Backend Apps Prototype

Requirements Engineering
& Design Thinking
on Backend Apps
TYPO3 Camp Hamburg 2015

Gernot Schulmeister | gernot.schulmeister@wfp2.com 09.08.2015 Seite 2wfp:2 GmbH & Co. KG Mönchengladbach | www.wfp2.com
Requirements engineering & design thinking on backend apps
Gernot Schulmeister
… Lives in Mönchengladbach
… Developes websites with TYPO3 since Version 3.7
(2005)
… Works for wfp:2
… Has a migration background and comes from
Southeast-Europe (Austria)
… Likes operative CMS evaluations
Contact
• facebook.com/gernot.schulmeister
• twitter.com/mistakanista1

Requirements engineering
Design thinking
Backend app prototype
Schedule

Problems in web projects
• The timetable cannot be held
• The budget is overdrawn
• The size extents
• The solution differs from the customers expectations
• The requirements are unclear
• Last minute changes
• No common view on the project volume
• Additional costs are often carried by the agencies
• Scrum does not fit for every customer

Requirements engineering
• Helps to analyse and clarify requirements with the
customer before the project starts
• Stakeholder analysis
• Must, should and can requirements
• Functional and non functional requirements

Stakeholder analysis
• Who are the decision makers?
• Who works with the solution?
• Who has benefits of the implementation?
• Under which condition is the software used?
• Identify the vision, workflows, expectations and
functionalities
• Clarifies the customers view on the project volume
• Develops understanding for more budget

Must, should & can requirements
• Must: minimum of a good implementation
• Should: very good solutions but increase time and
money
• Should requirements only necessary for power user?
• Can: make the project a highlight
• Increase the budget a lot and have many details and
dependencies to other requirements
• Later changes are very costly if there are no
experiences with the target of the project
• Postpone to later releases

Functional & non functional
requirements
• Functional: output of the solution
• Define them exactly
• Interfaces, security, expected usage interval & data
volume, tests
• Who made the requirement
• Non functional: quality of the solution
• Reliability, fault tolerance, usability, learnability,
efficiency, time behavior, resource behavior,
maintainability, portability

Example process
• Identify stakeholder: visionaries, decision makers,
know how carriers, administrators, editors, user
• Collect requirements: interview them in position or
topic groups, not all together
• Analyse requirements: sort, version, categorise to
find relationships and contradictions
• Validate requirements: in discussion groups to sort
out interpretations and get new insights.
• Iterate: after the feedback of the customer
• Acceptance of the requirements

When to use it
• As a own pre project to define the efforts
• At the begin of a project or sprint
• At the begin of the technical implementation
• When a project has failed to restart it

Conclusion
• Requirements engineering needs practise
• Customer gets more details of his targets
• No discussions and interpretations about
implementation details
• Implementation is more straight forward
• Basis for a cost calculation
• Shows early if the budget is sufficient
• Tool to check the quality of the implementation
• Helps to coordinate and assure business partners

• Process to make innovations supported by many
Problems of innovations
• Decisions for innovations are made by HIPPOs
• The first correct solution is implemented
• High risks of success regarding global developments
of technologies, markets and customers
Design thinking

• Technology: what can be made now or in future
• Business: sustainable business models
• Humans: attractive and requested solutions
• Sections: process → technology / business
• Functions → technology / humans
• Emotions → humans / business
Sweet spot of
innovation

Rules
• Fail often and early
• Leave titles at the door
• Don´t talk do!
• There are no good ideas
• Build on ideas of others
• Avoid criticism
• The quantity is it
• Stay focused
• Dare to be wild!
• Think human centered
• Be visual
• Let´s have fun
• Don´t be captured by a simple solution of a problem
• Go underneath it and expand the problem space

Core attributes
• Ambiguity: being comfortable with unclear things
• Collaborative: work together across disciplines
• Constructive: new ideas based on old ideas
• Curiosity: interest in new things
• Empathy: look at the customers point of view
• Holistic: bigger customer context
• Iterative, non judgemental
• Open mindset: design thinking is not restricted on
software

Process
• Double diamond: problem and solution space
• Start is a challenge as a question
• Divergance: get new insights
• Convergance: sort, priorisize and select

Conclusion
• Strategic direction of innovation projects
• Answers the question of what not how
• Introduction in a agile project
• Ends with a prototype
• Decision of implementation is made somewhere else
• Not useful in th 23rd
iteration of a product

Links
Requirements engineering:
• http://t3n.de/magazin/requirements-engineering-
webprojekte-237281/
Design thinking:
• https://jaxenter.de/design-thinking-als-prozess-zur-
innovationsfindung-290

TYPO3 Backend Apps Prototype

More Related Content

Similar to TYPO3 Backend Apps Prototype (20)

More from Gernot Schulmeister (9)

Recently uploaded (20)

TYPO3 Backend Apps Prototype