directory

Ooodles of old stuff including How-To's, Writers Resources, Directories of all Types, Technology Reviews, Health Information, Marketing Statisitcs, Affluent Markets, Hospital and Medical Market Data and more

Sunday, September 03, 2006

What is a Functional Spec?

Purpose of the functional spec



The Functional Specification describes the features of the software product. It describes the product's behavior as seen by an external observer, and contains the technical information and data needed for the design. The Functional Specification defines what the functionality will be, but not how that functionality will be implemented.



The software engineer uses the Functional Specification document to create a detailed design document that explains in detail how the software will be designed and developed. The detailed design work may further decompose and translate the functional requirements into pseudo-code, and from there into a computer module or program.



The functional specification translates the Software Requirements Document into a technical description that:

• Ensures that the product feature requirements are correctly understood before moving into the next step, the software design process.

• Clearly and unambiguously provides all the information necessary to design the software.



Expected Minimum Deliverables included in Functional Spec….

Identification of User Requirements Definition

The purpose of defining user requirements as described in this step is to prepare for writing an accurate and complete Statement of Work. When user requirements are well understood from the start of a project, customer satisfaction with the resulting software will be higher.

Describe Users

Identify the characteristics of the intended users of the software:

• Names of industries, specific businesses and job functions

• Minimum computer skills and equipment that users will have

• Specialized technical knowledge or expertise that users will possess

• Specialized equipment that is owned or operated by the intended users

Different job functions or levels of experience that differentiate the various sets of expected users. These groupings or types of expected users are known as the "user classes" for the software.



Describe:

• Approximate numbers of the various types of users expected for the software

• How often users are expected to use the software

• The tasks that the users will accomplish with the software.

Viewed broadly, a user is anyone who is affected by or who may affect the software product. User roles are the kinds of persons who will be affected by the system: those who use the software directly, those who use the results produced, and those who never see the system, but have information influencing its design (such as regulators and lawyers). Considering this broad list of user classes suggests features and functions that need to be included.



Information Technology departments at customer companies are another important group to consider. For example, including steps to participate in customer internal software development processes may be important to ensure acceptance of the completed software within their systems.

Gather Initial Requirements

Get the users involved very early in the concept discussions to understand what they need the software to do. These are the initial functional requirements.

Discuss the software requirements with funders and end-users. Be sure to cover:

• Key features and functions that the software must perform, including graphical interface, management reports, and human factors (usability)

• Benefits to the customer including savings that could be obtained

• Approximate cost for the development

• Any commercial software products that provide overlapping or competing capabilities.

Review Requirements with Users

Review the initial requirements with end-users and funders to obtain their approval of:

• What tasks the users want to use the software to do

• Key features and functions

• Reports and results the software should produce

• Other software that needs to interface to this software

• User interface description

• Other key requirements of users and funders.





Functional Specification Scope

The Functional Specification includes specific information about each functional requirement of the software. The Functional Specification should describe, for each functional requirement:

• Purpose - What the function is intended to accomplish.

• Input - What inputs will be accepted, in what format the inputs arrive, sources for the inputs, and other input characteristics.

• Process -The steps to be performed, algorithms, formulas, or techniques to be used. Software implementation details are not included, however.

• Output - Desired outcomes such as the output form (e.g. report layout), the destination of the output, output volume and timing, error handling procedures, and units of measure.

• Usability items need to be included in the Functional Specification. These are features that ensure user friendliness of the software. Examples include clear error messages, input range checking as soon as entries are made, and order of choices and screens corresponding to user preferences.

The Functional Specification also includes performance requirements, a discussion of design constraints (e.g. hardware, software), and required attributes such as security, maintainability, reliability, mobility, and availability.



Functional Specification Review

To ensure that all parties understand the software objectives, the Functional Specification must be reviewed for accuracy and completeness. The Functional Specification review should include:

• Project manager

• Software developer

• Technical and scientific domain experts such as consultants or other project managers

• User group members and other typical end-users

It is critical to hold a combined meeting, either at one site or through video or telephone conference calls, so that consensus agreement and formal approval can be reached and recorded.



Before discussing the Functional Specification as a group, the participants review the document individually. As preparation for the review meeting, the developer prepares an initial estimate of the time, effort, and funding required. Then the project manager responds.



An iterative exchange continues until the project manager (representing the users and other stakeholders) and the developer reach agreement upon what features and capabilities will be proposed to the project stakeholders at the meeting, considering the timetable and funding level.



Upon final agreement, the responsible persons sign the final version of the Functional Specification. Copies are then distributed to the reviewers, Corporate Software Quality, and other interested parties.









Functional Specification Contents

Typical sections for the Functional Specification document are:

A. Introduction

Describes the purpose, scope and organization of the Functional Specification document.

B. Software Overview

• Product description: Describes briefly why the software (or upgrade) is being developed, and lists the most important features and capabilities.

• Product functional capabilities: Presents a list of the functions that the software will be required to perform. Where a product feature comprises several functional capabilities, a table may be developed to illustrate these relationships. The list of functional capabilities may be an updated version of the capabilities listed in the Software Requirements Document.

• User characteristics: Describes the intended users of the software in terms of job function, specialized knowledge, or skill levels. Considers various user classes or profiles such as managers, engineers, equipment operators, IT support staff, and network or database administrators.

