High-level specification

Learn how to describe your high-level specification along with best practices.

Before kick-starting your Uniscale journey you should have:

1. Create an account

2. Create a workspace

3. Invite to a workspace

When this is done, you are ready to follow the guide below on how to build better software!

Introduction

The specification, or functional requirement specification, is where you specify the overall idea. This includes an introduction, the main challenge, why you are going to solve this, and on a high level your approach to solving this.

This part is done from an abstract view, meaning that it is not about solving the actual problem, but rather carefully explaining what the problem is and what the desired outcome is.

This is typically defined by the Founder, Visionary, Product Owner, or someone who understands the solution.

Best practice

Cater to your audience

Aim for a short and concise description. Cater the message to your audience whether this is for internal or external stakeholders.

Tip: Make use of our Generative AI to help improve your writing. Learn more here: Tutorial: Using AI in Specification

Keep it at an abstract level

Focus on describing the key challenge and purpose of your specification and leave the concrete steps to solving the issue for later. This will help you make sure that people are aligned on the overall goals and that your solution will meet the customer's requirements.

Describe your high-level specification

Tutorial: High-level specification

To help you get started, here are some inspirations for what to include in your specifications.

Copy the template below into your solution description. This will guide you to include the essential parts of your high-level specification

What - Solution description

• Short description: Explain in a few sentences what your solution is doing.

• List 3-5 high-level functionalities and features of your solution.

Why - Purpose and motivation

Describe to your audience what the purpose of your solution is.

• What value does it bring?

• What are the desired outcomes that you want to achieve?

• What are the struggles and challenges you see for example in the market?

Who - Actors in the solution

• Name and list all the different types of actors that use his solution.

Data sources in the solution

• This data may come as actor input to the system, external data sources where information is imported from, or any other sources.

• When listing the data sources you might just discover some missing actors.

Grouped actors

Do some of your actors belong to specific named groupings?

High-level functionality and divided by actors or grouped actors*

• [Insert high-level functionality] - [insert actor or grouped actor]

• [Insert high-level functionality] - [insert actor or grouped actor]

• [Insert high-level functionality] - [insert actor or grouped actor]

*Note: The named list of functionality groupings are likely your modules.

Create and describe your first modules

Before creating modules, we recommend reading our guide for best practices: Best practices for creating modules

Module description

The description of your module is where you describe the purpose and intention for this specific module.

💡 Tip: You can re-use the relevant information you described in your high-level specification.

Here are relevant things to include:

• Intended functionality for the specific module.

• What is the exact action that this module intends to achieve?

• Detailed explanation of what this module is supposed to do and how it proposes to achieve it

• Actors: Who is going to interact with this module?

Break your modules into pages for grouping functionality

Pages are an element for structure, where you can organize and group your functional use cases. Often used (if needed) when you have locked in the first revision.

You can read more about Pages here: #page

Functional use cases - high level definition & user story

• This is the high-level behavior: a clear description of the high-level functionality intended for the user (this usually entails an action/ taking the user from point A to point B

• A good logic to follow is that you should describe the functional use case with:

  • Define the actor and their needs.

  • Describe what each actor wants to achieve.

  • Define their desired outcome.

• Examples: House cleaning app: As a house owner, when my house is dirty, I want to book a cleaner, so that my house is cleaned.

You can read more here: Functional use case

Add Acceptance criteria to your Functional use cases

• Describe what this is and how it will work

• Note; Our Generative AI can help write suggestions for what acceptance criteria to include: AI-generated acceptance criteria

• Definition: a list of qualifications that the functional use case (UX flow if detailed specification?) needs to fulfill

---

Next steps

• You can already now choose to approve your first revision: Module revision

• Involve your product designer and begin the Detailed specification