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

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Ähnlich wie TYPO3 Backend Apps Prototype

Ähnlich wie TYPO3 Backend Apps Prototype (20)

Mehr von Gernot Schulmeister

Mehr von Gernot Schulmeister (6)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

TYPO3 Backend Apps Prototype