typo3 backend apps prototype
TRANSCRIPT
Gernot Schulmeister | [email protected] 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
Gernot Schulmeister | [email protected] 09.08.2015 Seite 5wfp:2 GmbH & Co. KG Mönchengladbach | www.wfp2.com
Requirements engineering & design thinking on backend apps
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
Gernot Schulmeister | [email protected] 09.08.2015 Seite 6wfp:2 GmbH & Co. KG Mönchengladbach | www.wfp2.com
Requirements engineering & design thinking on backend apps
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
Gernot Schulmeister | [email protected] 09.08.2015 Seite 7wfp:2 GmbH & Co. KG Mönchengladbach | www.wfp2.com
Requirements engineering & design thinking on backend apps
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
Gernot Schulmeister | [email protected] 09.08.2015 Seite 8wfp:2 GmbH & Co. KG Mönchengladbach | www.wfp2.com
Requirements engineering & design thinking on backend apps
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
Gernot Schulmeister | [email protected] 09.08.2015 Seite 9wfp:2 GmbH & Co. KG Mönchengladbach | www.wfp2.com
Requirements engineering & design thinking on backend apps
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
Gernot Schulmeister | [email protected] 09.08.2015 Seite 10wfp:2 GmbH & Co. KG Mönchengladbach | www.wfp2.com
Requirements engineering & design thinking on backend apps
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
Gernot Schulmeister | [email protected] 09.08.2015 Seite 11wfp:2 GmbH & Co. KG Mönchengladbach | www.wfp2.com
Requirements engineering & design thinking on backend apps
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
Gernot Schulmeister | [email protected] 09.08.2015 Seite 12wfp:2 GmbH & Co. KG Mönchengladbach | www.wfp2.com
Requirements engineering & design thinking on backend apps
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
Gernot Schulmeister | [email protected] 09.08.2015 Seite 13wfp:2 GmbH & Co. KG Mönchengladbach | www.wfp2.com
Requirements engineering & design thinking on backend apps
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
Gernot Schulmeister | [email protected] 09.08.2015 Seite 15wfp:2 GmbH & Co. KG Mönchengladbach | www.wfp2.com
Requirements engineering & design thinking on backend apps
• Process to make innovations supported by manyProblems 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
Gernot Schulmeister | [email protected] 09.08.2015 Seite 16wfp:2 GmbH & Co. KG Mönchengladbach | www.wfp2.com
Requirements engineering & design thinking on backend apps
• 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
Gernot Schulmeister | [email protected] 09.08.2015 Seite 17wfp:2 GmbH & Co. KG Mönchengladbach | www.wfp2.com
Requirements engineering & design thinking on backend apps
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
Gernot Schulmeister | [email protected] 09.08.2015 Seite 18wfp:2 GmbH & Co. KG Mönchengladbach | www.wfp2.com
Requirements engineering & design thinking on backend apps
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
Gernot Schulmeister | [email protected] 09.08.2015 Seite 19wfp:2 GmbH & Co. KG Mönchengladbach | www.wfp2.com
Requirements engineering & design thinking on backend apps
Process
• Double diamond: problem and solution space• Start is a challenge as a question• Divergance: get new insights• Convergance: sort, priorisize and select
Gernot Schulmeister | [email protected] 09.08.2015 Seite 20wfp:2 GmbH & Co. KG Mönchengladbach | www.wfp2.com
Requirements engineering & design thinking on backend apps
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
Gernot Schulmeister | [email protected] 09.08.2015 Seite 22wfp:2 GmbH & Co. KG Mönchengladbach | www.wfp2.com
Requirements engineering & design thinking on backend apps
Links
Requirements engineering:• http://t3n.de/magazin/requirements-engineering-
webprojekte-237281/Design thinking:• https://jaxenter.de/design-thinking-als-prozess-zur-
innovationsfindung-290