Best Application Specification Template 2020

Best Application Specification Template 2020 In principle, everyone agrees on the interest of a specification, but in practice, the question is often: “yes, but what do I put in these specifications?”

Application Specification Template

To help you, here is a non-exhaustive list of what you can indicate in your specifications. It may inspire you, but it’s up to you to make it your own and complete it according to your needs. No worries, this will just be a first version that we will work on together.

Some essential details

  • The versions

It is advisable to keep a summary table of the different versions and their dates, to more easily follow the game app development company of the project.

  • The table of contents

It allows the reader to have a first overview of the project. Although it may seem like a simple navigation tool, it is in fact a first reading of the specifications.

  • Lexicon

Your job may require using technical words that we are likely not to understand. No worries, all you need to do is provide a quick lexicon.

Context of the project

  • Company presentation

This part is sometimes neglected, sometimes very extensive. It’s up to you to find the right ratio. Do not overdo it, but do not forget to say the essentials so that the actors of the project understand all the issues.

  • The objectives of the project

The role of the application, the solutions that the application provides, the innovation of use for the user …

  • Project targets

Marketing targets or usage targets: Personas (imaginary characters to whom we attribute a name, age, profession, purchasing habits, etc.)

  • Existing interfaces

Responsive site, Web app, POC, redesign of an existing application, etc?

What interfaces do you have? Will they be replaced by the application? Will they have to interact with the application? The ideal is to describe the current eco-system and how the application will fit into it. For this part, a diagram is often much clearer than long sentences.

  • Competition

If competition, it is interesting to expose your differentiations and your similarities compared to the uses and functionalities provided by your competitors.

Presentation of the project

  • The platform (s): iOS, Android, web …
  • Equipment: mobile, tablet (portrait, landscape or both). If it is a unique piece of equipment because the whole company will be equipped with the same smartphone or the same tablet, it should be specified.
  • Economic model :
    • free or paid application,
    • subscription,
    • selling products,
    • publicity…
  • The expected result: do you want a POC to present to investors or a finished product to put on the market?

Description of the project

Functional description

It is a question of describing all the functionalities that you will bring to the user.

  • The user journey

It can be described via a diagram, a list of screens to which it will access, or even user stories ( Phrases simply describing a feature to be developed ). It’s up to you to use whatever method suits you, but a diagram or simple sketches are sometimes much more complete than long speeches.

  • Functionalities
    The list can be very long, and can seem redundant to you with the previous step, but it is better not to forget anything. Here are some ideas:
    • User account with registration / login
      • E-mail
      • Facebook
      • Google
      • Phone Number
    • Access without connection to content, or content restriction,
    • Import or export
      • photos,
      • videos
    • Messaging
      • Text
      • Pictures,
      • Videos
      • His
    • Interact with the content
      • comment
      • liker
      • share
      • bookmark,
    • Friend invitation
    • Location, mapping,
    • QRcode scan,
    • Connection to a bluetooth device,
    • Payment system,
      • CB
      • Paypal
      • Apple Pay
      • Google wallet
    • Promo code,
    • Search engine, filter,
    • Agenda, reminder,
    • Push notifications, email
    • Offline: should some features be accessible offline?

To remember nothing, the list of features can be made next to each screen when describing the user journey.

Back office

In a first version of the application, it is sometimes preferable to administer nothing or very little. It can be expensive to create a back office, it is sometimes advisable to test your application and make the changes directly in the application before investing in an administrative back office.

List in your specifications the functionalities that you want to find in your back office, possibly specifying that it is possible to carry it out only in a 2nd version of the application. It is also possible to prioritize your needs.

The elements to describe are for example:

  • the number and type of access: administrator, editor, reader, etc.
  • the content elements to be able to administer
  • management of user accounts: modify identifiers, extend a subscription, etc.
  • the necessary exports

It is often tempting to want to manage everything, but it is important to question your real need: it will always be possible to change it later.

Technical constraints or non-functional specificities

They can be as diverse as they are varied, here are some elements that are found most often. And if there isn’t any, there’s no need to look for any 😉

  • Third party services

What will the application need to be connected to? A CRM, an ERP, a database, a mailing or SMS tool, an information system …

  • Compatibility

What OS or browser versions must the application be compatible with? If you do not have a particular constraint, it is better to seek the advice of your provider rather than impose a potentially unworkable constraint.

  • security

All service providers are now committed to a “RGPD friendly” design. However, you remain responsible for the processing of your customers’ data, so you might as well ask clearly what you need.

  • Accommodation

You can manage your accommodation directly or ask the agency that makes your application to do it, it’s up to you!

Please note, some types of data require specific hosting, such as health data.

Graphic elements

  • graphical charter

It is of course to be transmitted. If you don’t have one, you can already list all the elements at your disposal: logo, colors, typo…. If you don’t have anything, that’s okay, but remember to report it.

  • Models

The first models (or sketches) could be produced as part of a POC or simply to easily illustrate the expected elements.

  • Sources of inspiration

It is sometimes difficult to describe your design expectations, but there are always things that we like (or not) in other interfaces. It’s time to list them (links, screenshots, etc.) and indicate what you like in each of these examples.

Piloting

  • Expected benefits

Is it about design, graphics, development, etc? All of this at the same time?

  • Planning

We often think of the end date, but don’t forget to give a project start date. It can sometimes take a long time between a consultation and the actual launch of a project.

There is of course the deadline; especially if your application is associated with an event. If this is not the case, we do not recommend imposing a deadline for the deadline. This can be counterproductive in terms of expected results; to make a quality product, you have to take the time you need.

  • Budget

We often think that giving a budget will distort the provider’s proposal. This will especially allow him to make you a coherent proposal. Imagine consulting a real estate agent without giving a budget for your project; the chances of being satisfied with his proposal are much lower.

  • Contacts

Who to contact for what question?

  • Expected response elements

Methodology, technical proposal, planning …

Drafting of the specifications

You now have a first list of items to indicate. Of course, it is not necessary to have exhaustive specifications from the start of the project. This document must be built iteratively, to refine your needs little by little, until obtaining the description of a first version of the application project. So, do not wait to have a perfect specification to consult us.

A first simple version of expression of the needs, will allow you to obtain a first approach of the cost and the planning of your application project.

Do not try to design your final interface to the specifications either. We are here to bring you our know-how and our advice. Describe what you have in mind using this list, and count on us to organize all of these ideas.

Now, it’s up to you to describe your needs to us!

Leave a Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.