When this is done, you are ready to follow the guide below on how to build better software.
Phase 1: Specification
The specification, also known as “Functional Requirement Specification”, is a document used to describe a solution's intended capabilities, appearance, and interactions with users.
To describe your specification, start by creating a solution
Within your Uniscale workspace, create a solution to describe your product and outline the functional specifications.
High-level specification
Intro to high-level specification
Here you will describe the overall solution. This part is done from an abstract view, meaning that it is not about solving the actual problem, but rather explaining the problem and desired outcome carefully.
Things you may include:
Abstract Description
Purpose and motivation
High-level requirements
High-level end-user behavior
This is typically defined by the Founder, Visionary, Product Owner, or someone who understands the solution.
Describe your high-level specification
Define and describe your modules
Enrich your Functional use case with Acceptance criteria.
This is where you will start to design how the actual product will look and feel. Where high-level specification is abstract, here you will define concretely how the product will work:
Should it be an app, website, software, physical paper, or a combination?
How should the user interface look and feel?
The overall layout of your solution including visuals (mockups or wireframes),
How should the product work - eg. what pages will you need, what buttons to include, what should happen when clicking on each button, and what should happen in case of errors?
For this part, you will involve a product designer (eg. UX/UI designer) who will start to break down the high-level specification and design the product.
Use Pages and Sections to break down the layout and structure of your solution
A best practice is to include mockups or wireframes for each part of your solution
Include UX requirements:
Break down your modules and pages into Functional use cases.
Include relevant UX flows
Describe your UX flows and include Functional acceptance criteria
Include UI requirements: Use Designer notes to describe the look and feel in addition to other descriptions that are helpful to the front-end developer.
Service linking is where you bridge your functional specification to your technical documentation.
Introduction to service linking
Typically, a Solution Architect or Technical Lead handles this phase. They translate customer requirements into logical service boundaries by developing the services needed to meet the specified requirements.
The documentation also referred to as Technical documentation, is where you define the requirements and the building blocks to support your functional specification.
High-level documentation
Introduction to high-level documentation
The documentation often referred to as "Technical Documentation," is where the focus shifts to the technical details of your product.
This part is typically created by experts such as Tech Leads or Solution Architects. They ensure the technical and non-technical aspects of your solution are aligned, even if they are not directly involved in coding.
Describing your high-level documentation
As you have now linked your UX flows to Service flows, you will start to document the intention and purpose of each service.
Now you can include a description of each service to document the service functionality requirements.
See a detailed guide to describing your documentation: Service basics
Detailed documentation
Introduction to detailed documentation
This is where you define all concrete actions and data contracts to fulfill all specified technical functionality.
This part includes:
Endpoint modeling
Error code and sample data
Data contracts modeling
Data validations
Describing your detailed documentation
Navigate to the service and begin to document the technical aspect.
This is the toolbox that the developers can use to build the product. The toolbox consists of all the information that is created in the specification and documentation. It contains everything that you need to do the communication between your frontend and backend
Generating the SDK
Start by navigating to the SDK portal from the navigation bar.
You can now select from your approved modules and services. If you do not see anything, please check the steps Module revision and Service revisions
Select your preferred development language
Select "Save changes". This will start generating the SDK.
Begin with an introduction to your solution. We have made a template for you to use here:
Define and create your modules: For best practices on what modules to create, visit this article:
Describe your modules: Write a short description and include the relevant high-level functionalities and actors related to this module. See for more details.
Describe the high-level end-user behavior: This is done by creating an Functional use case inside your module. See for more details.
