SDLC Deliverables and Techniques
SDLC Guidebook
SDLC Deliverables and Techniques
System Initiation Phase
Processes
Prepare for System
Initiation
Techniques
Interviews
Document Gathering and
Reviews
Process Deliverables
(Outcomes)
Establish Team and Environment
for System Initiation
Define Security Roles and
Responsibilities*
Orient Staff on the SDLC
Security Tasks*
Establish a System Criticality
Level*
Verify Proposed Solution
Brainstorming
Verified Proposed Solution
Research
Classify Information
(preliminary)*
Establish System Security
Profile Objectives
(preliminary)*
Create a System Profile
(preliminary)*
Assist in Developing
System Schedule
Brainstorming
Research
Work Breakdown Structure
(WBS),
High level estimates using
predefined Estimation Models
Estimating
System Requirements Analysis Phase
Processes
Prepare for System
Requirements Analysis
Techniques
Site Walk-through
Project Origination and
Business Case Reviews
Team Skills Assessment
Technology Needs Assessment
Page 1 of 15
Process Deliverables
(Outcomes)
Established Team and
Environment for Requirements
Analysis
Stakeholder Map (Initiated as a PM
activity but must be correct and up
to date during this phase)
SDLC Deliverables and Techniques
SDLC Guidebook
Determine Functional and
Non-Functional
Requirements
Tool Needs Assessment
System Context Diagram
Stakeholder Analysis (though
done as a part of Project
Management (PM) activity, the
project PM and business
analyst (BA) must ensure that
the stakeholders identified are
still current and correct.)
Template:
Establish an Information
Profile (iterative)*
Establish System Security
Profile Objectives (iterative)*
Decompose the System
(preliminary)*
Organizational Modeling
Scope Modeling
System Context Diagram
Business Requirements Document
-
Business and Functional
Requirements
-
Non-Functional Requirements
-
Business Rules
-
Requirements Traceability
Matrix
Functional Decomposition
Interviews
Observation (Job Shadowing)
Focus Groups
Acceptance and Evaluation
Criteria
Scenarios and Use Cases
Sequence Diagrams
User Stories
JAD Sessions
Brainstorming
Storyboarding
Prototyping
Structured Walk-through
Event Analysis
Business Rule analysis
Requirements Workshops
Risk Analysis
Root Cause Analysis
Page 2 of 15
Template:
Business Requirements Document
SDLC Deliverables and Techniques
SDLC Guidebook
Define Process Model
Work Flow Diagrams
Process Model
Flow Chart Diagrams
Business Process Models
Use Case Diagrams
Decision Analysis
Prototyping
Define Logical Data Model
Classify Information
(iterative)*
Logical Data Model
Requirements Data Model
Data Dictionary
Existing File Descriptions
Data Conversion Requirements
Archiving and Retention
Requirements
Reconcile Functional and
Non -Functional
Requirements with
Models
Current State Gap Analysis
Current Assessment Document
Scenarios and Use Case
Modeling
Validated Functional and
Non-Functional Requirements and
Models
Data Modeling
Use Cases
ER Diagrams
Class Diagrams
System Design Phase
Processes
Prepare for System
Design
Techniques
Interviews
Site Walk-throughs
Create a System Profile
(iterative)*
Decompose the System
(iterative)*
Assess Vulnerabilities and
Threats (preliminary)*
Assess Risks (preliminary)*
Page 3 of 15
Process Deliverables
(Outcomes)
Established Team and
Environment for System
Design
SDLC Deliverables and Techniques
SDLC Guidebook
Define Technical
Architecture
Interviews
Technical Architecture
Document Gathering and
Reviews
Role/Authorization Analysis
Define System
Standards
Select and Document Security
Controls (preliminary)*
Interviews
System Standards
Brainstorming
Policy and Standards Reviews
Create Physical
Database
Formal Walk-throughs
Databases and System Files
Standard Data Definition
Languages
Data Administration
Techniques
(Data Normalization,
De-Normalization)
Prototype System
Components
Iterative Prototypes/Reviews
Presentations
Prototype and Proof of
Concept Results
GUI/Report Development
Tools
Produce Technical
Specifications
Function Decomposition
Expressing Logic: Pseudo
Code, Structured English,
Object Oriented Logic
Operational Requirements
Assessment System Load
Analysis Business Impact
Analysis Potential Problem
Analysis
Technical Specifications
 Module Specifications
 Security, Database, Network,
