How to draw up the specifications for a bespoke application in order to define its scope

A list of screens and features alone does not yet define a clear scope for the application. Describe the business objectives, the users, their workflows, integrations and technical requirements so that the team knows what is to be built and how to proceed. This is how you prepare the technical specification for a bespoke application.

A good description of requirements clarifies the idea and makes it easier to discuss the project. It is not the length of the document that matters, but the specifics: who will use the application, what problem it is designed to solve, and how you will know that it is working as intended.

You’ll learn how to describe objectives, functions and user scenarios, set priorities, and take into account integrations, security and performance. This will enable you to turn your idea into a scope that can be jointly assessed and developed.

Key findings

• Please specify the platforms and devices on which the application is to run, and the systems it should connect to.
• Describe users’ tasks step by step, rather than simply listing the screens.
• Link the business objective to the problem the application is designed to solve, and specify how you will recognise the expected outcome.
• Group the features by priority to define the scope of the first release and plan for further development.

Table of Contents

• What are the requirements for a bespoke application?
• What is a functional specification for mobile and web applications, and how do you create one?
• Business objectives and the problem the application solves
• The role of the application’s technical specification
• Internet Stars: Dedicated apps

What are the requirements for a bespoke application?

The requirements specify what the application is intended to do, on which platforms it is to run, and with which systems it is to interface. The technical specification should cover functional and non-functional requirements, integrations and acceptance criteria. The test plan describes how to verify that the criteria have been met.

1. Defining platforms and technical requirements Specify whether the application is to run on Android, iOS or both, and list the supported devices. For the web version, list the browsers and screen resolutions. Describe the requirements regarding security, performance, scalability, localisation, technology and infrastructure. Estimate traffic levels and the periods during which they occur. If the app is to work without an internet connection, include this in the requirements. Specific device limitations will help the team assess the scope of work.
2. Identifying processes and existing systems Describe the business process that the application is intended to support, and indicate where it will fit into the company’s current operations. List the systems used by the team and the data exchanged between them. For each integration, state the name of the system and its owner. Specify what should happen when data is changed in one of the systems and in the event of an error. This will help the developers understand how the solution is intended to work in day-to-day operations, rather than just on screen.
3. Inclusion of external systems and APIs: Describe each external integration separately. Specify the system, API documentation, test environment and technical contact at the supplier’s end. If the scope of the API is unknown or the system does not provide one, state this in the document. Also include documentation for the hardware with which the application is intended to interoperate. Formulate acceptance criteria as verifiable outcomes, such as correct data storage or the generation of a report. The test plan should specify which scenarios will confirm that these criteria have been met. Gov.pl recommends a separate test environment, functionally equivalent to the production environment, intended for functional testing and for verifying fixes and changes.

Specify the user groups, the frequency with which they perform their tasks, the devices they use and their working conditions. If the scope of the API is unknown or if there is no API, please indicate this in the brief.

What is a functional specification for mobile and web applications, and how do you create one?

The functional specification describes what the user can do and how the system is expected to respond. The technical document expands on these points to set out the conditions required for implementation. The duration of the analysis depends on the scope of the project, the number of roles involved and the pace of decision-making.

1. Describing functions from the user’s perspective. Break down the tasks for each role into specific user stories. Example: “As a manager, I want to approve an order so that its fulfilment can begin.” Add the necessary data and permissions. Consider how to prepare the technical specification for a bespoke application for different users. Do not limit yourself to the name of the function; omit the description of its purpose and outcome.
2. Prioritising features: Categorise features as required at launch, recommended, optional and outside the scope. In an order management application, the ability to create a request might be essential at launch, whilst an additional report view could be deferred. Such priorities make it easier to draw up a schedule and to tailor the scope and approach to collaboration. Also note which ideas will be reconsidered at the next stage.
3. Defining application screens and states. Describe the user’s journey from the start of a task to its completion. For a form, specify the empty, correctly completed and incorrect states. Add details of what happens after the data is submitted and how the user can return to editing. When considering how to prepare the technical specification for a bespoke application, include interface sketches if they help to explain the layout or how the application is used.
4. Estimating user experience and functional complexity: Estimate the number of screens based on user histories and complete scenarios. A single task may involve searching, viewing details and confirming an action. Also describe exceptional situations, such as no results or a lost connection. This information helps to assess the complexity of a mobile or browser-based application and to plan the development of subsequent modules.

