This post explores the structure of a good template for a business functional specification or template for a detailed functional specification. It looks at the contents and template of a good functional specification, how to work with users and the process of creation of a good functional specification.
I have provided a template of a business functional specification in a simple to follow 10-step way that can be used by a business analyst to walk through with users and collect the business functional specifications for the development of a new or modified application. In addition there are helpful hints and tips on developing the business functional specification that you can use as you develop the document. This was a specific request via feedback from one of my blog followers. A big thank you to Heather in Colorado, USA, really appreciate the feedback and I hope that you find this useful. This post is part of a number of articles on projects, you can read more here.
Are you enjoying this blog? If so, please forward this to a friend or colleague and suggest that they sign up here. It is free and you will receive a coupon code to allow a free download from our store + regular updates on tools, templates and interviews to help get it done !
You may also find some of the tools and templates that I have used to deliver projects for startups here, including the most popular item in the store, a project quote tool that helps you build a fully costed project commercial model. You can find it here. All products are offered with a money back guarantee. Introduction: Business Functional Specification- a template The structure of a good business functional specification can be summarised as
Contents of a business functional specification Introduction
Organisation Model
Requirements (this could be done in a table format)
Note: these should be expressed as much as possible in business terms. That is the functions that the business users would like to have in the system. For example the ability to capture address information on a single screen with validated information for fields like STATE and COUNTRY. The section below for non-functional requirements is to be used for the more technical requirements of the system, which are more likely to include how the application fits into an architectural environment. That is what type of machine does it run on, where is it located, what security etc. does it have. Non functional requirements
Note: the suggestion is to express these using a table that has the headings of category and then the non-functional requirement. For example the category might be application availability and the non-functional requirement would be to have the system with 99.99% availability. Interaction requirements
Basically this is what system does this application need to connect to and what sort of interaction does that need to be. For example the application may need to connect to a database to get a list of valid post codes, but that is a READ interaction and does not need to UPDATE anything in the external system. Data Requirements This section in the business functional specification can be used to identify what sort of data will need to be stored and processed. For examples does the application need to have the ability to store data in other languages, is the application required to store reference files for example with a trouble ticketing system. The business functional specification does not need to specify each data type for every data item in the application that can be identified during the user interface design and architecture. Solution overview
Use Cases This is the big one. Get this right and the rest of the application deployment will flow from this. I have used the following format in table form
Example #1
The above is a good example of how business functional specifications can be used to show how different areas in a business need to use an application for different business functions. For example it may initially be a CRM system but other support functions still have to use it as well. Functional Mapping to Roles & Responsibilities This is used to map the functions of the system to the roles and responsibilities of the business user. For example the system admin functions will be mapped to the application support team. The configuration of new data will be mapped to the marketing and promotions team. Assumptions, Constraints and dependencies This can be used to specify the boundaries or the scope. For example the business functional specification may have an assumption that the system needs to support 7000 users with year on year growth of 10%. Alternatively there may be an assumption that the application has to be hosted in a data center in a particular geographical location. Acceptance Criteria The business functional specification should specify how the application will be accepted. This could be through a formal testing process or via a dry run process or parallel run process. Thanks for reading Andrew Everett
0 Comments
Your comment will be posted after it is approved.
Leave a Reply. |
Categories
All
A$4.00
For the project office to use. A list of things to check off in managing a project grouped into sections from scope, time, budget, quality and management. Instantly check the health of any project by scoring against these 117 questions.
A$4.00
The following is a project checklist, which can be used by project managers, program managers, delivery managers, pre sales consultants and anyone who is focused on ensuring that all areas of a project are being managed to ensure successful delivery. It is organised around the lifecycle of a project from initiation through delivery and close out.
Archives
November 2019
|