Application Architectures
 Test Plans/Test Cases
 Deployment/ Transition Plans
Template:
Technical Specifications
Training Needs
Decomposition
System Construction Phase
Processes
Prepare for System
Construction
Techniques
Interviews
Process Deliverables
(Outcomes)
Established Team
and Environment
Page 4 of 15
SDLC Deliverables and Techniques
SDLC Guidebook
Site Walk-throughs
Environmental Assessments
Refine System
Standards
Brainstorming
for System
Construction
Refined System Standards
Policy and Standards
Reviews Best Practice
Assessments Lessons
Learned Reviews
Prototyping
Assess Vulnerabilities and
Threats (iterative)*
Assess Risks (iterative)*
Select and Document Security
Controls (iterative)*
Build, Test, and Validate
(BTV)
Coding
Unit Test Results
Create test data*
Unit Tested System Components
Manual Testing
Unit Tested System Utilities
Automated
Testing
Data Conversion Utilities
Defect Tracking
Conduct Integration and
System Testing
Manual Testing
Automated
Testing
Integration and System Test
Results
Validated System
Defect Tracking
Validated System Utilities
Regression Testing
Test Security Controls*
Produce User and
Training Materials
Technical Writing
User Manual
Illustration
Training Materials
On-line Content
Development JAD Sessions
Prototypes/Content Review
Current State Gap Analysis
Scenarios and Use Case
Modeling
Data Modeling
Produce Technical
Documentation
Technical Writing
Illustration
On-line Content Develop
Page 5 of 15
Technical Documentation
SDLC Deliverables and Techniques
SDLC Guidebook
Security Documentation
Prototypes/Content Review
System Acceptance Phase
Processes
Prepare for System
Acceptance
Techniques
Interviews
Site Walk-throughs
Environmental Assessments
Process Deliverables
(Outcomes)
Established Team and
Environment for System
Acceptance
Acceptance Test Plan Review
Validate Data
Initialization and
Conversion
Manual Testing
Data Validation Test Results
Automated Testing
Validated Data Initialization and
Conversion Software
Defect Tracking
Regression Testing
Test, identify, Evaluate,
React (TIER)
Manual Testing
Acceptance Test Results
Automated Testing
Validated System
Measure security compliance*
Validated System Utilities
Document System Security
Profile*
Document Security
Requirements and Controls*
Defect Tracking
Regression Testing
Refine Supporting
Materials
Technical Writing/
Illustration
Revised User/Training Materials
Revised Technical Documentation
On-line Content
Development/Content Review
System Implementation Phase
Processes
Prepare for System for
System Implementation
Techniques
Interviews
Distribution of Materials
Coordination of Training
Logistics
Page 6 of 15
Process Deliverables
(Outcomes)
Established Team and
Environment for System
Implementation
SDLC Deliverables and Techniques
SDLC Guidebook
Deploy System
Training Sessions
Migrated and Initialized Data
Manual Business Operations
Operational System
Parallel Operation
Perform System Certification
and Accreditation *
Transition to Performing
Organization
Training Sessions
Phased Ownership
Ownership of System by
Performing Organization
* Security Activities within SDLC Phases (ITS-S13-XXX)
SDLC Process Deliverables
Archiving and Retention: The purpose of the archiving and retention requirements analysis is to
define and document the business rules, laws, mandates or policies governing the handling of data
that is no longer in active use. Archiving defines at what point the data would be moved to an
offline storage media. Retention defines at what point the data would be deleted permanently.
Back up and Recovery: Criticality and sensitivity of logical data is described. Requirements for
data availability, when scheduled unavailability is acceptable, and a description of data recovery
and restoration requirements are defined. Back up and Recovery requirements are typically
described for the entire dataset. If necessary, specific entities and/or attributes maybe
highlighted when back up and recovery needs are unique.
Business Requirements Document: The Business Requirements Document (BRD) details the
customer’s needs and expectations in order to meet their business objectives. It describes what
the system should accomplish rather than how. The BRD is the foundation for all subsequent
deliverables. See Business Requirements Document template. The BRD includes the following
sections:

