GLOSSARY
What do we mean by that?
You shouldn’t need our technical vocabulary to make decisions about your software. Here are a few terms in plain language.
15 terms
- MSP+
- Our name for building and running software with one partner. A managed service provider (MSP) runs IT for an organisation. The plus: we run the software we build for you. The scope of ongoing support and maintenance is set out for each engagement.How building and running fit together
- Scenario
- A concrete description of a situation, an action and the expected outcome. Relevant conditions and exceptions explain when the description applies. A scenario makes a process question discussable; it does not by itself establish that software behaves that way.Example: An employee completes a job sheet. If required information is missing, it stays open and shows what is still needed.A question to ask: Which starting conditions and exceptions matter?
- Expectation
- The behaviour or result that should occur in a described situation. It is more specific than a broad goal such as ‘easy to use’ or ‘efficient’. It explains what someone should be able to do or observe under particular conditions.Example: After a delivery date changes, scheduling sees the new date against the correct order.A question to ask: What exactly should someone be able to see or do?
- Check
- A comparison between a stated expectation and an observed result. The circumstances belong with it: which version, data and settings were used? A standalone success message does not explain which question was examined.Example: Compare the expected delivery date with the date shown in the scheduling overview after a change.A question to ask: Which expectation was compared with which observation?
- Exception
- A situation where the usual rule does not apply or a different response is needed. An exception is not automatically an error. It may be a familiar part of everyday work for which no clear path has yet been agreed.Example: A job has been carried out, but one item will be delivered later. Neither ‘fully complete’ nor ‘not started’ describes it well.A question to ask: Who can choose a different path, and what must follow?
- Coverage
- The situations and subjects that were actually examined. Coverage also identifies what falls outside an assessment. A passing check for one process rule is not a conclusion about every rule, every dataset or every condition.Example: A check with one user does not establish how the software behaves when many people use it at once.A question to ask: Which important situations have we not examined?
- Custom software
- Software developed for a particular need or way of working. It can be a bounded application or a missing step between existing systems. Alongside development, it requires choices about ongoing use, maintenance and changes.Example: An application that supports a specific handover process that existing products do not handle well.A question to ask: What is actually missing from the solutions we already have?When custom software is worth it
- Scope
- The agreed extent of an engagement: what is included, for whom and under which conditions. What remains outside the engagement belongs in the description too. A new request can be valuable without automatically becoming part of the existing agreement.Example: The first step supports the handover to scheduling. Changes to invoicing are outside it for now.A question to ask: What belongs in this step, and what remains separate?
- Acceptance criteria
- Specific conditions that help the people involved assess whether an agreed part meets expectations. They structure the conversation about delivery. They cover what has been agreed and do not replace every other form of investigation.Example: A planner can see which jobs are waiting for information and what information is missing.A question to ask: What will allow us to assess this outcome?
- Integration
- A connection through which systems exchange information. Integration needs agreement about the meaning of data, when it is exchanged and what happens if a message does not arrive. A technical connection alone does not resolve these questions.Example: An address change needs to reach the same customer record in two different systems.A question to ask: Which system is authoritative, and how are differences handled?
- API
- An agreed way for software to make information or functions available to other software. An API can make integration possible. Its suitability depends on the functions, access and arrangements the provider makes available.Example: A scheduling system exposes a function that another application can use to request the status of a job.A question to ask: Does the available interface provide the information we need?
- Version
- An identifiable state of software or a description at a particular moment. Distinguishing versions helps people discuss changes and connect an observation to the right state. A result from an earlier version does not automatically apply to a later one.Example: A rule changed after the last review. The earlier result does not assess that change.A question to ask: Which version does this agreement or observation concern?
- Environment
- The systems, settings and data in which software runs. Development, test and production environments may be configured differently. Those differences can matter when interpreting a result or preparing a change.Example: A test uses fictional data, while everyday use depends on information from another system.A question to ask: Which conditions differ from real use?
- Operation and maintenance
- The work needed to keep software in use after delivery. Its scope depends on the arrangements made. It may include changes, updates and handling problems. The term alone does not establish availability or response times.Example: An external service changes. Someone needs to assess the effect on an existing integration.A question to ask: Who is responsible for what, and which arrangements apply?Operations in our approach
- Handover
- Transferring knowledge, resources and responsibilities so another team or provider can continue the work. The information, access and rights needed depend on the situation and the agreements. These need to be made specific.Example: Another team takes over day-to-day operation and needs to understand the setup and known issues.A question to ask: What does the next responsible team need to carry on?
A GOOD START
Where does work get stuck?
Start with one situation.Get in touch