Showing all Design Documentation
-
How much ‘work’ does a democratically representative value agenda ‘need’
Status: First draft for comment First of all, Value Prospecting is not intended to be ‘work’ it should be designed as a rewarding social interaction in itself – ‘meaningful fun’. I would like to think that repose and reflection are a natural part of the rhythms of life. There is a Judeo-Christian tradition in the…
-
Kitemarking for Societal Human Value
Status: Draft Published for comment What is ‘Kitemarking’ Kitemarking is a (british english) term for quality assurance marking, so called because the original British Standard institute Verification (BSV) mark looks like a kite… Many will be familiar with other quality assurance marks ISO, CE, UL, FSC…which are often seen stamped on consumer products or labels…
-
UIX: User Interface and experience. Development team Document
Status: Live document: Published for comment/development This document focuses on the design of the user interface, including wire-frames, mock-ups, and details on how users will interact with the system. The work relating the UI has been started, partly in the document ‘Design for Social learning’, and in part by beginning a (Figma) wire frame/mock up.…
-
DSD: Database Schema Design: Development Team document.
Status: Placeholder: for later development Since this application involves a database, a separate document is required to outline the database schema, relationships, and data storage details. Often the discipline underlying RDB schema design and the processes they are intended to support uncovers additional attributes, relations, meanings and processes. we should expect that this part of…
-
DDD: Detailed Design Document: Development Team document.
Status: Placeholder: For later development This document provides a more detailed view of the system design, specifying how each component or module will be implemented. It includes details like algorithms, data structures, and interfaces. This Link describes a single SDD/DDD scope – currently we are splitting it but both docs will contain similar headings, where…
-
SDD: System Design Description: Development Team document.
Status: Placeholder: For later development This document describes the high-level system architecture, including components, modules, data flow, and interaction between different parts of the system. This is a placeholder document at the moment. It’s not on the critical path yet but will include probaby a quite well established basic architecture for web applications, backups, scurity…
-
SRS: Software Requirements Specification: Development Team document..
Status: Priority for active development: Published for collaboration/Comment This document outlines the functional and non-functional requirements of the software. It serves as a foundation for the entire software development process. see https://www.cprime.com/resources/blog/how-to-create-a-clear-high-quality-srs-document/ SRS Document Example This is a placeholder document at the moment. Please see ‘Vision and Intent’ for a related document. Each of the…
-
Design for Social Learning
Application Interface Design for Social Learning and Perspective taking: (P)rinciples, (C)omponents and (A)ssumptions are numbered below e.g. C01 is component 1 Prerequisites: Registering Values and Prospects… P01 To express or manage human values, a shared definition is fundamental. C01 A Value Dialog: For the identification, definition (classification, characterisation), analysis, discussion, development and maintenance of a…
-
Vision and Intent
Representation, Engagement, Collaboration, Social Learning, Perspective taking, Values, Prospects and Impacts. I am asking for advice and support to make, universally available, a general method of capturing, reflecting on, developing and representing democratically, the things people care about (their Values), and what we can do about them (our Prospects). Interpreting all social human activity as an…
-
FileNote: Naming software design docs
Status: Published The specific documents required for application software design can vary based on methodologies, project requirements, and organizational preferences. However, here are some common formal documents that are typically involved in the application software design process: The actual documents needed may vary based on the complexity of the project, the development methodology (e.g., waterfall,…