High Level Overview that includes the project background, purpose and scope of the project.
A link to the Stakeholders map is also included. References to relevant documents such as
the Scope Statement, Business Case, etc. if applicable should be listed. Project Assumptions,
Dependencies and Constraints are included here also.

As-Is State if applicable, this section contains a clear representation of how things are
currently done. It should include the goals, objectives workflow, business rules and tasks as
they currently exist. Current issues and opportunities should also be identified. Graphic
diagrams (e.g., Context, Business Process Flow, Data Flow, Swimlane or others as appropriate)
may be included.

To-Be State includes the business case justification, identify what changes are needed to
bridge the gap between what exists currently and what the project will deliver, a description
of the proposed solution and any impacts that the project results will have on the business.
Graphic diagrams (e.g., Context, Business Process Flow, Swimlane or others as appropriate)
may be included.

Business and Functional Requirements specify the full set of functional capabilities needed
Page 7 of 15
SDLC Deliverables and Techniques
SDLC Guidebook
by the new/modified system.
o
Business requirements are higher-level statements of the goals, objectives, or needs
of the enterprise. They describe the reasons why a project has been initiated, the
objectives that the project will achieve, and the metrics that will be used to measure
its success. Basically, requirements state what a system needs to do in order to
provide a capability and meet its objectives.
o
Functional requirements are a complete description of how the system will function
from the user’s perspective. They describe the behavior and capabilities of an
application, including the information or data that the application will manage.
Functional requirements typically have one or more business rules associated with
them. Business rules state the condition under which the functional requirement is
applicable and the rule to be applied; they provide the criteria, conditions, and
exceptions for a scenario.
Three graphical representations that will be included in the Functional Requirements are:
System Context Diagram, Business Flow Diagram, and System Interface Diagram. Also
included in the Functional Requirements are: the reporting requirements, the menu structure,
security, accessibility, Mockup Screens, and Logical Data Model.
The Functional
Requirements will evolve throughout this phase of the SDLC as the Detailed Functional
Requirements are captured, and as supporting process and data models are created, ensuring
that the eventual solution provides the Customers with the functionality they need to meet
their stated business objectives.