Start your requirements specification with the business objective and scope of work, then define the functions, user interactions with the system and non-functional requirements. Keep them brief and to the point: outline the main objectives, plans and specific features of the project. Indicate who will use the application, how it will be accessed and how different user groups operate. This will ensure you take into account the context in which the system is used, rather than just its individual components.

A list of functions alone is not enough if it fails to take into account the users, the purpose of the action and its outcome. Functional requirements should describe what users can do, including administrator privileges. User stories help to estimate the number of screens to be designed and coded, and to make a preliminary assessment of functional complexity. You should therefore link each feature to the person who uses it and the outcome they are intended to achieve. This approach facilitates a consistent definition of the project’s requirements.

Business objectives and the problem the application solves

Describe the problem the app is designed to solve and the business outcome it is intended to deliver. Start with how things are currently done, rather than with a list of ideas.

1. Defining objectives and the business model To begin with, define the main objectives of the project. Is the app intended to streamline order processing, reduce manual data entry or open up a new sales channel? Choose an objective that can be linked to a specific business activity.Also describe the business model: who will use the application, who will pay for it, and how is it intended to generate revenue? In the case of a booking platform, distinguish between the guest, the service provider and the administrator. Each role may have different tasks and expectations. Add what outcome each role is expected to achieve. Set out the objectives in a brief project description. For example, a mobile app for sales representatives could be used to log visits and submit orders. Explain why the current process is insufficient and how the new tool will fit into the company’s revenue model. Do not assume that the app alone will improve business performance.
2. Taking changes to business processes into account: Set out the current workflow for the task, then describe the planned change. If an employee currently takes a request over the phone and the application is to move this stage to a form, determine who will check the data and what will happen once the request has been submitted. Consider the impact of the change on roles, decision-making and the flow of information. The new system may alter the workflow of the customer service department and the way a manager approves cases. Note which tasks the application will take over and which will still be carried out by a person. Also list exceptional situations, such as incorrect data or the absence of a person authorised to make a decision.Compare the process flow before and after implementation. Such a review will show whether the features support the business objective or merely replicate the old steps on screen. Gather feedback from the people who will be using the application. Their day-to-day tasks will help to clarify the scope, prepare for implementation and minimise discrepancies between the project’s objectives and the company’s operations.

The role of the application’s technical specification

An incomplete specification leaves decisions to the developers, increases the risk of discrepancies and makes acceptance more difficult. Minimise this risk by describing the behaviour of functions, dependencies, devices and measurable acceptance criteria.

1. Establish the document as a common point of reference. Compile the business, functional and technical requirements within it, rather than scattering decisions across emails and wireframes. A list of features alone is not enough. Specify what data each feature processes, who uses it and what output the system should return. This will ensure that the project owner, designer and developers are all working from the same set of assumptions.
2. Describe the behaviour, not just the name of the function. Instead of simply writing ‘reports’, specify who runs the report, what data they select and what result they receive. Also list edge cases, such as missing data or a failed save. A specific description provides the software development team with a basis for design, implementation and testing. Separate expectations from technical decisions, which depend on the analysis of the solution.
3. Document the non-functional requirements and dependencies. Specify the expected performance, security, scalability and runtime environment. Indicate which systems the application is to exchange data with and what technical documentation supports the integration. Take end-user devices into account, as their limitations may influence the choice of features. Failure to take these conditions into account may result in the team designing a solution that is ill-suited to the actual use case.
4. Establish measurable acceptance criteria. Set out how you will know that the feature is working as intended. In the case of a form, this might involve saving the data correctly and highlighting fields that need correcting. Link each criterion to a requirement and a test scenario. This will make it easier to evaluate the finished module and, should changes be made, will show which agreements need updating.
5. Treat the specification as a document that evolves alongside the product. Revise it when module testing reveals new requirements or the project vision changes. Describe the installation, dependencies, algorithms, and the layout and behaviour of components when documenting the solution for the technical team. For larger projects, organise updates by module so that you can easily link a change to a feature and its criteria. Discuss the scope of the application when you need to translate requirements into a development plan.

