Simple Design
Document
Simple Design Document
System Name
3/8/2016
Table of Contents
1.
OBJECTIVES.................................................................................................................................... - 3 -
2.
GUIDANCE ....................................................................................................................................... - 3 -
3.
SCOPE................................................................................................................................................ - 3 -
4.
REFERENCES .................................................................................................................................. - 4 -
5.
OUTSTANDING ISSUES ................................................................................................................. - 4 -
6.
APPROVALS..................................................................................................................................... - 4 -
7.
ROLES ............................................................................................................................................... - 4 -
8.
INPUTS .............................................................................................................................................. - 5 -
9.
OUTPUTS .......................................................................................................................................... - 5 -
10. CONTROLS....................................................................................................................................... - 5 11. PROCEDURE ................................................................................................................................... - 5 11.1. ESTABLISH CONFIGURATION MANAGEMENT LIBRARY ................................................................. - 5 11.2. DEFINE THE ENVIRONMENT ........................................................................................................... - 5 11.3. ANALYZE THE COURT'S GOALS AND DIRECTION ........................................................................... - 5 11.4. IDENTIFY ACCEPTANCE CRITERIA ................................................................................................. - 6 11.5. DEFINE THE GOALS OF THE ORGANIZATION, PROCESS OR SYSTEM ............................................... - 7 11.6. MODEL THE EXISTING SYSTEM ..................................................................................................... - 7 11.7. DEFINE THE SCOPE ........................................................................................................................ - 7 11.8. DEVELOP CANDIDATE SOLUTIONS ................................................................................................ - 8 11.9. DEVELOP A SYSTEM CONCEPT STATEMENT .................................................................................. - 9 11.10. DEVELOP A DOMAIN MODEL OF THE NEW SYSTEM IN ITS ENVIRONMENT .................................. - 9 11.11. DEVELOP PROTOTYPES OR SIMULATIONS .................................................................................... - 9 11.12. DEVELOP THE SYSTEM CONCEPT SPECIFICATION ...................................................................... - 10 11.13. CONDUCT SYSTEM CONCEPT REVIEW - SCR ............................................................................. - 10 11.14. INVENTORY AND STORE PHYSICAL PROTOTYPES ...................................................................... - 11 -
-2-
Simple Design Document
System Name
3/8/2016
1.
Objectives
1.1.
To define a procedure for deriving and defining a system concept for the
operations and technology selection of a system development project. The system
concept is developed to help achieve a model or visualization of the system before
focusing on the details of specifying all system requirements and design elements.
1.2.
The key objective of developing a system concept or an operational concept is to
better define the project’s overall scope and boundaries (technically and
financially) so that the system requirements can be driven by the overriding
concept for the system.
2.
Guidance
2.1.
Concept definition is the visualization phase. Both technical and financial aspects
of the system must be taken into account when developing the concept. A
technically desirable concept may not be feasible if the cost is prohibitive.
Making adjustments to the concept before continuing further in the life-cycle is
more cost-effective for the entire project than proceeding on a technical premise
without having studied the financial impact of a given approach.
2.2.
Concept definition may involve developing prototypes of hardware, software,
special interface screens or devices, operational procedures, database
designs/structures, partial or full-scale simulators or mock-ups of operational
facilities or environments and other aspects of the system which require clearer
visualization prior to specifying requirements.
2.3.
This procedure provides a structured approach to analyzing an organization,
process or system through decomposition to define and quantify the problems,
causes, goals, objectives, solutions, desired outcomes and other key attributes
necessary in understanding and defining a system concept.
3.
Scope
3.1.
System concept definition generally occurs at the beginning of the system
development life cycle.
3.2.
The system concept is generally limited to defining, documenting and sometimes
prototyping necessary models or components of the system before engaging in
system requirements.
3.3.
Concept definition can be performed at any major milestone in the project where
it is necessary to clarify or modify the system concept.
3.4.
It may be necessary or desirable to establish a concept definition laboratory or a
mock-up and simulation facility depending upon the nature of the project.
-3-
Simple Design Document
System Name
4.
References
4.1.
Configuration Management Procedure
4.2.
Version Identification Procedure
4.3.
Life-Cycle Standard
4.4.
System Test Procedure
4.5.
System Delivery and Installation Procedure
4.6.
System Concept Specification Template
4.7.
System Concept Checklist
5.
Outstanding Issues
6.
Approvals
3/8/2016
6.1.
Changes to this procedure must be approved by the organization's Software
Engineering Process Group (SEPG).
7.
Roles
7.1.
The Project Manager is responsible for insuring that all project personnel follow
the procedure.
7.2.
The Systems Manager and the Configuration Manager are responsible for
insuring that a hardware and software audit are performed before disposing of
any physical prototypes or software prototypes.
7.3.
The Project Manager is responsible for selecting appropriate individuals from
his/her project departments to assist in the development of the system concept
and any prototypes to be developed.
-4-
Simple Design Document
System Name
3/8/2016
8.
Inputs
8.1.
Contractual Requirements for the system.
8.2.
System Requirements that may have been specified in the proposal or RFP
phase.
9.
Outputs
9.1.
Client Approved System and Operations Concept Specification Document
9.2.
Cost/Benefit Analysis of Candidate System Concepts
9.3.
Prototypes
9.4.
Results of reviews and inspections of the System and Operations Concept
Definition Specification.
9.5.
Results of system concept analysis and tradeoff studies and cost/benefit
analysis.
10.
Controls
10.1.
Reviews and/or inspections of the System and Operations Concept Definition
Specification insure that it accurately reflects the perspectives and requirements
of customers.
11.
Procedure
11.1. Establish Configuration Management Library
11.1.1. This is the beginning of system development work, so the Configuration
Management Library should be established according to the characteristics
defined in the Change Request Procedure.
11.2. Define the Environment
11.2.1. Define the Environment: Environment = Organizational Philosophy + Culture
+ Values + Systems + Needs + Resources + Strategies + Competitors. Define or
describe the organizational environment in which the system or project will
operate or be used.
11.3. Analyze the Court’s Goals and Direction
11.3.1. Define Opportunities: Opportunities = Unrealized potential in processes,
personnel, policies, strategy, markets, products, organization, other resources
-5-
Simple Design Document
System Name
3/8/2016
and technology. Identify opportunities for improvement of the existing
organization, process or system that are not specifically derived from existing
problems or inefficiencies.
11.3.2. Define the Problems: Problems = Short-comings + Causes +
Opportunities(derived from the problems). Define the problems inherent in the
existing system, process or approach. Identify specific problems or shortcomings
of the existing system that prevent it from fulfilling the goals and objectives of the
organization, process or system.
11.3.3. Identify goals that are fulfilled by the organization, process or system that could
be fulfilled more effectively.
11.3.4. Define the Causes: Causes = Nature of Existing Solutions + Environmental
Factors + Implementation of the Existing Solutions.
11.3.5. Define the Objectives: Objectives = Problems + Desired Outcomes +
Opportunities. Define the objectives to be accomplished by the system in terms
of the existing problems that have been identified that should be solved and the
opportunities presented by other forms of unrealized potential. The objectives
should be stated in terms of the quantified outcome that is desired.
11.3.6. Prioritize the objectives to identify those that are the most critical to the success
of the organization, process or system.
11.4. Identify Acceptance Criteria
11.4.1. Quantify the desired outcomes of the organization, process or system so that the
results of implementation can be measured against these criteria.
11.4.2. Use the quantifiable desired outcomes as the acceptance criteria for the new
organization, process or system.
11.4.3. Define the Quality factors that will determine the acceptance of the organization,
process or system. These quality factors include, but are not limited to:

