Guide to writing a software brief - WiredContact
post-template-default,single,single-post,postid-602,single-format-standard,bridge-core-2.7.1,qode-page-transition-enabled,ajax_fade,page_not_loaded,,qode-title-hidden,qode-theme-ver-25.6,qode-theme-bridge,disabled_footer_bottom,qode_header_in_grid,wpb-js-composer js-comp-ver-6.6.0,vc_responsive

Guide to writing a software brief

Should a process be Automated or should a system be developed ?

A well written software brief will provide a clear indication of what you need to achieve from your system.

The process of putting your thoughts in writing will often alter the destination as you clearly define your journey in association with each department or team who will benefit from the CRM Solution.

Discussing your issues with us will also help you, whilst a new solution may be desirable it may not be essential to all departments and you may already have the information available but were unaware of how to access it. This is the value of experienced consultancy.

  • Help to establish the essential elements of your objectives for each part of your business.
  • Reduce the development effort by setting clear objectives.
  • Provide a basis for accurately estimating cost and time scales.
  • Provide a basis for verification and validation of each procedure.
  • Serve as a reference for any future developments you encounter.

Characteristics of a well written instruction
The key qualities of a good bespoke software brief are for it to be:

  • Unambiguous – every stated requirement should only have one possible interpretation.
  • Correct – every stated requirement is one that the software should meet.
  • Complete – all significant requirements are included.
  • Consistent – the brief should not conflict with other documentation relating to the project.
  • Verifiable – it should be possible to check that the software meets each stated requirement.
  • Modifiable – the brief should be organised such that it would be easy to make changes to at a later date.

Software Brief Contents

Organisation Overview
Giving us an overview of your organisation is a great way to help us understand your objectives. It can also help us to suggest additional functionality that may benefit your organisation. You should include details about the products/services your company offers, the size of your company, the mentality of your company and your objectives for the future.

We need to know what you are trying to achieve with your CRM deployment. Generally speaking we are going to help you solve a particular problem / inefficiency, therefore you should describe this problem in some detail.

Details of exactly how the software will solve the problem should be saved for the requirements section, your objectives should be focused on what you are trying to achieve ( not the detail of how). Try to ensure that your objectives are clear, concise and achievable.

Software Requirements
Here you should provide a detailed explanation of the benefits you require. The more detail you can provide the more accurate and useful our response will be. As with your objectives, you should try to ensure this section is as unambiguous and complete as possible. If your business uses a lot of industry-specific terminology, be sure you provide clear definitions as it is possible we may have no knowledge of your industry.

You should try to ensure you include details of the following in your requirements:

  • Functionality Details of what the software will do.
  • External Interfaces How will the software interact with existing systems? If you want WiredContact to share data with third-party software please explain to what extent.
  • Performance What are the performance benchmarks for the system? reduce time between stages, improve throughput or some other metric?
  • Attributes What are the important attributes of the system? If your organisation uses multiple devices, you may require the access on specific devices or from remote locations. If your CRM system is dealing with sensitive data then security may be a key attribute.
  • Constraints The development of your software may be influenced by a variety of factors, including: legislation, company policies, resource limitations, programming languages and operating environments and of course budget.

Time scales
We need to know when you expect the software to be developed by. Try to be realistic with your time scales; the deployment and development process may take a few days to fully complete and it may be preferable if the work is done in stages. Providing unrealistic time scales may not help the project. Try to allow for the time that it will take for you to collate all the required information. As each department or user obtains access to the system make sure they are trained on how to use it and that you make clear the preferred method of instructing any alterations.

Sometimes your project may need to alter course, this may become apparent as your system is developed and other opportunities are identified.
This may happen once your team start to see the benefit of the development and a “Better idea” evolves. If the new idea requires additional development then it could delay the project or incur additional cost or both. You should try to allow some extra time for these unexpected complications. Of course the “Great idea” could always be saved and shared internally until all “great ideas” have been discussed.

Your budget will determine the difference between nice to have and essential to have. If your budget is below the estimated cost we may well be able to devise a solution that is more cost-effective and remember you can always continue with the development as funds become available.

Additional Information
If you have any additional details that are important but have not been covered elsewhere, you should make sure they are also clearly specified in your brief.

Ultimately having a bespoke CRM solution means you have control; during the development cycle try to remain focussed on the original brief you gave and understand that little change you “assumed” was already going to be built into the system may take someone a few hours to develop.