View source for Process - Functional Specification

This page clarifies the Functional Specification Process

== Pre-Requirements ==

* One or many of:
** BRD
** SDD
** EST (spreadsheet and document)
** SOW
** Combined EST


== Process ==

* Requirement and functional overview created by PS lead for the project/change. Also technical notes as to how this was estimated.
* Handover to R&D.
* Testplan created at this stage, wrt scenarios (see below)
* R&D to create technical notes to implement the change as requested.

{{Note}} Regardless of who is doing the FS, the technical aspects should already have been discussed with R&D and noted.


== Creating an FS ==

The Functional Specification may be created as a Word doc or within Assist Calidus Hub and exported as a PDF.


== Using the FS Word Template ==

* Double click on the FS Template - this will create a new document
* Replace placeholder text with your text.
* Copy the requirements from the EST/BRD into the Client Requirement section
* Copy the Solution into the Solution section.
* Take any scoping comments from the Solution and move to Scoping.
** Strongly scope - if there are things that are not included or limited in the solution, make that clear in this section.
* Ensure that Pre-requisites are populated if required.
* Data section should include any backing data that should be set up and indicate whether this will be done by the client or by Aptean. Indicate whether this will be automated through a script at release, or post-implementation task. 
* Implementation Advice should show whether anything else should be setup e.g. EDI, ORS reports, recreating reports, plus details.
* Functional Description should expand on the solution, focussing on detailing the functional components that will change (or not change) as part of this change. 
** For example, the solution overview may say that a screen is changing to add a new field X. The Functional description should include a prototype screen layout or detailed description of where this field should be, what screen, etc.
** {{Note}} This section is critical - this section is what is signed off by the customer. Use customer wording or phrases if appropriate, to ensure that the customer understands the functionality in detail. Explain why this solution will fulfil their requirements.
* Technical notes may be structured and formatted in any way you please. However, this section is to be written/reviewed by R&D BEFORE release to the customer.
* The Test Plan should be created (from a template) and embedded in the document in this section, or pasted into this section, as long as this section is landscape.
** The test plan should be focussed more on scenario testing than unit testing. It is expected that the R&D operative will conduct appropriate unit and limit testing WITHOUT having to have explicit instructions, UNLESS that unit/limit testing is core to this change.
* Paste in the estimate values. Ensure that you account for your time, plus any time to issue/review the FS.
** If multiple departments/people are involved in the specification of this change, then you should note your time on the estimate in hours in total (plus delta if you have returned to this following review) as a review note. 
** One of the authors should be assigned the final review, to total up all this time and amend the FS time, and remove any notes relating to this.
* Save as FS-{CaseNo}-{Client} {Desc} v{Version}.docx


{{Note|
* Document properties should be used for the following:
** Title - without references
** Version - 2dp e.g. 0.01
** Yearcopyright - e.g. 2025
** Client Company Name - {Client Name}
** Area or Project/System - {System & Release Version}
** Reference - {Case No - Cust Ref}
* These are used in the Heading, Footing and title pages.
* You can refresh all referenecs in each section using <code>[CTRL-A]-[F9]</code>
}}


== Using Assist Calidus Hub to create an FS ==

{{Note}} You must be logged in to be able to create new pages in Assist.

* Click the link here: [[Help:CreateNewPage#Functional_Specification|Create New FS from Template]]
* Enter the FS name following convention FS-{CaseNo}-{Client} {Desc}. {{Note}} No version in the page name.
* This will start an editor - this may be in Source mode or Visual Editing mode.
* Enter the #vardefine values, following the guidelines in the template.
* Enter text in all sections following the guidelines for the Word Template above.
* Enter the estimate values in the Appendix template provided.
* Save and provide reasonable change notes e.g. v0.01 - initial creation.
* Export the PDF using the link provided - this will append the version number.

{{Note|
* Follow the guidelines and help here: [[Assist Editing Guide]].
}}


== General Notes ==

{{Note}} All technical restrictions should be referred to the project PS lead in a timely fashion. This should not be an email or automated devops - this is directly affecting progress on development - organise a meeting asap to resolve the technical restriction. Bring examples and possibilities to the meeting.

<noinclude>
[[Category:Processes]]
</noinclude>