Usability

Reliability

Safety

Security

Efficiency
-6-
Simple Design Document

Flexibility

Maintainability

Currency of information

Response effectiveness

Aesthetic appeal
System Name
3/8/2016
11.5. Define the Goals of the Organization, Process or System
11.5.1. Define the Goal Statement: Goal Statement = Goals + Objectives to be
accomplished by the system or project. Define the goals that the court hopes to
achieve during the course of this project. Formulate the list of individual
objectives into a cohesive definition of the purpose, mission, and goals of the
organization, process or system.
11.5.2. Review each objective to determine how it can be stated or grouped with other
objectives and restated in terms of a goal of the organization, process or system.
11.5.3. Review the objectives and goals to insure that they are clear and concise, not
ambiguous.
11.6. Model the Existing System
11.6.1. Define the Agents: Agent = (Agent Roles + Events)/Domain. Define the agents,
which play a role in the environment. These agents may be individuals, systems,
organizations or other autonomous entities that have some capacity to act and
react to events occurring within the defined environment. Playing of their roles
by the various agents causes certain effects to occur within the environment and
agents exert varying degrees of control over their portion of the domain.
11.6.2. Define the Domain Model: Domain Model = Environment + Agents (expand this
section)
11.7. Define the Scope
11.7.1. Define the Constraints of the organization, process or system. These constraints
include, but are not limited to:

Financial
-7-
Simple Design Document
System Name
3/8/2016

Personnel

Time/Schedule

Training/Certification

