TYPO3 Backend Apps Prototype

Requirements Engineering & Design Thinking on Backend Apps

TYPO3 Camp Hamburg 2015

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

Requirements engineeringDesign thinking

Backend app prototype

Schedule

Requirements engineering



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



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

Design Thinking



• 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



• 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

Backend app prototype(Demo)



Links

Requirements engineering:• http://t3n.de/magazin/requirements-engineering-

webprojekte-237281/Design thinking:• https://jaxenter.de/design-thinking-als-prozess-zur-

innovationsfindung-290

Internet

TYPO3 Backend Apps Prototype