Non-Functional Requirements identify the expected response times of the application, data
volumes of the application to process or report, data classification, availability of application,
data archiving and retention, Recovery Point Objective (RPO), Recovery Time Objective (RTO)
to plan or schedule system outages. In addition to Stakeholders’ needs, the Non-Functional
Requirements must also capture Non-Functional NYSDOT ITS Specific Standards
Requirements, such as security (roles, restrictions and permissions), accessibility
(http://www.w3.org/), ADA (http://www.access-board.gov) and authorization, legal and
regulatory requirements. The Non-Functional Requirements also include: on-line help,
training needs, number of users, peak times for the system, hardware required.

Requirements Traceability Matrix link to a table that illustrates logical links between
individual functional requirements and other types of system artifacts, including other
Functional Requirements, Use Cases, Architecture and Design Elements, Code Modules, Test
Cases, and Business Rules.
Data Conversion Requirements: determining and documenting data conversion requirements
includes analyzing and defining source data, determining if source data is valid and/or required for
the new data model and defining the process to translate source data into the target entities and
attributes. This deliverable includes narrative descriptions of the source data describing its
business meaning. The process to translate source data into data model entities and attributes
includes translation of data into accepted standards used by the new application. The valid values
for the attributes are described in the logical data model. Data Conversion analysis may include
determining data cleansing requirements. During this step the source data is reviewed to
determine if redundant, obsolete or inaccurate data is contained in the data source. Processes are
then defined to “cleanse” the data for the new application.
Page 8 of 15
SDLC Deliverables and Techniques
SDLC Guidebook
Data Dictionary: defines key terms and data relevant to a business domain. Data dictionaries or
glossaries are used to formally identify and define all terminology used by the organization or
organizational unit. For example, an organizational unit may differentiate between a client and a
program area, where a client is a party with whom the business has an enforceable professional
service agreement, whereas a program area may have a much more casual, transaction based
relationship with the business. In a healthcare organization, such as a hospital, the term patient
may be used, along with its unique definition, rather than either client or program area.
Existing File Descriptions: Existing file layouts and existing database descriptions are
accumulated and reviewed. Identification of data used to initialize the new application as well as
data sources that are inputs to the normal processing cycle of the new applicatin are compiiled. If
incomplete documentation is available for the existing data, analysis is done to determine the
“business meaning of the available data.
Performance Analysis: This includes general utilitization information including number and
location of system end users, hours of operation, and peak utilization of the application.
Requirements Traceability Matrix: This is a template/tool that can be used to help trace
requirements and their relationships within the project. If requirements are complex, this helps
ensure that the project’s scope, requirements, and deliverables remain “as is” when compared to
the baseline. It enables the team to “trace” the deliverables by establishing a thread for each
requirement- from the project’s initiation to the final implementation. The purpose of a
traceability matrix is to create and maintain relationships between business objectives,
requirements, to solution components and to other artifacts such as test cases. Requirements
traceability identifies and documents the lineage of each requirement, including its backward
traceability (derivation), its forward traceability (allocation), and its relationship to other
requirements. Sample traceability matrices are shown below.
Requirement Information
I
D
Requirement
Description
Priority
Category
Relationship Traceability
Relates to
Business
Objective
Source
Manifests in WBS
Deliverable or task
OR
Requirement Traceability Matrix
Req
#
Req#:
Req. Name
RFP #
WBS task #
TS #
Requirement Number; for each project requirement
Page 9 of 15
Verification
Verification
Validation
SDLC Deliverables and Techniques
SDLC Guidebook
Req Name: Enter the name and brief description of the requirement
RFP #: Request For Proposal (RFP); specify the identification number of the requirement as listed in the
RFP.
WBS task#: List the MS Project Subtask and Task numbers that are associated with the requirement.
TS #: Test scripts should be prepared for the actual testing process.
Verification: Use this field to record completion of the signoff process.
System Context Diagram: The Context Diagram represents a high-level view of the business
processes of a system, and can serve to clarify the system boundary and scope of analysis. It
identifies any internal or external entities (other systems, business units or organizations) with
which the system interacts and identifies, at a high level, the business process inputs and outputs
from and to these entities. See System Context Diagram Guidelines.

AS-IS System Context Diagram - This context diagram is created at the start of a project
and used to understand and communicate among project stakeholders and participants
what entities the system currently interacts with and the relevant information flows (inputs
and outputs) that exist between these entities and the system.

Conceptual (TO-BE) and Finalized System Context Diagram -During system design and
development, the conceptual (TO-BE) or finalized system context diagram is developed and
represents any changes to the “AS-IS” Context Diagram entities, and information flows
to/from these entities.
Technical Specifications: The Technical Specification forms the basis for technical design,
technical development, workflows, and procedures for using the system/product/ service and all
testing plans. They describe how the business requirements will be translated into the system
and application components. Its goal is to help ensure a clear understanding of what the
developers are supposed to build in satisfying overall business requirements, and to ensure
internal standards and best practices are met. This document captures the following information:








Project Information
o Summary Details
o Key Project Contacts
o Key Dates
Web Development Standards
Information Security Classification
Design and Technology Details
o System Profile
o Solution Details
o Guidelines and Best Practices
Required Documents
o Business Requirement Document (BRD)
User Community
Support & Service Requirements
o System Availability Required
o Support and Service Delivery
o Maintenance Windows
o Solution Support Groups
Solution Stack
o Operating System
Page 10 of 15
SDLC Deliverables and Techniques
SDLC Guidebook





o Web Server
o Application Server / Middleware
o Database Management System
o Client Device
o Development Languages
o Virtualization
o Directory Services
o Active Directory Schema
o Windows Servers Active Directory (AD) Membership
o Network
Application Architecture
o Description
o Layers
o Session Management
o Open Source, Freeware, and or Shareware
o Presentation, Business and Data Logic
Application Integration
o External System Dependencies
Network Architecture
o Network Architecture and Design Description
 Network Diagram
 Network Enhancements / Changes
 Environments
o Communications and Performance
 Data Flows and Network Protocols
 Network Traffic
 Domain Name Services
Database Architecture
o Initial Size of Database
o Anticipated Annual Growth
o Database Features
 Database Environment
 Database Connection Account Type
o Stored Procedures
o Object-Relational Mapping
o Archive Log Mode
o Number of Database Instances
o Clustering
o Database Normalization
Security Architecture
o Threat Mitigation Plan
o Application Security
 User Identification and Authentication
 Roles
 Authorization and Access Control
 Entity Store
 Account Management
 Data Segregation
 Data Integrity
 Session Management
Page 11 of 15
SDLC Deliverables and Techniques
SDLC Guidebook




 Input Validation
 Use of Mobile Code
 Security of Interfaces to the Internet and/or Other Systems
 SOA / Web Services
 Exception Handling
 Cached Data / Temporary Files
 Application Logging
 Application Auditing
o Infrastructure and Network Security
 Network Security
 Separation of Administrative and User Traffic
 Operating System Accounts and Privileges
 Server Hardening
o Database Security
 Local User Management
 Database Logging
 Database Link Privileges
o Security and Audit Logs
 Remote Archiving
o Cryptography and Key Management
 Appropriate Use of Encryption
 Digital Certificate Management
 Encryption Key Management
Pre - Production Environment Security
Enterprise Backup and Recovery
o Backups
 Schedule
 Data Retention
o Disaster Recovery
 Disaster Recovery
 Business Continuity
System Module Specifications
o Sub-System A
 Module A-1
 Module Overview
 Interface Prototype
 Customer Decision Maker(s)
 Customer Representative(s)
 Inputs
 Interfaces
 Security Considerations
 Logic Flow & Sequence Diagram
 Outputs
 Database Access
 Common Elements Used
 Module Review Process
 Audit Tracking
 Special Considerations
System Test Plans
o Unit Test Plan
Page 12 of 15
SDLC Deliverables and Techniques
SDLC Guidebook
Integration Test Plan
System Test Plan
Acceptance Test Plan
Performance Testing
 Performance Profiling
 Stress Testing
 Load Testing
Regression Test
o Defect clustering
Deployment and Transition Plans
o Consumer Training and Deployment
o Data Preparation
o Backup and Recovery
o Software Migration
o Production Start-up
o Production Verification
Application Architecture Diagram
Technical Architecture Diagram
o
o
o
o




Description of SDLC Security Activities (as defined in - ITS-S13-XXX)
Define Security Roles and Responsibilities: Security roles must be defined and each security
activity within the SDLC must be clearly assigned to one or more security roles. These roles must be
documented and include the persons responsible for the security activities assigned to each role. To
accomplish this, the default definition of an SDLC role may be expanded to include security
responsibilities and/or new security roles may be defined to encompass security activities. In all
cases, the assignment of security activities to roles, and the identification of persons given
responsibility for these roles, must be clearly documented.
For the purpose of utilizing a consistent definition of roles across various SDLC’s, it is highly
recommended that SE’s utilize as guidelines the New York State Office of Information Technology
Services (OITS) Enterprise Program Management Office (EPMO) and the National Institute of
Standards and Technology (NIST) publications . Of specific relevance to the definition of roles and
SDLC frameworks are:
 EPMO NYS Project Management Guidebook (PMG)
 NIST Special Publication 800-64, Security Considerations in the System Development Life Cycle
Orient Staff to the SDLC Security Tasks: All parties involved in the execution of a project’s SDLC
security activities must understand the purpose, objectives and deliverables of each security
activity in which they are involved or for which they are responsible.
Establish System Criticality Level: When initiating an application or system, the criticality of the
system must be established. The criticality level must reflect the business value of the function
provided by the system and the potential business damage that might result from a loss of access to
this functionality.
Classify Information: As per New York State policy
http://www.dhses.ny.gov/ocs/resources/documents/Cyber-Security-Policy-P03-002-V3.4.pdf, all
information contained within, manipulated by or passing through a system or application must be
classified. Classification must reflect the importance of the information’s confidentiality, integrity
and availability.
Page 13 of 15
SDLC Deliverables and Techniques
SDLC Guidebook
Establish System Security Profile Objectives: When initiating an application or system, the
security profile objectives must be identified and documented. These objectives must state the
importance and relevance of identified security concepts (??????) to the system and indicate the
extent and rigor with which each security concept is to be built in or reflected in the system and
software. Each security concept must be considered throughout each life cycle phase and any
special considerations or needs documented.
The purpose behind establishing system security profiles and monitoring them throughout the
lifecycle is to be actively aware of the relative priority, weight and relevance of each security
concept at each phase of the system’s life cycle. SE’s must verify that the security profile
objectives adequately consider all federal, state and external security mandates for which the
system must be compliant.
Profile the System: The system or application being developed must be iteratively profiled by
technical teams within the SDLC. A system profile is a high-level overview of the application that
identifies the application’s attributes such as the physical topology, the logical tiers, components,
services, actors, technologies, external dependencies and access rights. This profile must be
updated throughout the various phases of the SDLC.
Decompose the System: The system or application must be decomposed into finer components
and its mechanics (i.e. the inner workings) must be documented. This activity is to be iteratively
performed within the SDLC. Decomposition includes identifying trust boundaries, information
entry and exit points, data flows and privileged code.
Assess Vulnerabilities and Threats: Vulnerability assessments must be iteratively performed
within the SDLC process. Threat assessments must consider not only technical threats, but also
administrative and physical threats that could have a potential negative impact on the
confidentiality, availability and integrity of the system. Threat assessments must consider and
document the threat sources, threat source motivations and attack methods that could potentially
pose threats to the security of the system.
Threat assessments must adhere to all relevant state and federal mandates to which the SE must
comply and follow industry best practices including the documentation of the assessment
processes. Threat assessments and the underlying threat modeling deliverables that support the
assessment must also be fully documented. Appendix E within this document includes a list of
recommended resources for performing threat assessments.
Assess Risk: Risk assessments must be iteratively performed within the SDLC process. These
begin as an informal, high-level process early in the SDLC and become a formal, comprehensive
process prior to placing a system or software into production.
All realistic threats and vulnerabilities identified in the threat assessments must be addressed in
the risk assessments. The risk assessments must be based on the value of the information in the
system, the classification of the information, the value of the business function provided by the
system, the potential threats to the system, the likelihood of occurrence, the impact of the failure of
the system and the consequences of the failure of security controls.
All identified risks are to be appropriately managed by avoiding, transferring, accepting or
mitigating the risk. Ignoring risk is prohibited. Risk assessments must adhere to all relevant state
and federal mandates to which the SE must comply and be fully documented.
The risk assessments must be periodically reviewed and updated as necessary whenever the
underlying threat assessment is modified or whenever changes are made to the system. Appendix E
within this document includes a list of recommended resources for performing risk assessments.
Page 14 of 15
SDLC Deliverables and Techniques
SDLC Guidebook
Select and Document Security Controls: Appropriate security controls must be implemented to
properly mitigate risks that are not avoided, transferred or accepted. Security controls must be
justified and documented based on the risk assessments, threat assessments and analysis of the
cost of implementing a potential security control relative to the decrease in risk afforded by
implementing the control.
Documentation of controls must be sufficiently detailed to enable verification that all systems and
applications adhere to all relevant security policies and to respond efficiently to new threats that
may require modifications to existing controls.
Residual risk must be documented and maintained at acceptable levels and a formal risk
acceptance, with executive management sign-off, must be performed for medium and high risks
that remain after mitigating controls have been implemented.
Security control requirements must be periodically reviewed and updated as necessary whenever
the system or the underlying risk assessment is modified.
Create Test Data: A process for the development of significant test data must be created for all
applications. A test process must be available for applications to perform security and regression
testing.
Confidential production data should not be used for testing purposes. If production data is used, SEs
must comply with all applicable federal, state and external policies and standards regarding the
protection and disposal of production data.
Test Security Controls: All controls are to be thoroughly tested in pre-production environments
that are identical, in as much as feasibly possible, to the corresponding production environment.
This includes the hardware, software, system configurations, controls and any other
customizations.
The testing process, including regression testing, must demonstrate that all security controls have
been applied appropriately, implemented correctly and are functioning properly and actually
countering the threats and vulnerabilities for which they are intended. The testing process must
also include vulnerability testing and demonstrate the remediation of critical vulnerabilities prior
to placing the system into production.
Appropriate separation of duties must be observed throughout the testing processes such as
ensuring that different individuals are responsible for development, quality assurance and
accreditation.
Perform Accreditation: The system security plan must be analyzed, updated, and accepted by SE
executive management.
Page 15 of 15