Organizational Flexibility/Adaptability: Degree to which organizational
processes or policies may have to change to implement the new
organization, process or system.

Technology

Policy constraints

Security constraints

Legal constraints

Privacy constraints

Accessibility constraints (section 508 Accessibility Requirements)

Other resource constraints
11.7.2. Define the Scope in terms of the various constraints that will or should be
imposed on the organization, process or system.
11.8. Develop Candidate Solutions
11.8.1. Brainstorm a list of solutions to the specific problems. Do not impose constraints
or judgments on the solutions; simply develop a list of solutions regardless of
their feasibility or merit.
11.8.2. Evaluate the solutions against the acceptance criteria and the goals and objectives.
Determine which solutions best accomplish the objectives within the constraints.
11.8.3. Optimize any promising solutions to determine if they can more effectively
accomplish the objectives of the project within the constraints.
11.8.4. Continue the brainstorming, evaluation and optimization until a list of reasonable
solutions (effective solutions that satisfy the objectives within the constraints) is
developed.
-8-
Simple Design Document
System Name
3/8/2016
11.8.5. If any solutions do not satisfy all constraints, review the solutions and the
constraints to see if either can be modified in some way that the combination of
the solution and the imposed constraints comes closer to satisfying the goals and
objectives of the project.
11.8.6. Select candidate solutions and approaches based on how well they satisfy the
acceptance criteria and fit within the established constraints.
11.9. Develop a System Concept Statement
11.9.1. Define the Concept Statement: Concept Statement = Goals + Solutions +
Constraints + Scope. The Concept Statement should reflect the overall vision,
mission, purpose and goals of the organization, process or system. The Concept
Statement should clearly and succinctly state the approach to be used in terms of
the selected solutions. The concept is the combination of the goals and objectives
to be fulfilled and the solutions and strategies that will be implemented.
11.10. Develop a Domain Model of the New System in its
Environment
11.11. Develop Prototypes or Simulations
11.11.1. Identify the type, scope, nature, number and goals of any prototypes to be
developed. More than one prototype is generally recommended for a software
system. Prototyping can also be performed for developing policies, sample
products, presentations, multimedia or film/video products and prototypes of
product packaging, facilities, devices and other aspects of the project that should
be visualized and evaluated prior to making key decisions about implementation.
11.11.2. Develop the hardware/software/interface or other prototype(s) and simulations to
help visualize the candidate concepts being developed. It may be necessary to
limit the number and scope of the prototypes depending upon resource limitations.
It may even be necessary to limit the effort to prototyping only the chosen
candidate system concept.
11.11.3. Depending upon the nature of the project it may be necessary to build partial or
full-scale models, simulators or even a mock-up of an operational environment
concept or facility. If this is the case, it may be necessary to follow the Facility
Engineering and Site Preparation Procedure to define and develop the mock-up,
the simulation facility or any other special physical considerations to be
developed during this concept definition phase.
-9-
Simple Design Document
System Name
3/8/2016
11.11.4. Demonstrate how the prototype meets technical requirements and cost estimates
11.11.5. Conduct a cost/benefit analysis of the system capabilities of the competing
candidate concepts to provide objective evaluation criteria for selecting a final
candidate or individual system features. Use the cost and schedule estimates
produced above to perform the analysis.
11.11.6. Prototyping may be necessary for the purpose of testing and validating:

User Interface

Processing Algorithm

User Interface Hardware or other hardware

Process Model

Database Structures
11.12. Develop the System Design
11.12.1. Develop the System Design Document according to the document template for
this document. Employ the information derived in this procedure in the
appropriate sections of the document.
11.13. Conduct System Concept Review - SCR
11.13.1. Perform an internal review of the System Design Document prior to reviewing
the specification formally at the System Concept Review (SCR) meeting.
11.13.2. Make any necessary corrections or changes to the System Design Document.
11.13.3. Review the System Design Document at a scheduled review meeting (SCR).
11.13.4. Make any necessary changes to the System Design Document as requested.
11.13.5. Acquire written approval of the revised System Design Document before
beginning the next phase of the project..
- 10 -
Simple Design Document
System Name
3/8/2016
11.14. Inventory and Store Physical Prototypes
11.14.1. Identify, label and inventory any physical equipment or other prototypes, which
cannot be stored in a document or source code repository.
11.14.2. It is recommended that if it is not feasible to permanently store physical
prototypes that several photographs should be taken of the prototypes before
disposing of the physical prototypes.
11.14.3. If photographs are taken, they should ideally be digitally scanned and inserted
into the System Design Document or simply stored in the electronic source code
and documentation repository and a hardcopy of each photograph stored in the
project file.
- 11 -