Internet Stars: Dedicated apps

Internet Stars develops bespoke applications for businesses that require software tailored to their own processes. Get in touch with the team if you’ve already identified a problem but need help translating it into a scope of functions, user roles and an action plan. The specification will make it easier to discuss what the application should do and how it will fit into the company’s day-to-day operations.

If the project links an app to an online shop or requires the automation of repetitive tasks, please include these dependencies in the description. Specific scenarios, expected outcomes and recommended integrations will help to clarify the requirements before further planning. Do you have an idea for a bespoke app? Get in touch with Internet Stars and tell us about your project.

Turn the assumptions into the next stage of the project

The specification is also intended to help you make decisions as the project gains momentum. Treat it as a reference point when deciding which requirements to develop now and which to leave for later. This will ensure that the product’s direction is guided by the company’s objectives, rather than by ideas added on without a shared plan.

You now know how to draw up the technical specifications for a bespoke application. Use this knowledge to discuss how to translate these requirements into a product developed in collaboration with the company. When new requirements arise, go back to the project’s objective and decide whether they change its direction or merely extend its scope. This will enable you to plan the next steps without losing sight of the business rationale behind the solution.

Internet Stars has been in operation since 2008, and its team creates digital solutions for businesses. If you’d like to discuss your idea and work out what the next step might be, get in touch with Internet Stars about your project. Start with the goal you want to achieve, and build on that.

Frequently Asked Questions

Does the specification have to include mock-ups?

No, mock-ups are not essential for drawing up specifications. They are useful when you need to illustrate the layout of an unusual view or agree on how the application should be used with its users. They can take the form of a hand-drawn sketch or a clickable prototype. If the team has differing interpretations of a feature’s description, a mock-up allows you to quickly highlight the point of contention without prejudging the final look of the interface.

What can and cannot be included in requirements specifications?

The specification sets out expectations and describes the system’s operational boundaries, but it does not make business decisions on behalf of the company. It can indicate who uses the features, what data they enter and what output they are expected to receive. It cannot replace a discussion about priorities, nor can it resolve every detail of the project. Treat it as a shared basis for agreement, which can be updated as assumptions change.

Can the contractor draw up the specifications?

The contractor may draw up the specifications as part of the project analysis, working in collaboration with people who are familiar with the company and its processes. The team helps to translate the requirements into a description of functions, constraints and dependencies. Decisions regarding objectives and working methods remain with the company. Jointly drafting the document makes it easier to identify discrepancies before they make their way into the implementation plan.

Why are specifications so important?

The specification helps you refer back to the agreed terms when a new idea or a request for a change arises during the project. You can assess whether it falls within the agreed scope or whether it requires the work to be replanned. Without a written point of reference, it is easy to confuse the original assumptions with subsequent decisions. The document therefore supports both the start of the project and discussions about the next stages.

Why is it important to draw up a suitable technical document specification?

A well-organised document facilitates the transfer of knowledge between those involved in the project. When the team composition changes, a new member can reconstruct the reasoning behind previous decisions and understand the interdependencies between the system’s components. Record the date of the decision, the person responsible for it and the related features. This record of decisions reduces the risk of different people developing the application based on conflicting assumptions.

How do you write a functional requirements specification?

Start by describing the user’s task, then add the conditions under which it begins and the expected outcome. Example: the operator selects a job, changes its status, and the system records the author and the time of the change. Also consider what happens if the save fails and how the error is displayed. Finally, link the requirement to a test that will verify whether the function works as described.

An article by

Andrzej Klimek

Owner of Internet Stars since 2008