Dear community, a good concept is a useful foundation for subsequent development. Unfortunately, there is often no concept at all, or there are weak concepts that don’t offer much value.
Therefore, I have compiled a few points below that I consider essential elements for a concept. The list is certainly not exhaustive, but it is helpful for comparing it with my own approach to writing concepts. If you have any other ideas, please feel free to contact me so I can expand the list.
A concept…
- should be clearly structured in chapters and written in short, simple sentences so that it is easy for the reader to understand and quickly search.
- should include an introduction or motivation as to why a concept is needed in the first place or why it needs to be developed at all.
- should provide answers to the question “How do we implement our business requirements in practice?”
- should name contact persons.
- should contain business and technical terms.
- can be structured according to the following aspects: organisation, process, data, system, communication and security.
- should contain a function model and a data model. The data model is followed by the function model.
- should contain a reference to the requirements (e.g. business processes).
- should provide information about the technical and business objects to be developed (e.g. if developing object-oriented).
- should be easily accessible and editable for all stakeholders.
- should be agreed upon before development begins.
- should provide information about the user interface (input and output fields, interaction options, etc.). A mockup is also welcome.
- can be designed according to the input/process/output (IPO) principle in many places because it frequently occurs.
- must describe the behavior of an application in the event of errors and success.
- must also address non-functional requirements such as load distribution, security, clean code specifications and more.
- may contain specific names for development objects so that a developer doesn’t have to spend too much time naming them.
- should address the issue of testability early on (at least via unit tests).
- may contain implementation effort estimates as a guide for a developer.
- should clarify what constitutes a self-contained development that can be given to a developer or development team as a package (implementation distribution).
- may be read by an uninvolved consultant or developer to determine whether the concept is comprehensible (quality control).
- should name existing development objects like tables to use.
- must highlight roles and responsibilities, especially when different teams are involved in the development (e.g. programming team and security team).
Good luck with your next concept
Michael