Software consultancy

Software design

A specification you can price from, or a written roadmap for a system that already runs. The cheapest place to fix a design is on paper, so this covers requirements through to extensibility, security, and stability before anyone writes a line.

Software requirements

  1. Informal and formal requirements work aimed at a functional specification: what the software must do to meet the business goal. A functional specification is usually required before a quote on anything that will see a large deployment or touch core operations, because it is the document that stops the price moving later.
  2. A technical specification then says how it will be built: user interface, entities, how they interact, and usually the database design. Duration and cost get tighter at that point.

Software architecture

Informal diagrams for a meeting, and formal ones for a specification. We use UML unless the job is healthcare, in which case the modelling is typically HL7.

Performance, recovery, tests, documentation

  1. Performance tests on an existing system, to find the bottleneck and say what would actually help
  2. Disaster recovery, backup, restore testing, and continuity, including geo-replication when the system cannot be lost
  3. Unit tests, capacity tests, and manual QA, either installed from scratch or improved from the ones you already have
  4. User guides through to functional and technical documents, for a system you already run or one we are about to build