Home

Software process improvement

Agile software development

JAD and RAD

System requirements

System functional specification

System functional specification definition.

System functional specification definition

A specification is a document that details a given requirement or set of requirements. In our article about requirements the following classifications were made and described:-

  • Requirements scope
  • Functional versus non-functional requirements

    In this article, we go deeper into the functional requirement specification of a system. As we go deeper into the subject we also examine a useful tool for specifying the functional requirements of a system.

    Functional specification using the Data Flow Diagram (DFD)

    Regardless of system scope (i.e. could include both manual and computer processes) specification of the required functionality is essential in order to be able to design the workflow or computational process components. The functionality of a system is the essential purpose of the system and can be defined by a series of individual functions. For example a sales order processing system can be functionally defined by describing the following:-

  • Calculate the availability of the requested goods
  • Calculate the total price of the order
  • Allocate goods to this order
  • Ship the goods to the customer

    These functions, which could include manually performed processes, specify what is required of the whole system.

    For a data processing system a series of processes can be linked together in order to depict the overall data flow or data processing. This arrangement of data processing elements is referred to as a DFD. The DFD notation is explained in many places on the web, this article focuses on the DFD as a useful method of documenting the system functional requirements.

    DFD in functional specification

    Once you are familiar with the DFD, see other web resources, it should become clear that there is a strong relationship with process workflow and the DFD. There are, however, some limitations of the DFD for describing workflow and these are:-

  • The DFD does not show roles and responsibilities.
  • The DFD does not indicate the order in which the processes are executed.
  • The DFD does not show any paths or dependencies between the processes.
  • The DFD does not show how the processing is done only what is expected.

    In summary the DFD is a specification of the data transformations of the system. The tool is not prescribing workflow as this is a systems design structure. The DFD data transformations are very powerful descriptions of functionality as they include:-

  • Calculations, i.e. tax etc.
  • Derivations, i.e. if the ship to address is in Zone A, then Ship Fed Ex.
  • GL Account processing, if the goods sold are to non-profit then booked to GL abc.

    The above derivations do not describe how the requirement is achieved but rather they specify the functional requirement in terms of what is required. These derivations that are shown on a DFD become part of the system specification. Notice all requirements cannot be specified on the DFD, for example if the goods are required to be shipped in 3 days of an order being placed then this is a non-functional requirement and cannot be depicted as a data flow (or data derivation). That said the DFD diagram is a powerful tool for depicting the functional requirements.

    DFD versus Workflow

    Process diagrams (i.e. workflows) are typically representations of How processing takes place and they are not requirements specifications. It is possible to construct an abstract process diagram, i.e. in UML there is an Activity diagram or a State diagram that could be used to describe the functionality. In practice these levels of abstraction for specification of What is required become confusing for the end user and sponsor and it is difficult to separate them from the physical workflow. That is why we would advocate using the DFD for the logical view and then move to a workflow to document the physical processes.

    The essential point here is that your documentation should move from the abstract, or logical, to the physical. In this way What is required is separated from How it is achieved. The difficulty with this approach to specification lies with the more abstract (or logical models). Most people are comfortable describing what they do in terms of how it is done. Describing what a system does independent from how it is done is one of the biggest barriers to communication for the systems analysts. For this reason new software development methods, such as those within the Agile framework, have become popular.

    A DFD documented independently of the actual workflow will give you the functional specification of the system. In our experience, this notation (DFD) is an abstract notation that can be understood by users, sponsors and all people who are associated with the systems process design. Alternative structures for documenting essential systems requirements, i.e. UML, object oriented analysis, are more abstract and require a steeper learning curve than the DFD.

    How the DFD facilitates the design

    Once the functional requirements, e.g. DFD, are specified and the data dependencies for the discreet functions are known the designer has both the minimum constraints and the maximum implementation options available. As soon as the designer, and this could be process designer (one that includes manual processing) begins to assign roles and creates a physical workflow then they are narrowing the implementation options. In the final design only one workflow and systems design is chosen. There could be a degree of flexibility within the selected design, i.e. path alternatives, but in essence the designer chooses one out of a huge number of alternative solutions.

    As well as having a design separate from the functional requirements it is important to be able to trace where the requirements are implemented in the design. This tracing, via a traceability matrix, should be two way. By having a traceability matrix a number of key questions are answered:-

  • Where in the design is this requirement implemented?
  • If this requirement chances or becomes obsolete where does the design change?
  • Why is this feature in the design, what purpose is served?
  • Can an alternative design satisfy these requirements more effectively?

    The DFD is an ideal tool for both separating out the logical functional requirements and allowing design traceability.

    No guarantee (or claim) is made regarding the accuracy of this information. Any questions or comments should be sent to:-