• User operations and practices: Describes how persons will normally use the software, and the tasks they will most frequently perform. Also covers how users might use the software on an occasional basis, such as creating data backups or importing data from another program. Consider using USE CASE examples to specify the end-users' expected use of the software.

Use Cases describe the sequence of events that occurs as a user works with a software application. A use case records the actions of the user, and the resulting responses of the software. Multiple use cases are typically written to describe software that has many capabilities.



Use Cases, also called "user scenarios" or "user stories", can provide a useful way of documenting:

• What users will do with a planned software application

• How the application will respond.

For example, to help the user achieve a specific goal, the software presents a series of tasks and screens to be completed. The Use Case for a particular user goal describes:

• The user's goal

• The tasks or steps that the user completes to achieve the goal

• The system responses to each user task or step.

A series of Use Cases is created, one for each principal goal that users have in utilizing the software.



This approach helps to ensure that:

• The software includes the key functionality expected

• The system responses will be most helpful to users.



• General constraints: Algorithm limitations, user interface limitations, and data limitations. Includes items such as minimum space or room needed to house equipment, type of electrical and HVAC required (e.g. conditioned power), maintenance requirements. Also, states if training is required for optimum use, or if calculated results are only applicable in certain situations.

• Assumptions: Lists any assumptions that were made in specifying the functional requirements.

• Other software: How does the program interact with other software, such as spreadsheets, word processing or presentation software? Can one cut and paste from the application to other Windows software programs?

C. Specific Function Descriptions

This section is repeated for each function of the software. Some examples of functions are: engineering calculations, sorting or sequencing, other operations relating inputs to outputs, validity checks on inputs, error handling and recovery.

• Description: Describes the function and its role in the software.

• Inputs: Describes the inputs to the function. Where user interface (UI) elements are present, these are described. Examples of UI elements are check boxes, dropdown lists, and alphanumeric fields. Input validation strategy, allowed data types and value ranges are specified for each input.

• Processing: Describes what is done by the function. Where algorithms, equations, or other logic are used, they are described here. If calculations are done utilizing the methods of specific standards or references, these are cited. Database definitions are also included where relevant.

• Outputs: Describes the outputs of the function. Where a user interface description is relevant, it is included. Reports generated are also defined.

D. External Interfaces

The interfaces in this section are specified by documenting: the name and description of each item, source or input, destination or output, ranges, accuracy and tolerances, units of measure, timing, display formats and organization, and data formats.

• User Interfaces: Describes all major forms, screens, or web pages, including any complex dialog boxes. This is usually best done via simulated, non-functioning screen shots (such as PowerPoint slides), and may take the form of a separate document.



The navigation flow of the windows, menus, and options is described, along with the expected content of each window. Examples of items included are screen resolutions, color scheme, primary font type and size. Discussion also includes how input validation will be done, and how data will be protected from accidental changes. Specific items are described for each screen such as input fields, control buttons, sizing options, and menus.

• Hardware Interfaces: Describes the equipment needed to run the software, and also other output or input devices such as printers or handheld devices.

• Software Interfaces: Describes any software that will be required in order for the product to operate fully. Includes any EPRI software or commercial applications that customers will be utilizing together with the planned software. Also describes any software that the software product will interact with such as operating system platforms supported, file import and export, networking, automation, or scripting. Specifies whether the users must provide the interfacing software themselves, and any special licensing requirements.

• Communication Interfaces: Describes how the software product will communicate with itself (for multi-platform applications) or other software applications, including items such as networking, email, intranet, and Internet communications.



E. Performance

Discusses items such as response times, throughput requirements, data volume requirements, maximum data file size or problem complexity, maximum number of concurrent uses, and peak load requirements (for web-based applications). Includes expected response times for entering information, querying data files and databases, performing calculations of various complexities, and importing/exporting data.

F. Design Constraints

Examples of constraints that affect software design choices are items such as memory constraints involving minimum and maximum RAM and hard disk space, and limitations arising from hardware, software or communications standards.

G. Attributes

• Security: Describes any password-protected access levels such as operator, engineer/modeler, manager, database administrator-and which functionality will be accessible to each access level. If relevant, describes the planned approach to locking the software.

• Reliability, Availability, Maintainability: Describes requirements items such as days or weeks of continuous operation, strategy for data recovery, code structuring for ease of future modification.

• Configuration and Compatibility: Describes requirements such as those connected with individual customization or operation in specific computing environments.

• Installation: Describes the planned method for installation: done by the user independently, done by customer company internal IT services, done by an external contractor. Specifies the handling of such items as data transfer from prior releases, and the presence of software elements from prior releases.

o Usability: Describes items that will ensure the user-friendliness of the software. Examples include error messages that direct the user to a solution, input range checking as soon as entries are made, and order of choices and screens corresponding to user preferences.

H. Additional Requirements

Describes other characteristics the software must have, that were not covered in the prior sections.

• Database: Describes any specific requirements relating to the database, such as database type (e.g. relational), capability to handle large text fields, real-time capability (e.g. handling an incoming data stream, as from instruments), multi-user capability, special requirements relating to queries and forms.

• Administration: Includes any periodic updating or data management needed.

• User documentation: Describes the user documentation to be delivered with the software, including both hard copy and online requirements.

• Other requirements: Describes any other requirements not already covered above that need to be considered during the design of the software



 

0 Comments:

Post a Comment

Links to this post:

Create a Link

<< Home