Solution basics

The first dive into the specification and all its aspects: exploring the definition of the solution and its various elements, such as modules, pages, and more.

This article will explain each of the elements in Uniscale that allows you to describe and structure your specification. If you want to start using Uniscale, please check our Quick start guide

Solution elements

In this article, we will explain each of the elements in Uniscale that allows you to break describe and structure your specification.

In this video you will get a short introduction to the structure of a specification:

Solution

A solution is the product, project, or system that you are working on. It contains all the information such as your functional specification and technical documentation.

In Uniscale, we provide various elements to describe and structure your solution. In this article, we will go through each of the elements and explain their purpose and functionality.

Module

A module is a functionally isolated part of the software that has distinct ownership over its functionality and revision lifecycle.

Modules let you place a boundary in the solution at points where it makes sense to divide responsibilities for parts of the software.

Best practices for creating modules

To to create a module:

Modules: Advanced concepts

Defining module boundaries

Create clear boundaries in your software where responsibilities naturally divide. Modules are self-contained parts of the software with specific ownership and independent updates.

Clear module boundaries are crucial for your organization.

Modules to follow your product structure

Each module update should be treated as a separate project. Keep changes mostly within one module. Group elements that evolve together. This makes your application easier to update and maintain.

This approach allows you to scale as your solution evolves.

Organize modules based on ownership

Defining your module boundaries allows you to shape how your organization will grow. Grouping functionality through module and service boundaries affects the future structure of the organization. It's best to have a single team own an entire module to avoid shared ownership issues.

This prevents the need for separate projects that are tightly coupled and must be released together.

Functional use case

Functional use cases describe the user behavior within a module or page. This is in contrast to pages and sections that describe the structure.

A functional use case (FUC) can be used for two purposes:

Abstract: To describe the high-level user behavior of a module. An example can be to describe how a new user to your product should be onboarded.
Concrete: To describe the concrete behavior of a page or section. An example can be to describe concrete steps for what should happen when clicking on a button.

A Functional use case can further be broken down into the following elements:

UI Designer notes

For every User Interface (UI) element there is a UI designer note where your designer or product lead can describe the functionality and the restrictions you envision for that part of the UI.

Examples of a UI designer notes

Displayed information
Buttons
Areas that can expand and collapse
Drag and drop interfaces
Popups and triggered displays of information

UX Product notes

The UX Product notes allow you to add notes and provide a detailed description regarding the intended user experience for a specific functional use case.

UX flow

UX flows describe the detailed behaviors within functional use cases.

Functional acceptance criteria

A list of qualifications that the implementation of the UX flow needs to fulfill.

Examples of functional acceptance criteria

Assurances for accessibility of variable screen types and sizes (don't show on mobile, etc)
Front-end effects and animations (disabled buttons, etc)
Error handling such as password length not matching, etc

You can use our generative AI to help suggest acceptance criteria. Learn more here: Tutorial: Using AI in Specification

Service flow

Service flows are the first steps towards creating your technical documentation.

This part should be done by people familiar with your existing services, like a Solution Architect or Tech Lead.

For each UX flow in your solution, you can create a Service flow to begin to link your functional specification directly to your services.

Service

A service refers to a discrete unit of functionality or capability provided by a system or application.

Each service is defined by its inputs, outputs, behavior, and interactions with other components of the system. Describe the requirements for the underlying technical flows that will enable you to build the desired functionality.

To learn more about Services, visit our detailed Service basics article

Functionalities

Rich text editor

Our Rich text editor allows you to write your specifications using advanced styling options (heading, bold, italic, bullet points, and many more) and to embed media, images, and hyperlinks.

AI Functionality

Our AI functionality will provide your code generator with the needed domain-driven product information so you can work on your code much faster and with reduced costs.

Comments

You can also comment on different sections of your solution allowing you to add notes to the development process that can be seen and answered by your colleagues.

Commands

Uniscale offers a wide range of commands that allow you to write your specifications and build your solution in a matter of one simple click.