Co-design | Glossary

Definition:

Co-design is a well-established approach to creative practice, it has its roots in the participatory design techniques developed in Scandinavia in the 1970s. Co-design is used as an umbrella term for participatory, co-creation and open design processes. This approach enables a wide range of people to make a creative contribution in the formulation and solution of a problem.

This approach goes beyond consultation by building and deepening equal collaboration between affected users attempting to, resolve a particular challenge. A key tenet of co-design is that users, as ‘experts’ of their own experience become central to design process. The immediate benefits of applying co-design approach includes generation of better ideas with a high degree of originality and user value, improved knowledge of customer or user needs, immediate validation of ideas and concepts, higher quality, better differentiated products or services, more efficient decision making, lower development costs and reduced development time, better cooperation between different people or organisations and across disciplines.

Further Reading:

Book: Hardware/Software Co-Design: Principles and Practice By Jorgen Staunstrup, Wayne Wolf
https://en.wikipedia.org/wiki/Participatory_design#Co-design
http://designforeurope.eu/what-co-design
https://medium.com/@thestratosgroup/co-design-a-powerful-force-for-creativity-and-collaboration-bed1e0f13d46

System Context | Glossary

Definition:

Environment of a system is termed as a system context. A System is connected to it’s environment, it never stands on its own. In order to decide who and what exerts influence on the system being developed, the system context needs to be defined. Knowing the system boundaries, you know the scope of the system.

If you define boundaries of a system you get the clarity on system you are developing, how it impacts the development process and what can be disregarded during development. On analysing the system context it determines stakeholders, processes, documents and events relevant for the system. Demarcating the system boundary defines what functionalities of a system it is supposed to offer and what interfaces to external system exist. Requirement is identified systematically, identifying the relevant context by defining systems border.  This builds foundation for evaluation of the requirements for the new system. If the context is not defined properly during requirements engineering, the system relies on incomplete and inaccurate assumptions which might lead to a faulty behaviour.

Further Reading:

https://www.microtool.de/en/what-is-the-system-context/
https://www.flamelab.de/article/defining-the-system-context/