Meeting with james 6th july - hamstar/Braincase GitHub Wiki

Agenda

  • Ensure that we actually need to evaluate architecture - doesn't seem like any other FOSS projects do this except for actual distributions (is this a distribution we are making or a PKB?)

Actions from last meeting

  1. Need a low priority feature for LaTeX output
  1. Need to put reqs from ghissues into Req Spec and email it to James
  • Done
  1. Need to finish the Software Review Methodology

Minutes

  • Think about more standard, less scripty ways of doing things (e.g. RPM) ** Issue: #182

  • Portfolio to be the project on github

  • So anyone can come along and see that it is a transparent organised OSS project and see:

  1. decisions
  2. Components
  3. Reqs
  4. methods
  5. norms
  • Product is the entity that surrounds Braincase
  • Braincase lives in there

Software Evaluation

  • Architecture Reqs are more like Architectural Constraints
  • Need a prologue description of the methodology
  • Justify decision by saying there is no existing single methodology for such a project
  • Some stuff missing from the diagram
  • Exceptions for requirements and skills
  • Could split the diagram to show evaluation process in more detail
  • The process of evaluating might cause us to revisit the architecture design
  • Need to make it very clear that there is iterations and adaptions
  • Need to make it a more iterative methodology
  • State what we are going to record throughout the process
  • Be clearer about selection/disqualification criteria
  • Note down the incumbances bought upon us by software
  • Licence requirements
  • Resource usage
  • Don't use our lack of skills to rule out components

Req Spec

  • Update TOC (with page numbers)
  • Add page numbers
  • Say that the doc is based on a template
  • and what standard approach we are using Generic Standard Approach
  • Definitions and Conventions can come under Requirements Elicitation Output Management
  • Stakeholders can come under System Overview and add more stakeholders
  • ourselves
  • future developers of the system
  • Add feature numbers
  • Update description of features
  • Make another category to come under features called User Scenarios (which are the use cases we did for James)
  • Update system overview
  • No specifics of OS/Software
  • Don't need superuser in user classes, maybe just a deployment manager
  • Group related features should be low prio
  • Not needed
  • #58
  • #87
  • #85
  • Check repetition on #96/#103
  • Go over use cases to check completeness
  • Requirements should explain functionality that isn't explicitly stated in the use cases but just implied
  • Get rid of requirements which are specified explicitly in use cases
  • Requirements could be listed under features instead of use cases
  • Personal Repo is still on low prio, should be high
  • Change application portability to Deployment
  • Data portability
  • Extra use case "examining contents of backup - user can unzip backup file and find files they can do something with" #191
  • Should be clear that you can still access your data if Braincase disappears #191
  • manifest file... #191
  • Don't add reqs that allow a superuser to see users data
  • Logging
  • helps further the mission of capturing knowledge
  • don't need to log stuff like edits and creations as that is stored anyway
  • makes sure errors are not occurring and notifies user if they are #190
  • check backups are happening correctly #82 #81
  • possibly implementation level
  • Non Functional Reqs
  • make a numbered list
  • store on github issue tracker

Issues

Actions

⚠️ **GitHub.com Fallback** ⚠️