Example: a comprehensive mission

This is a complete, filled-in mission for an everyday application — a community library management system. It follows the eight-section guideline you get when you create an application. Use it as a yardstick for the level of detail that produces good downstream requirements, not as a script to copy. Your domain will differ; the depth is the point.

See Writing your application mission for guidance on each section.

---

Mission Statement — Community Library System

1. Business Purpose

The Community Library System manages the lending of physical and digital items across the branches of a small public library service. It is used by library staff to catalogue items, register members, and process loans, and by members to search the catalogue, borrow and reserve items, and manage their own account online.

Its purpose is to let a small, often part-time staff run an accurate lending service with minimal manual record-keeping, and to give members self-service access to the catalogue and their loans so they don't have to phone or visit the desk for routine tasks. The intended benefits are fewer lost and mis-shelved items, less time spent on manual issue/return, and higher member satisfaction through self-service.

It is not an accounting or HR system, and it does not manage building access, room bookings, or events — those remain in the council's existing systems. It reports on stock and lending; it does not make acquisition decisions.

2. Business Scope

In scope

• Catalogue of physical items (books, audiobooks, DVDs) and e-book/e-audio licences.
• Member registration, accounts, and self-service via a web portal.
• Lending workflow: issue, return, renew, reserve, and recall.
• Overdue handling: reminders, fines (where the service charges them), and lost-item processing.
• Stock management: acquisition records, withdrawals, inter-branch transfers, stocktake.
• Reporting on stock levels, lending activity, and overdue items.

Out of scope

• Financial accounting and payment settlement (fines integrate with the council payment gateway; the ledger lives there).
• Acquisitions purchasing and supplier management (handled in the council procurement system; this system records the resulting items).
• Events, room bookings, and public-PC booking (separate systems).
• Cross-authority lending or national union catalogues (a possible later increment).

Envelope

• Used by staff at up to 8 branches and a central library, and by registered members from any web browser. Peak load is after-school and Saturday mornings. The service operates during opening hours; the member portal is available 24/7. A later phase may add a mobile app and self-service kiosks.

3. Stakeholders and User Classes

Stakeholder	Role	Interest
Member	Borrower	Easy search, borrowing, and account management; clear, fair overdue handling; privacy of their borrowing history
Library assistant	Primary desk user	Fast, reliable issue/return; minimal clicks under a queue
Branch librarian	Stock + member management	Accurate stock, reservations across branches, member problem resolution
Service manager	Oversight	Service-wide reporting, fine policy, stock decisions
Council IT	Operations	Supportability, integration with payment and identity systems, data protection
Data protection officer	Compliance	Lawful handling of member data and borrowing history; retention
Supplier/cataloguer	Data source	Clean import of catalogue records

User classes (software-interacting)

• Member — frequent, self-service: search, borrow/reserve/renew, view account.
• Library assistant — constant during opening hours: issue, return, register members.
• Branch librarian — daily: manage stock, resolve reservations, edit member records.
• Service manager — occasional: run reports, set fine and loan policy.
• Administrator — rare: configure branches, item types, loan rules, integrations.

4. Operational Concept

Items are catalogued once and held at a branch. A member searches the catalogue (in branch or online), and either borrows an available item at the desk or reserves one that is on loan or held elsewhere. Issuing an item records the loan against the member with a due date derived from the item type and member category. Returning it clears the loan and, if the item is reserved by someone else, routes it to the reservation queue rather than back to the shelf.

Loans accrue toward a due date; as that date approaches and passes, the system sends reminders and, where the service charges them, applies fines per policy. A member can renew a loan unless the item is reserved. Stock moves between branches on request and is tracked through transfer states. Staff and managers run reports over stock and lending to inform day-to-day operations and stock decisions.

5. Scenarios

Routine borrow and return. A member brings three books to the desk. The assistant scans the member card and each item; the system records three loans with due dates and prints (or emails) a receipt. Two weeks later the member returns them; the assistant scans each item, the loans clear, and the items return to the shelf.

Reservation and collection. A member reserves a title that is all on loan. When a copy is returned at any branch, the system holds it for the member, notifies them, and routes it to their collection branch. The member collects it within the hold window; if they don't, it passes to the next reservation or returns to stock.

Overdue and fine. A loan passes its due date. The system sends a reminder, then a second reminder, then applies a fine per the service's policy. The member pays online through the council payment gateway; the system records the payment as settled and lifts any borrowing block.

Lost item. A member reports an item lost. Staff mark it lost; the system applies the replacement charge per policy and withdraws the item from stock. If the item is later found, staff reverse the charge and return it to stock.

Inter-branch transfer. A reservation can only be met by a copy at another branch. The system raises a transfer; staff dispatch and receive it through transfer states, and it becomes available at the collection branch.

Member self-service and privacy. A member logs into the portal, renews a loan, updates their contact details, and views their current loans — but not another member's, and the system does not expose their full historic borrowing list beyond what policy allows.

6. Assumptions

• Members are identified by a library card number issued at registration; the council's identity system is not required for basic membership.
• The council payment gateway is available for fine and replacement-charge settlement; the system records outcomes but does not hold card data.
• Catalogue records are imported in a recognised bibliographic format from the supplier.
• Branches have reliable network connectivity during opening hours; brief outages are tolerated by queuing desk transactions for later sync.
• Staff receive basic training on the desk workflow; members need no training for the portal beyond on-screen guidance.

7. Constraints

Operational

• Desk issue/return must be fast enough to keep a queue moving (a few seconds per item).
• The member portal must be usable on a low-end phone over a slow connection.
• The service operates with limited, often part-time staff — workflows must be simple.

Commercial / organisational

• Must fit within the council's existing payment and identity platforms rather than introduce new ones.
• Fine and loan policies are set by the service and must be configurable, not hard-coded.

Technical

• Integrate with the council payment gateway and the supplier's catalogue import format.
• Run within the council's hosting and browser-support baseline.
• Barcode scanning at the desk using standard library card and item barcodes.

8. References and Applicable Standards

Reference	Applies to
UK GDPR / Data Protection Act 2018	Member personal data and borrowing history — lawful basis, retention, and the right to erasure
WCAG 2.1 AA	The member-facing web portal — accessibility
Council information-security policy	Authentication, data-at-rest handling, supportability
Bibliographic import format (e.g. MARC 21 / ONIX)	Catalogue record import from suppliers

(For an application with no external standards, this section would simply read "None".)