- 2.5.11.3 Developing Data Definitions
- 2.5.11.4 Developing Process Specifications
- 2.5.11.5 Functional Specification Package
- Exhibit 2.5.11-1 Format for a Leveled Data Flow Diagram
- Exhibit 2.5.11-2 Symbols Used to Define Data
- Exhibit 2.5.11-3 A Procedure described using a Narration, then using a Decision Table
- Exhibit 2.5.11-4 Common Process Specification Example
-
This section discusses the components of data definitions.
-
The following attributes actually describe and define the system components. They provide information critical to understanding the system under description:
-
Constraints;
-
Contains;
-
Description
-
Values/Meanings
-
-
Use the following cross-references to describe the relationships between system components and provide information that enhances system understanding and maintainability:
-
Access Key To;
-
Accessed By;
-
Aliases/Modifiers;
-
Input To;
-
Output Of;
-
Part Of;
-
Provides;
-
Receives
-
Updated By:
-
Additional cross-references for common Process Specifications.
-
-
Because attributes are critical, they have a higher priority than cross-references. Therefore, first document all attributes of the components; then, as time permits, add the cross-references. Use only the attributes and cross-references that are pertinent to that specific piece of data being defined.
-
Store and maintain, whenever possible, the values/meanings, descriptions, constraints (if applicable), and cross-reference information in an automated manner, such as through an automated data dictionary. On the other hand, keep the breakdown of data streams and data stores (contains attributes) into elementary components on the same medium with the accompanying data flow diagrams and process specifications.
-
If the list of values and meanings is so extensive as to be unwieldy, then reference an existing internal management document. Use the following phrase as a comment in the "values" category - "for values refer to the most current version of fill-in official title and number of reference document", and state under what specific name in the internal management document the values and meanings can be found.
-
A single data element may constitute a data stream; this is indicated on a data flow diagram when the element name is assigned to an arrow.
-
The following attributes define the data streams/elements:
-
Description: a narrative description of the element.
-
Values/ Meanings: a list of valid values for an element and the meanings of those values.
-
-
Use the following cross-references to describe the relationships with other system components:
-
Access Key To: an alphabetical listing of data stores for which this data element is an access key.
-
Aliases/ Modifiers: an alphabetical listing of other names for the same element (aliases), or qualifiers for the element name (modifiers).
-
Input To: if the element is a data stream, an alphabetical listing of processes that, as input, accept the data stream.
-
Output Of: if the element is a data stream, an alphabetical listing of processes which are sources of the data stream.
-
Part Of: an alphabetical listing of data groups which contain this element.
-
-
A group may be a data stream, or it may be a component part of a larger group, data stream, or data store. The following attributes define the data streams/groups:
-
Description: a narrative description of the group.
-
Contains: a list of the elements and/or subordinate groups which constitute the data stream/group being defined; symbols are used to show the relationships between the contents.
-
-
Use the following cross-references to describe the relationships with other system components:
-
Access Key To: an alphabetical listing of data stores for which this data group is an access key.
-
Aliases/Modifiers: an alphabetical listing of other names for the same group (aliases), or qualifiers for the group name (modifiers).
-
Input To: if the group is a data stream, an alphabetical listing of processes that, as input, accept the data stream.
-
Output Of: if the group is a data stream, an alphabetical listing of processes which are sources of the data stream.
-
Part Of: an alphabetical listing of larger data groups which contain this group.
-
-
The following attributes define the data store:
-
Description: a narrative description of the data store.
-
Constraints: a narrative description of items, rules, regulations, etc. affecting the data store; e.g., required password security or response time criteria for database access.
-
Contains: a list of the elements and/or groups which constitute the data store; symbols are used to show the relationships between the contents.
-
-
-
Accessed By: an alphabetical listing of processes or external entities which use this data store as a source; the data store is shown as an input to these processes or external entities on the data flow diagram.
-
Updated By: an alphabetical listing of processes or external entities which change or reorder the contents of the data store.
-
Aliases/Modifiers: an alphabetical listing of other names for the same data store (aliases), or qualifiers for the data store name (modifiers).
-
Part Of: an alphabetical listing of larger data stores (such as a database) which contain this element.
-
-
External entities are defined by the following:
-
Description: a narrative description of the external entity.
-
Provides: an alphabetical listing of data stream(s), which the external entity provides as input to the system.
-
Receives: an alphabetical listing of data stream(s), which the external entity receives as output from the system.
-
-
When a system is using both a glossary and data dictionary, some data will be defined in both. This is most likely to occur in the case of data streams on the context diagram that enter and exit the system, and with data elements. If it happens that the data is defined in both and any attributes are the same, state in the system glossary, see Data Dictionary.
-
Define the contents of data in the "Contains" attribute. Data, except for data elements, is composed of and defined by lower level data components. Show the relationships between these data components in the "Contains" attribute using a symbol convention.
-
Unless the use of an automated data dictionary precludes usage, then refer to Figure 2.5.11-22 for the symbols to be used to list the contents of data.
Figure 2.5.11-22
This image is too large to be displayed in the current screen. Please click the link to view the image.Symbols used to list contents of data
-
Exhibit 2.5.11- 2 provides the symbols used to define data.
-
An alias is a data name that is synonymous with a more commonly accepted data name of a data stream, data store, data group, or data element. An alias is created when the same data is labeled with more than one data name (i.e., the commonly accepted name and the alias name(s)).
-
Aliases generally occur for three reasons:
-
Different users have different names for the same form, etc.
-
An analyst inadvertently introduces an alias in the data flow diagram.
-
Two analysts working independently with the same data stream give it different names.
-
-
Enter the alias name(s) under the aliases cross-reference of the commonly accepted data name. In addition, the commonly accepted name should be entered under the aliases cross-reference of the alias name(s). Eliminate all aliases, except those mandated by users, by the end of analysis.
-
All data processing systems, whether structured or not, require descriptions of the procedures that determine how inputs are to be transformed into outputs. As these procedures increase in complexity, English narrative descriptions become a more ambiguous and less acceptable means to specify these transformations. Structured analysis introduces the process specification, a written description and explanation of the processing which takes place within a data flow diagram process bubble.
-
Only use structured English, decision tables, or decision trees. To write the procedures section of a process specification.
-
The three attributes associated with all process specifications are (in appropriate order):
-
Description - a narrative describing the purpose and objective of the process.
-
Constraints - a narrative description of the process constraints. This section usually is not needed, but may be used to specify nonprocedural requirements. An example is a timing requirement such as a report that must be generated only on the last day of the month. Pertinent characteristics of the process such as input and output volumes, peaks and seasonality of the input and output data flows are other possible constraints.
-
Procedures - use structured English, decision tables, or decision trees to describe in detail the criteria governing the transformation of input data streams into output data streams. Convey what has to be done, not how it is to be accomplished.
-
-
There are two types of process specifications:
-
Primitive Level Process Specifications;
-
Higher Level Process Specifications.
-
-
This type of process specification defines primitive level (lowest level; not further decomposed) data flow diagram process bubbles. This specification must contain the description and procedures attributes; and, as applicable, may contain the constraints attribute.
-
This type of process specification defines higher level ("parent'') data flow diagram process bubbles and conveys information common too more than one of its "child" bubbles. This type of specification must contain the description attribute; and, as applicable, may contain the constraints attribute.
-
Do not address physical requirements such as tape input, card records, telecommunications devices, etc in the written description. Describe physical information in the constraints section, but only when essential.
-
Ensure that the process specifications stress what needs to be accomplished, not how it is to be accomplished.
-
Develop a process specification for each bubble.
-
Entitle each process specification with the process name and number of its associated bubble on the data flow diagram.
-
The main intent of the process specification is to define the transformation of input data into output data.
-
Avoid redundancy between the process specification and other tools in the functional specification package.
-
Use the data names as shown in the data flow diagram's and date definitions in the process specification.
-
Use Structured English, decision table or decision tree format to write the procedures attribute.
-
Describe the procedure sections of process specification for the lowest level (primitive) bubbles using an abbreviated form of English known as structured English. The intent is to provide communications that are more explicit and less contextual than narrative English. Structured English tries to limit reader interpretation, despite the reader's frame of reference, to one obvious conclusion.
-
Structured English uses a limited vocabulary consisting of:
-
strong action verbs;
-
direct and indirect objects that are defined in a glossary/data dictionary;
-
as few adjectives and adverbs as possible.
-
-
Do not write process specifications from a physical code-like perspective (i.e., in the worst case they contain detailed instructions as to control, working storage, physical media considerations, switch settings, etc.) as this will cause a significant decrease in "user friendliness". Structured English that is simply pseudocode for program source code defeats the purpose of analysis, limits design options and flexibility, and creates a maintenance headache for analysts.
-
Structured English also uses a limited statement syntax consisting of simple imperative sentences, closed-end decisions, closed-end repetitions, or any combinations of the above. All Process Specification functions must be described using only the three constructs discussed below. These constructs have only one entry point and one exit point; they create a linear presentation (one construct is done completely before another construct is begun), thus avoiding the confusion inherent in narratives that skip around. Procedures written in Structured English should be numbered in a consistent manner for readability and referencing purposes. Numbering the constructs helps facilitate citing or referencing within the Procedures Section of a process specification.
-
Use this construct to present a sequence of steps to be taken in order. It consists of imperative sentences, each of which is ended with a period and is indented equally in the construct. Indentation signifies the relationships and dependencies of statements within the various constructs. Figure 2.5.11-23 provides an example of a sequence construct.
Figure 2.5.11-23
This image is too large to be displayed in the current screen. Please click the link to view the image.Sequence Construct
-
Use this type of construct to select an action from among mutually exclusive alternative actions based upon the outcome of a specific condition. There are two versions of this construct, the If-Then-Else format and the Select-Case format.
-
When there are only two alternatives, use the If-Then-Else format. When there is no action to be taken, write the "Else" or the "Then" statement portion of the decision showing no action; or the "Else" statement portion may be omitted (unless it is being used as an end marker for readability). Figure 2.5.11-24 illustrates the If-Then-Else format.
Figure 2.5.11-24
This image is too large to be displayed in the current screen. Please click the link to view the image.Decision Construct
-
Figure 2.5.11-25 provides an example of an If-Then-Else Decision Construct.
Figure 2.5.11-25
This image is too large to be displayed in the current screen. Please click the link to view the image.Decision Construct
-
Use the Select-Case format when there are more than two alternatives, each mutually exclusive. Number each case, enclose in parentheses, and end with a comma. Once a case is selected and its action taken, ignore the subsequent case statements. Figure 2.5.11-26 provides an example of a Select-Case Decision Construct.
Figure 2.5.11-26
This image is too large to be displayed in the current screen. Please click the link to view the image.Decision Construct
-
Use the Repetition Construct to show action performed until some condition occurs to cause the action(s) to cease. Figure 2.5.11-27 illustrates a Repetition Construct.
Figure 2.5.11-27
This image is too large to be displayed in the current screen. Please click the link to view the image.Repetition Construct
-
Decision tables are a concise and efficient way of specifying processes, which have numerous combinations of conditions from which to choose in order to perform a specific action. Figure 2.5.11- 28 illustrates the format of a decision table. Exhibit 2.5.11- 3 illustrates a procedure and a decision table that expresses the same procedure.
Figure 2.5.11-28
This image is too large to be displayed in the current screen. Please click the link to view the image.Format of a Decision Table
-
Figure 2.5.11- 29 provides an example of a decision table.
Figure 2.5.11-29
This image is too large to be displayed in the current screen. Please click the link to view the image.Example of a Decision Table
-
A decision table comprises four typal sections, the following explains these sections:
-
Conditions Section: lists the conditions or statements that affect the process being specified and must be considered in performing the process being specified.
-
Condition Entries Section: indicates whether the condition is met or not. This section is subdivided into vertical columns that are generally numbered and are known as rules. The blocks within the condition entries section, when filled in, contain the responses to the conditions listed in the conditions section.
-
Actions Section: lists those actions that may be taken in order to perform the process.
-
Action Entries Section: This section is also subdivided into the same vertical columns or rules as the condition entries section. The blocks contain either an "X" (meaning perform the action) or either a " " or a "=" (meaning the action does not apply).
-
-
Exhibit 2.5.11- 3 illustrates the use of a narration and a decision table to describe the same procedure. For the purposes of this exhibit, a procedure to determine who will approve the selection and acquisition of contractual services is being used.
-
A decision tree is a graphic representation of a decision table; it communicates the same information in a different form. Figure 2.5.11- 29 provides an example of a decision table. Figure 2.5.11- 30 depicts a decision tree that expresses the decisions expressed in Figure 2.5.11- 29.
Figure 2.5.11-30
This image is too large to be displayed in the current screen. Please click the link to view the image.Decision Tree
-
Some processes are shared by different systems or are used more than once within a single system. These common processes are designated by adding the suffix "(COMMON)", capitalized and placed in parentheses, to the end of the process name.
-
In addition to the three attributes which apply to all process specifications, there are three cross-references associated with common process specifications:
-
Maintained by the organizational identification (branch, section, etc.) of those who have maintenance responsibility;
-
Last Revision month, day, and year of the latest revision;
-
Used By organizations that use the Process Specifications.
-
-
The first appearance of the common process specification in a data flow diagram set must list the description attribute; may list the constraints and procedures attributes; and must list the Maintained By and Last Revision cross-references. Subsequent occurrences of the common process specification need only list the Description attribute.
-
Each common process specification is the maintenance responsibility of one project team or organizational area; and only those responsible will be allowed to make changes to a specification. Any organizational area may use the specification, but the group with the maintenance responsibility will notify the users of any changes and revisions.
-
Exhibit 2.5.11- 4 provides an example of the first and then subsequent occurrence of a common process specification.
-
The primary deliverable that results from structured analysis is a functional specification package. After a system is defined using the tools of structured analysis, the resulting documentation must be packaged to derive the functional specification package.
-
Where applicable, naming standards shall be applied. Names, numbers, and all other identifiers shall be consistent among deliverables.
-
Standard identifying information should be provided on every page of the analysis documents. Include the following types of information when applicable:
-
System name;
-
Functional Specification Package number;
-
Responsible organization (e.g., branch/section);
-
Operational/Revision date;
-
Project Name/Project Number.
-
-
A functional specification package comprises one context diagram. The scope of the functional specification package should be consistent with the scope of the context diagram. The functional specification package comprises:
-
data flow diagrams, which graphically depict business processes and the data interfaces among these processes;
-
data definitions, which define and document the interfaces on the data flow diagrams;
-
process specifications, which specify the data transformations among the business processes.
-
-
The two allowable ways of ordering the data flow diagrams and process specifications within a functional specification package. The data flow diagrams should be sequenced in ascending numeric order and the process specifications placed immediately behind their associated data flow diagram or grouped together behind the entire data flow diagram set.
-
To maintain uniformity among functional specifications packages developed for a system, one of the following methods should be used for sequencing:
-
Sequence the Process Specification in the same sequential order they would appear in if they were interspersed with the data flow diagrams; or
-
Sequence the Process Specifications in ascending numeric order (e.g., 1.0, 2.0, 2.1, 2.1.1, 2.1.2, 2.2, 3.0, 3.1, 3.2, 3.3, 4.0).
-
-
Enter all data definitions into a system glossary and/or data dictionary. If a manual system glossary is being used, packaged it into the functional specification package.
-
In order to fully document a system, add other sections to a functional specification package. Graphic CRT screen displays for projects that use CRT terminals for processing should be organized into a Screen Display Section.
-
Organize Graphic formats for printed inputs and outputs such as reports (e.g., error registers) into a Print Report Layouts Section.
-
This section provides centralized information about the system's sources of input data and sinks for system output data.
-
Add a Table of Contents and/or cross-referencing material to aid the reader in understanding and following the functional specification package. Develop an alphabetical index of names of external entities, processes, data groups, and data elements; or a listing of external inputs and outputs, and processes to organize a functional specification package.