DI 39536.205 Developing a Systems Approach -- DDS
The DDS should follow an established approach to systems analysis and design to ensure that needs are assessed adequately and that the system developed will meet them successfully. The DDS is not required to follow a specific methodology, such as the top-down structured analysis used in SSA's SMP. However, any generally accepted approach will contain the following elements:
A. System life cycle concept
EDP Systems progress through a life cycle, passing through four distinct phases: the study phase, the design phase, the development phase, and the operation phase. Each phase involves different activities and progressive levels of approval.
1. Study phase
During the study phase, the situation is analyzed, problems are defined, opportunities are discovered, goals and objectives are identified, feasibility studies conducted, and functional requirements, including training and physical environmental requirements, for the recommended system are made.
2. Design phase
During the design phase, the specifications for the recommended system are created. System specifications include hardware and software specifications, and examples of physical specifications such as electrical, space, cabling, air conditioning and raised flooring.
3. Development phase
During the development phase, the specified equipment is procured and installed; the software is written and tested; procedures are written; personnel are trained; and plans are made to convert the operation to the new system.
4. Operation phase
During the operation phase, the system goes into live operation. Validation and acceptance testing are done. Periodically, performance reviews are conducted to ensure that the goals for the system are being achieved, and that it is responsive to changing requirements. Performance reviews may, in turn, trigger system upgrades, expansions, and replacements, which will themselves progress through the system life cycle.
B. Functional requirements
Functional requirements describe what a system does , as opposed to the actual hardware and software components of the system. Functional requirements usually include:
Data flow diagrams , which graphically represent sources, destinations and storage of data, and the processes performed by the system.
Data dictionaries , which describe the specific data elements and structures of the system.
Presentations of process logic , which describe specific processes in adequate detail.
Describing the system in logical rather than physical terms during the study phase promotes better communications between systems analysts and users. Users have detailed knowledge about the processes they perform, but cannot be expected to understand all the technical aspects of an automated system. Review of functional requirements provides the user the opportunity to confirm that a proposed system will do precisely what is desired, without getting distracted by the technical details of how the system would be implemented. Conversely, if system analysts have misunderstood the processes to be automated, corrections to the functional requirements can be made from the user's frame of reference.
Using logical rather than physical descriptions of the system provide an added advantage in that the design of the system will be based on the user's needs and not limited by preconceived notions concerning hardware and software.
C. Coordinating development of the system
See DI 39536.400 for guides for conducting the systems study. As the DDS begins to develop functional requirements, the staff will coordinate their plans with the regional office.
All functional requirements will be developed in accordance with SSA's data requirements for workload and fiscal reporting.