SDLC Deliverables and Techniques

SDLC Guidebook

SDLC Deliverables and Techniques

System Initiation Phase

Processes / Techniques / Process Deliverables (Outcomes)
Prepare for SystemInitiation / Interviews
Document Gathering andReviews
Define Security Roles and Responsibilities*
Orient Staff on the SDLC Security Tasks*
Establish a System Criticality Level* / Establish Team and Environment for System Initiation
Verify Proposed Solution / Brainstorming
Research
Classify Information (preliminary)*
Establish System Security Profile Objectives (preliminary)*
Create a System Profile(preliminary)* / Verified Proposed Solution
Assist in Developing System Schedule / Brainstorming
Research
Estimating / Work Breakdown Structure (WBS),
High level estimates using predefined Estimation Models

System Requirements Analysis Phase

Processes / Techniques / Process Deliverables (Outcomes)
Prepare for System Requirements Analysis / Site Walk-through
Project Origination and Business Case Reviews
Team Skills Assessment
Technology Needs Assessment
Tool Needs Assessment
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.) / 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)
System Context Diagram
Template:
System Context Diagram
Determine Functional and Non-Functional Requirements / Establish an Information Profile (iterative)*
Establish System Security Profile Objectives (iterative)*
Decompose the System (preliminary)*
Organizational Modeling
Scope Modeling
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 / Business Requirements Document
-Business and Functional Requirements
-Non-Functional Requirements
-Business Rules
-Requirements Traceability Matrix
Template:
Business Requirements Document
Define Process Model / Work Flow Diagrams
Flow Chart Diagrams
Business Process Models
Use Case Diagrams
Decision Analysis
Prototyping / Process Model
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
Scenarios and Use Case Modeling
Data Modeling / Current Assessment Document
Validated Functional and Non-FunctionalRequirements and Models
Use Cases
ER Diagrams
Class Diagrams

System Design Phase

Processes / Techniques / Process Deliverables (Outcomes)
Prepare for System
Design / Interviews
Site Walk-throughs
Create a System Profile (iterative)*
Decompose the System (iterative)*
Assess Vulnerabilities and Threats (preliminary)*
Assess Risks (preliminary)* / Established Team and Environment for System Design
Define Technical
Architecture / Interviews
Document Gathering and Reviews
Role/Authorization Analysis
Select and Document Security Controls (preliminary)* / Technical Architecture
Define System
Standards / Interviews
Brainstorming
Policy and Standards Reviews / System Standards
Create Physical
Database / Formal Walk-throughs
Standard Data Definition
Languages
Data Administration Techniques
(Data Normalization, De-Normalization) / Databases and System Files
Prototype System
Components / Iterative Prototypes/Reviews
Presentations
GUI/Report Development Tools / Prototype and Proof of Concept Results
Produce TechnicalSpecifications / Function Decomposition
Expressing Logic: Pseudo Code, Structured English, Object Oriented Logic
Operational Requirements
Assessment System Load Analysis Business Impact Analysis Potential Problem Analysis
Training Needs Decomposition / Technical Specifications
  • Module Specifications
  • Security, Database, Network, Application Architectures
  • Test Plans/Test Cases
  • Deployment/ Transition Plans
Template:
Technical Specifications

System Construction Phase

Processes / Techniques / Process Deliverables (Outcomes)
Prepare for System
Construction / Interviews
Site Walk-throughs
Environmental Assessments / Established Team and Environment for System Construction
Refine System
Standards / Brainstorming
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)* / Refined System Standards
Build, Test, and Validate (BTV) / Coding
Create test data*
Manual Testing
Automated Testing
Defect Tracking / Unit Test Results
Unit Tested System Components
Unit Tested System Utilities
Data Conversion Utilities
Conduct Integration and System Testing / Manual Testing
Automated Testing
Defect Tracking
Regression Testing
Test Security Controls* / Integration and System Test Results
Validated System
Validated System Utilities
Produce User and Training Materials / Technical Writing
Illustration
On-line Content Development JAD Sessions
Prototypes/Content Review
Current State Gap Analysis
Scenarios and Use Case Modeling
Data Modeling / User Manual
Training Materials
Produce Technical Documentation / Technical Writing
Illustration
On-line Content Develop Security Documentation
Prototypes/Content Review / Technical Documentation

System Acceptance Phase

Processes / Techniques / Process Deliverables (Outcomes)
Prepare for System Acceptance / Interviews
Site Walk-throughs
Environmental Assessments
Acceptance Test Plan Review / Established Team and Environment for System Acceptance
Validate Data Initialization and Conversion / Manual Testing
Automated Testing
Defect Tracking
Regression Testing / Data Validation Test Results
Validated Data Initialization and Conversion Software
Test, identify, Evaluate, React (TIER) / Manual Testing
Automated Testing
Measure security compliance*
Document System Security Profile*
Document Security Requirements and Controls*
Defect Tracking
Regression Testing / Acceptance Test Results
Validated System
Validated System Utilities
Refine Supporting Materials / Technical Writing/ Illustration
On-line Content Development/Content Review / Revised User/Training Materials
Revised Technical Documentation

System Implementation Phase

Processes

/

Techniques

/

Process Deliverables (Outcomes)

Prepare for System for System Implementation / Interviews
Distribution of Materials
Coordination of Training Logistics / Established Team and Environment for System Implementation
Deploy System / Training Sessions
Manual Business Operations
Parallel Operation
Perform System Certification and Accreditation * / Migrated and Initialized Data
Operational System
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 by the new/modified system.
  • 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.
  • 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 ( ADA ( 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.

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 / Relationship Traceability
ID / Requirement Description / Priority / Category / Source / Relates to Business Objective / Manifests in WBS Deliverable or task / Verification / Validation

OR

Requirement Traceability Matrix
Req # / Req. Name / RFP # / WBS task # / TS # / Verification

Req#: Requirement Number; for each project requirement

Req Name: Enter the name and brief description of the requirement

RFP #: Request For Proposal (RFP); specify the identification number of therequirement as listed in the RFP.

WBS task#:List the MS Project Subtask and Task numbers that are associated withthe 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
  • Summary Details
  • Key Project Contacts
  • Key Dates
  • Web Development Standards
  • Information Security Classification
  • Design and Technology Details
  • System Profile
  • Solution Details
  • Guidelines and Best Practices
  • Required Documents
  • Business Requirement Document (BRD)
  • User Community
  • Support & Service Requirements
  • System Availability Required
  • Support and Service Delivery
  • Maintenance Windows
  • Solution Support Groups
  • Solution Stack
  • Operating System
  • Web Server
  • Application Server / Middleware
  • Database Management System
  • Client Device
  • Development Languages
  • Virtualization
  • Directory Services
  • Active Directory Schema
  • Windows Servers Active Directory (AD) Membership
  • Network
  • Application Architecture
  • Description
  • Layers
  • Session Management
  • Open Source, Freeware, and or Shareware
  • Presentation, Business and Data Logic
  • Application Integration
  • External System Dependencies
  • Network Architecture
  • Network Architecture and Design Description
  • Network Diagram
  • Network Enhancements / Changes
  • Environments
  • Communications and Performance
  • Data Flows and Network Protocols
  • Network Traffic
  • Domain Name Services
  • Database Architecture
  • Initial Size of Database
  • Anticipated Annual Growth
  • Database Features
  • Database Environment
  • Database Connection Account Type
  • Stored Procedures
  • Object-Relational Mapping
  • Archive Log Mode
  • Number of Database Instances
  • Clustering
  • Database Normalization
  • Security Architecture
  • Threat Mitigation Plan
  • Application Security
  • User Identification and Authentication
  • Roles
  • Authorization and Access Control
  • Entity Store
  • Account Management
  • Data Segregation
  • Data Integrity
  • Session Management
  • 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
  • Infrastructure and Network Security
  • Network Security
  • Separation of Administrative and User Traffic
  • Operating System Accounts and Privileges
  • Server Hardening
  • Database Security
  • Local User Management
  • Database Logging
  • Database Link Privileges
  • Security and Audit Logs
  • Remote Archiving
  • Cryptography and Key Management
  • Appropriate Use of Encryption
  • Digital Certificate Management
  • Encryption Key Management
  • Pre - Production Environment Security
  • Enterprise Backup and Recovery
  • Backups
  • Schedule
  • Data Retention
  • Disaster Recovery
  • Disaster Recovery
  • Business Continuity
  • System Module Specifications
  • 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
  • Unit Test Plan
  • Integration Test Plan
  • System Test Plan
  • Acceptance Test Plan
  • Performance Testing
  • Performance Profiling
  • Stress Testing
  • Load Testing
  • Regression Test
  • Defect clustering
  • Deployment and Transition Plans
  • Consumer Training and Deployment
  • Data Preparation
  • Backup and Recovery
  • Software Migration
  • Production Start-up
  • Production Verification
  • Application Architecture Diagram
  • Technical Architecture Diagram

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.