Business Analysis Guidebook/Business Analysis Within a Typical System Development Life Cycle

From Wikibooks, open books for an open world
Jump to navigation Jump to search

Business Analysis within typical System Development Life Cycles[edit | edit source]

Introduction[edit | edit source]

This section of the BA Handbook describes the standard phases and major processes of the System Development Lifecycle (SDLC), using a common language and in sufficient detail to provide a Business Analyst an understanding of the system development lifecycle and the expected deliverables for the various phases within a project.

Information Technology Governance Process[edit | edit source]

All software development projects, software enhancements, or software procurements should begin with an Information Technology Investment Request (ITIR), Business Case, and/ or a Project Proposal. These requests then go through an Information Technology Governance process supported by the agency’s Project Management Office (PMO). This process involves an evaluation and approval of the request at either a Division or Departmental level depending on the enterprise impact. IT Governance is the process that agencies use to ensure that IT is applying effort to the right projects and enhancements. The purpose of the process is to align IT investments with strategic goals, operational support, and required maintenance.

Once a proposal has been approved, it is added to the Project Management Portfolio and depending on resources, a Project Manager (PM) or Project Coordinator (PC), and a Business Analyst(s) (BA) are assigned to the project. This phase of the project is called the Origination Phase in the Project Management lifecycle. Software development does not begin in this phase but many of the tools and techniques used in the System Development Lifecycle (SDLC) are essential in the development of Business Cases and Project Proposals.

Roles and Responsibilities[edit | edit source]

The role of BAs on an IT Project can be multi–fold. Project Team roles are described in detail in NYS Project Management Guidebook -Roles and Responsibilities. It is possible for Project Team members to have multiple roles and responsibilities. On some projects, the BA may take on the roles of the Business Intelligence Analyst, Database Designer, Software Quality Assurance Specialist, Tester, and/or Trainer when there are limited resources available. It is also possible that the Project Coordinator, the Application Development Lead, or a Developer take on the role of the Business Analyst on some projects. There are two distinct sets of deliverables that a BA may be responsible for producing, the Project Management Methodology (PMM) deliverables, and the SDLC deliverables. The PMM deliverables may begin at project origination and end at project closeout. The PMM and the SDLC are closely integrated and both sets of deliverables are dependent upon each other. This SDLC begins during the Project Management Initiation Phase after the Business Case, the Project Proposal, the Project Charter, and the Project plan have been developed. This section of the BA Handbook will focus on the SDLC deliverables.

This overall framework for software development is based on the New York State Software Development Lifecycle from Section III of the NYS Project Management Guidebook Release 2 (CIO-OFT) [1]. This SDLC is designed to be generic enough for virtually all system development efforts, and allows utilization of nearly all platforms, tools, and techniques. An overview of the SDLC phases and the different methodologies (workflow patterns) are described below.

System Development Lifecycle Methodologies (Workflow Patterns)[edit | edit source]

There are numerous System Development Lifecycle (SDLC) methodologies to choose from for system development projects. Many methodologies are driven by the application development tools, by the software architecture within which the application will operate, or by the “build versus buy” decision. The four common methodologies that are included in this section are Waterfall, Agile, Iterative, and Incremental. Project Managers select the SDLC methodology that best fits their project based on the project, project environment, project team and project manager attributes.

Waterfall Methodology[edit | edit source]

In the waterfall model, system design is broken down into a number of linear and sequential stages, in which system evolution is seen as flowing progressively downwards, through the phases. The waterfall model has distinct goals for each phase of development. In this development method, each phase must be completed before the succeeding phase can begin. The output from each phase forms the input to the next phase; therefore, each phase has to be accomplished in turn to maintain the linkage between the inputs and outputs. Many software development projects still use the Waterfall methodology. Attributes that would make the Waterfall method the recommended methodology are when formality is called for, when there are disparate stakeholders, or when there are changing resources.

Agile Methodology[edit | edit source]

Agile software development is based on iterative development that advocates a lighter and more people-centric viewpoint than traditional approaches. Requirements solutions evolve through collaboration between the customer and self-organizing project teams. Feedback, rather than planning, is the primary control mechanism. The feedback is driven by regular tests and releases of the evolving software. The frequent inspection and adaptation in the agile method encourages teamwork, self-organization, and accountability. Agile methods allow for rapid delivery of high-quality software and employ a business approach that aligns development with customer needs and agency goals. The Agile methodology matches the need for emerging technologies and development styles as well as quick delivery and decreased overhead.

Iterative Methodology[edit | edit source]

The iterative methodology is an enhanced version of waterfall methodology. As with the classic or linear-sequential life cycle model, iterative also maintains a series of phases that are distinct and cascading in nature. Each phase is dependent on the preceding phase before it can begin and requires a defined set of inputs from the prior phase. More so, a fair amount of time is spent in the analysis phase. After this phase of the project, the requirements are categorized based on their priorities and the target is met in finite deliverables in multiple iterations. Only a limited set of requirements is constructed through to implementation. The process then repeats itself. Each output from any given iteration could potentially serve as an input to the downstream requirements in the new and next requirements phase (for the next iteration). The Iterative methodology delivers a product faster and involves the customer more so they feel that they have contributed to its development and are satisfied more in the end. It would be beneficial particularly to larger in-house development and to some COTS projects.

Incremental Methodology[edit | edit source]

Iterative and Incremental methodologies are similar in that the scope of the project is defined in the charter and both are developed in phases, each phase adding additional functionality to the system. In Incremental development, the Scope, Requirements Analysis, and Design phases are performed sequentially. However, the software features/requirements are divided into multiple, independent groups. The Construction, Acceptance, and Implementation phases are then performed for each group with the resulting system being deployed to production. Each piece of functionality is incrementally delivered. Whereas, Iterative development performs only high level Requirements Analysis initially and chunks out the scope into logical iterations. Each iteration includes a more detailed Requirements Analysis, Design, Construction, Acceptance, and Implementation phase.

Though seemingly similar, the iterative and agile methodologies differ in that requirements could continuously evolve in agile where as in an iterative model, requirements are refined only during the requirement phase of each iteration. Another Iteration of the process is accomplished through implementation with the result being an “Evolved” form of the same software product. This cycle continues with the full functionality “Evolving” overtime as multiple iterations are completed.

In reality, each phase of the SDLC can be thought of as a mini-project in itself, requiring planning, execution, and analysis. As the Project Team proceeds through the project and executes each phase, they will collect additional information that will enable the refinement of subsequent phases. Some of this information will be a natural by-product of having performed the processes associated with the current phase. As the detailed technical design evolves throughout the System Design phase, the team will have a much better understanding of the modules that will need to be built during construction, and will therefore be able to refine any prior estimates and plans for System Construction.

Additional information can be obtained through a focused analysis effort, performed at the completion of each phase. The responsibilities of the Project Team include assessing how closely the phase met Customer needs, highlighting those aspects of the phase that worked well, identifying lessons learned and best practices in an attempt to derive ways to improve upon processes executed throughout the project, and, most importantly, communicating results.

The SDLC Phases described here should be consistently performed even though the order of occurrence of when these activities take place may differ based on the methodology chosen. For a Plan driven methodology like waterfall, the SDLC phases would occur sequentially where as in Change driven methodology like Agile, these could occur simultaneously and repeatedly.

Many factors may influence your choice of approach to follow when developing a system. The better you know your Customers and Stakeholders, and the better you understand the factors that may influence their assessment of the project, the more likely it will be that your approach will suit their personalities, preferences, vision, and needs.

The key is to pick the approach that you believe will provide the best complete solution, balancing the preferences of your Customers, the abilities of your Project Team, and the overall business drivers (legislated timeframes, overall time to market, etc.). In any approach, the basic SDLC processes must be performed. What differs is the timing of their execution. As with the project management methodology, if processes or deliverables are skipped, the Project Team must record the reasons why, and must describe how the objectives of that process/deliverable will otherwise be met.

System Development Lifecycle[edit | edit source]

There are standard phases and processes that all system development projects should follow, regardless of environment, tools or work flow patterns. Every phase of the SDLC should include Information Security considerations. Security discussions should be performed as part of (not separately from) the development project to ensure solid understandings among the project team of business decisions and their risk implications to the overall development project. Security audits/reviews should be performed periodically throughout the systems development life cycle phases and conducted by the Information Security staff, independent of the development staff. Security audits/reviews should assess the status of information security from Origination through all the SDLC phases listed below. This section describes the six standard phases and the major processes of the New York State System Development Lifecycle (SDLC).

System Initiation Phase[edit | edit source]

This phase consists of the following processes:

• Prepare for System Initiation : The project team familiarizes themselves with the Business Case and Proposed Solution developed during the PMM Origination phase.

• Verify Proposed Solution: These documents are re-examined to ensure that they still appropriately define and address an existing organizational need.

To verify the Proposed Solution, the Project Team must:
  • Understand the agency’s current Strategic Plan, and how the new system fits into it i.e. any changes to the system must ultimately align to the strategic vision and goal of the organization;
  • Consider how it fits into the Agency’s application portfolio of existing or Proposed Systems. A System Context Diagram can be used to illustrate how the new/modified system will make use of, or add to, existing data stores. It can depict how the data/system will interface with other systems identified in the Strategic Plan (extract, update, data entry, etc.).
  • Update the stakeholder map.
  • To initially assess and determine all impacted Stakeholders;
  • To identify the right Stakeholders representing each affected Program Area with their authoritative levels for requirements approval;
  • Verify the proposed technology solution in view of Stakeholder needs, the Performing Organization’s long term technology direction, constraints, and state-of-the-art technology;
  • Define assumptions and constraints that could be technical, administrative or regulatory
  • Identify different solution options;
  • Confirm feasibility of the proposed system development approach.

• Determine SDLC Methodology (Work Flow Pattern) and Develop System Schedule: This verification effort provides the Project Team with the basis to determine the SDLC methodology (Work Flow Pattern) that will be used for this project. It will also provide the basis for a detailed schedule defining the steps needed to obtain a thorough understanding of the business requirements and an initial view of resource needs.

• Begin Security Planning:

  • Identifying key security roles for the system development;
  • Identifying sources of security requirements, such as relevant laws, regulations, and standards;
  • Ensuring all key stakeholders have a common understanding, including security implications, considerations, and requirements; and
  • Outlining initial thoughts on key security milestones including time frames or development triggers that signal a security step is approaching.

This early involvement will enable the developers to plan security requirements and associated constraints into the project[2].

At the end of System Initiation, all system-related materials gathered and produced by the Project Team should be consolidated and prepared for use as input for the next phase.

System Requirements Analysis Phase[edit | edit source]

In the System Requirements Phase, the needs of the business are captured in as much detail as possible. The Stakeholders are defined in the Business Case and the Stakeholders Map. The requirements form the basis for all future work on the project. It is important that the Project Team create a complete and accurate representation of all requirements that the system must accommodate. Accurately identified requirements result from effective communication and collaboration among all members of the Project Team and Customers. This provides the best chance of creating a system that fully satisfies the needs of the Customers. The requirements for a system are captured in the Functional requirements, Non-Functional requirements, and Business Rules.

During earlier phases or even during Requirements Phase when the requirements are elicited from the Customers of different Business Units, the Project Team must think about Business Process Re-Engineering. For example, what current processes must be changed or could be changed to do business more effectively. Is there a possibility to automate the process or leave it manual? Is it appropriate to create a single source of data that is being used by different Program Areas to avoid duplicity, maintain data integrity, and so forth?

By obtaining a detailed and comprehensive understanding of the business requirements, the BA can develop the Business Requirements Document (BRD). The BRD consists of the Business Rules, the Functional Requirements, the Non-functional requirements, the Process Model, and the Logical Data Model. In this phase, any applicable non-functional requirements standards that a system must adhere to are also captured and reviewed by appropriate units (such as Information Security Office, Server group, database management unit etc) for compliance. This phase consists of the following processes listed below.

Prepare for System Requirements Analysis[edit | edit source]

In this process, steps are taken to ensure that the project environment and Project Team are adequately prepared to capture and analyze the system requirements. All Project Team members must share a clear and common understanding of the scope of this phase of the project, the Project Schedule, the deliverables to be produced, and their individual responsibilities relating to the creation of these deliverables. In preparing for this phase, Skills, Technical Tools, and Team Assessments are done on the Project Team and the environment in which the team will work.

Regardless of the size of the development effort being undertaken, System Requirements Analysis may place the greatest demand upon Stakeholders in terms of resources and the extent of their required participation. Therefore, the Project Team must ensure that the Stakeholders identified initially are still correct and up to date. Stakeholders not identified lead to missing or erroneous requirements that could have a major set back to the project. As a part of preparing for this phase, the Project Team must make sure that the Stakeholder Map is current. Depending on the methodology chosen for this project (Waterfall, Agile or Iterative identified during the Initiation Phase), it is important for the Project Team to establish some expectations and agreed upon guidelines around communication and its frequency, sign off procedures, and the change control process with the Stakeholders.

Deliverables:

  • Established Team and Environment for Requirements Analysis – set up the project repository, get access to database environments, get software tools loaded if not already.
  • Context Diagram – a graphic design that clarifies the interfaces and boundaries of the project or process at hand. It not only shows the process or project in its context, it also shows the project’s interactions with other systems and users. A Context Diagram shows the system boundaries, external and internal entities that interact with the system, and the relevant information flows between these external and internal entities.
  • Stakeholder Map – a visual diagram that depicts the relationship of Stakeholders to the solution and to one another.
Determine Functional and Non-Functional Requirements[edit | edit source]

In Determine Functional and Non-Functional Requirements, information is gathered from a variety of project participants relating to the vision and scope of the system. There are a number of techniques used to capture the requirements. Depending on the SDLC Methodology used, the agency templates, and agency toolset, the Business Analyst may utilize some of the following techniques and/or tools to help document requirements and ensure that they are not missed. The Business Analyst Tools and Techniques section contains description of some of the techniques available such as: Use Case Modeling, Storyboarding, Functional Decomposition, interviews, joint application design sessions (JAD), Unified Modeling Language (UML), prototyping, data flow diagramming, process modeling, and entity-relationship diagramming.

From this, specific detailed requirements are identified and documented so that they address the stated business need. It is very important that the dependencies and the interrelationships between the requirements be captured. The Requirements Traceability Matrix is crucial in identifying the right ‘order’ of requirements to be executed, and to enable an impact analysis if requirements need to be changed. It is also important that all the applicable business rules be documented separately from the process; they must be clearly written and then reviewed for any conflicts.

Functional Requirements The Functional Requirements specify the full set of functional capabilities needed by the new/modified system. Requirements that define those features of the system that will specifically satisfy a stakeholder need, or with which the Customer will directly interact. Any data or reporting requirements that a system must have will be defined here. The Functional Requirements will evolve throughout this phase of the SDLC as 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.

Functional Requirements Tasks:

  • Identify and describe the program areas that will be affected by the new system.
  • Define in detail the procedures, high-level data requirements, existing reports and documents, roles and responsibilities, and the Stakeholders that will be impacted by the new system.
  • Describe in detail the business rules and data requirements.
  • Conduct a Security Impact Analysis early in the requirements phase and ensure participation with the Information Security representative. Key security activities for this phase include[2]:
  • Initial delineation of business requirements in terms of confidentiality, integrity, and availability;
  • Determination of information categorization and identification of known special handling requirements to transmit, store, or create information such as personally identifiable information; and
  • Determination of any privacy requirements.
  • Describe existing computer systems, data, and existing data/system interfaces.
  • Ensure that all required data elements have been identified in the data analysis.
  • Ensure that the sources and destinations of the data are known.
  • Identify and prioritize any procedural and/or automation changes.
  • Make sure requirements that are identified align to the business goals and objectives.
  • Make sure that the list of Stakeholders identified during initiation phase (who will identify/participate and/or approve requirements, along with their authority and/or influence levels) is up to date. Any new/change in Stakeholders identified during requirements elicitation phase should be updated in the stakeholder map.
  • Identify requirements using MoSCoW analysis – requirements that are MUST haves, SHOULD haves (high priority and should be included in the solution, if possible) and nice to haves but not necessary. A point scale may be used to select a vendor for such requirements. COULD haves are nice to have but not necessary and WON’T represent requirements that the Stakeholders agreed not to be implemented but may be implemented in future.
  • Identify requirements’ attributes such as owner, status, priority, and dependencies. Establish a requirements traceability matrix (RTM).
  • Make sure any ASSUMPTIONS AND/OR CONSTRAINTS regarding business processes, available technologies, solutions, timing, and budgetary restrictions are clearly documented and communicated to all Stakeholders.
  • Once the requirements are captured, VERIFY the requirements for correctness as a quality control check and VALIDATE that they align to the business objectives and goals. Make sure that the requirements are consistent and that there are no conflicting requirements.
  • Requirements can be further categorized into the following functions:
  • Common functions – common features and functions
  • GUI functions – screen layouts and navigational requirements
  • Reporting functions – report characteristics
  • Business functions – impacts the business functions
  • Interface functions – data exchange between the system and others
  • Batch functions – Off hours processing requirements
  • Security functions – authorization, roles and access privileges
  • Once the requirements are validated, make sure that each requirement has a Stakeholder identified for User Acceptance Testing (UAT). This task is an important predecessor to test plans and test cases.

Functional Requirements Deliverables

  • Business Requirements Document (BRD) consisting of:
  • Functional Requirements - A document containing detailed requirements for the system being developed. These requirements define the functional features and capabilities that a system must possess. Be sure that any assumptions and constraints identified during the Business Case are still accurate and up to date.
  • Business Process Model – A model of the current state of the process ("as is" model) or a concept of what the process should become ("to be" model)
  • System Context Diagram - A Context Diagram shows the system boundaries, external and internal entities that interact with the system, and the relevant data flows between these external and internal entities.
  • Flow Diagrams (as-is or to-be) – Diagrams graphically depict the sequence of operations or the movement of data for a business process. One or more of the following flow diagrams are included depending on the complexity of the model.
  • Business process flow
  • Data flow
  • Work flow
  • Business Rules and Data Requirements - Business rules define or constrain some aspect of the business and are used to define data constraints, default values, value ranges, cardinality, data types, calculations, exceptions, required elements and the relational integrity of the data.
  • Data Models: Entity Relationship Diagrams, Entity Descriptions, Class Diagrams
  • Conceptual Model - high level display of the different entities for a business function and how they relate to one another
  • Logical Model - illustrates the specific entities, attributes and relationships involved in a business function and represents all the definitions, characteristics, and relationships of data in a business, technical, or conceptual environment
  • Data Dictionary and Glossary - A collection of detailed information on the data elements, fields, tables and other entities that comprise the data model underlying a database or similar data management system.
  • Stakeholder Map: identifies all Stakeholders affected by the proposed change and their influence/authority level for requirements. This document is developed in the origination phase of the Project Management Methodology (PMM) and is owned by the Project Manager but needs to be updated by the project team as new/changed Stakeholders are identified through out the process.
  • Requirements Traceability Matrix: A table that illustrates logical links between individual functional requirements and other types of system artifacts, including other Functional Requirements, Use Cases/User Stories, Architecture and Design Elements, Code Modules, Test Cases, and Business Rules.

Non-Functional Requirements

The Non-Functional Requirements identify the technical, operational, and transitional requirements of the application as outlined below. In addition to business stakeholders’ non-functional requirements, non-functional agency IT specific standards requirements must also be captured. Agency Application Architect Units (AAU) may already have captured their recommended non-functional standards for their infrastructure. Agency Data Management Units (DMU) may also have recommended standards for implementations of software in their database environment. Both the AAU and DMU standards should be verified that they are still current. Non-functional Stakeholder requirements must be clear and testable.

For COTS Acquisition Requirements Analysis, the Customers and Consumers' needs should be captured in the Non-Functional Requirements document as well as those to satisfy the NYS Policies, Standards, and Guidelines listed below. The specific agency non-functional standards are included in the RFP and are used to define the current agency environment. Both the AAU and DMU standards should be verified that they are still current prior to release of a Request for Proposal (RFP). It is not the intention of the RFP to prescribe the COTS technical solution but only describe the existing infrastructure. It is up to the vendor to describe how their solution will fit into the agency environment and the necessary costs associated with their product to make it work. It is recommended that pre-established structural criteria are not appropriate to handle the highly volatile COTS marketplace. Requirements that may eliminate viable COTS solutions should be avoided.

Technical Requirements

Technical Requirements identify the technical aspects and constraints that must be considered when defining the new system. Considerations may include accessibility needs of Customers and Consumers, whether or not the storage and handling of data must follow specific encryption regulations, or whether the system will operate on internal agency hardware or will be hosted at either an internal or external data center. Areas to be addressed include:

  • NYS Policies, Standards, and Guidelines - This requirements section defines the NYS policies, standards, and guidelines that apply to the system. The State of New York Enterprise IT Policies may be found at the following website: <http://www.its.ny.gov/tables/technologypolicyindex.htm>
  • Accessibility - the degree to which a system is available to as many people as possible. Accessibility can be viewed as the "ability to access" and benefit from some system or entity. Accessibility is often used to focus on people with disabilities or special needs and their right of access.
  • Encryption - whether or not the storage and handling of data must follow specific encryption regulations.
  • Hosting - whether it is required that the system will operate on internal agency hardware or will be hosted at either an internal or external data center.
  • Environment for System Operation and Maintenance – physical environment in which the system must function. Location (indoors, outdoors, residency, main office, etc.), number of locations, temperature and climate constraints, dimension constraints, stability, mobility, safety and durability are some of the factors to consider.
  • Disaster Recovery/ Recoverability/ Business Continuity – addresses the ability to recover from power failures, lost data, system failure, acts of nature or sabotage. Discussion points include criticality of the system, acceptable response time to recover, point of restoration, redundancy and failover plans. Disaster recovery is a subset of business continuity.
  • Archiving/Retention Procedures – defines the process to retain data after it has served its usefulness. Should data be purged from the system? How long should data be saved? Will there be a need to access historical data? How fast do you need to get it?
  • Security Procedures - Security Analysis begins with an identification of the security decision makers, the systems administrator, the “delegated administrators” and the general system users. These authorization levels are defined in detail in the NYS ITS Enterprise Information Security Office (EISO) Security Activities within SDLC Phases (ITS-S13-XXX)[2]. A major consideration during Security Analysis is identification of data restrictions and requirements based on ownership, intellectual property, privacy, confidentiality, and accuracy.
  • Legal, Regulatory, Protection, and Functional Security Requirements are captured and analyzed.
  • Data Integrity – addresses currency of the data, accuracy, referential integrity, calculations, conversions, dependencies, etc.
  • Technology Guidelines, Regulations, and Constraints – procedures and processes that need to be addressed. Industry standards, certifications, coding standards, testing standards and documentation standards, etc.

Operational Requirements

Operational Requirements specify any administrative constraints or expectations that must be supported by the system. These requirements may include system performance expectations, technical infrastructure constraints, security mechanisms that must be followed, the need to regularly archive data, and any mandated audit and control processes. Areas to be addressed include:

  • System Performance and Responsiveness Expectations - Make sure any Stakeholders’ requirements about the expected response times for refresh of screens, data saving, reloading, etc. are clearly captured. Any performance requirements or system availability requirements must be documented along with any Stakeholders’ expectations.
  • System Availability Requirements- when does the system need to be available, daily 7am – 5pm, 24x7, etc., maintenance window, dependencies on other interfaces, restore and reactivate procedures (Recovery Point Objective (RPO), Recovery Time Objective (RTO), etc.
  • Business Continuity - requirements to ensure that critical business functions will be available to customers, suppliers, regulators, and other entities that must have access to those functions. These activities include many daily chores such as project management, system backups, change control, and help desk. Business continuity is not something implemented at the time of a disaster; Business Continuity refers to those activities performed daily to maintain service, consistency, and recoverability.
  • Customers/ Consumers for the System - It is important to know the maximum number of users for the system and the number of concurrent users. Identify if the application will be used internally or externally by field users (i.e. bridge inspectors) or by different external departments (i.e. Thruway, DEC, DMV).
  • Volume of Data - It is important to know the volume of data to be stored, updated, and/or reported on, the frequency of updates, what archiving of data is necessary and anticipated growth per year in data.
  • Fault Tolerance/ Robustness – addresses how the system will respond to data exceptions, system failures and hardware failures.
  • Data Archival/ Retrieval - Retention Period and Archiving Requirements, requirements to retain data after it have served its usefulness. Should data be purged from the system? How long should data be saved? Will there be a need to access historical data? How fast do you need to get it?
  • Audit and Control/ Audit Procedures – addresses the need to trace and log use of the system as to updates in database, operations performed, web page visitors, etc.
  • Software Quality Assurance (SQA) – assurance that the system meets specified requirements and Customer needs and expectations
  • Activities Related to Administration and Maintenance of System/Data – addresses how authorization is assigned and process by which problems are reported and resolved.
  • Compatibility with Other Applications/ Interoperability – need for system to interface with other systems without interfering with the operation of those systems. Web services, transmission protocols, messaging, data exports, data imports, and compatibility are some of the requirements addressed.
  • Configuration Requirements – addresses ease of system to adapt to new functionality without the need to make coding changes.
  • Manageability/ Maintainability Requirements – addresses support logistics, process for reporting incidents, change request process, routine diagnostics, defect tracking, upgrade process and schedule, etc.
  • Scalability - (horizontal, vertical): operational scalability including support for additional users or sites, or higher transaction volumes.
  • Reliability – What is the defect rate or failure rate of the system? What is an acceptable recovery time?
  • Portability – How easy is it to migrate the system to other platforms or operating systems.


Transitional Requirements

Transitional Requirements define the realm of conditions that must be satisfied prior to physically implementing the system in a production environment, or to relegating support responsibilities to the Performing Organization. Data conversion requirements, development, delivery of Consumer training programs and materials fall into this category. Areas to be addressed include:

  • Historical Data Cleansing, Conversion, and Import into the New System – addresses need to convert legacy data into new system.
  • Requirements Associated with Validation of the System Prior to Release – addresses availability of customers for testing, what type of deployment is acceptable (all or piecemeal), customer expectations of system, etc.
  • Roles of Customers/ Consumers of the System– needed to identify training needs, documentation needs, system access, hardware needs, deployment logistics, etc.
  • Expectations for User/Technical Documentation – target audience, format and content, media, etc.
  • Expectations for User/Technical Training and Training Materials - target audience, format and content, media, etc.
  • Mechanics of Physically Deploying/Transitioning the Application – business process changes, big bang or soft rollout, pilot, etc.
  • Required Support Hours and Acceptable Maintenance Windows - when does the system need to be available, daily 7am – 5pm, 24x7, etc., maintenance window, dependencies on other interfaces, etc.
  • Monitoring: Application Level Monitoring must be explicitly requested; otherwise, you just get system and database monitoring.
  • Future Development Considerations:
  • Localizability - ability to make adaptations due to regional differences
  • Modifiability or extensibility - ability to add (unspecified) future functionality
  • Evolvability - support for new capabilities or ability to exploit new technologies
  • Composability - ability to compose systems from plug-and-play components
  • Reusability—ability to (re)use in future systems

Non-Functional Requirements Deliverables:

  • Business Requirements Document (BRD) consisting of:
  • Non-Functional Technical Requirements – A section of the document that captures the technical requirements the system must possess. It identifies technical aspects and constraints that must be considered when defining the new system. Considerations may include accessibility needs of Consumers, whether or not the storage and handling of data must follow specified encryption regulations, whether the system will operate on internal agency hardware, or will be hosted at an internal or external data center.
  • Non-Functional Operational Requirements - A section of the document that captures the operational requirements the system must possess. It specifies any administrative constraints or expectations that must be supported by the system. These requirements may include system performance expectations, technical infrastructure constraints, security mechanisms that must be followed, the need to regularly archive data, and any mandated audit and control processes.
  • Non-Functional Transitional Requirements - A section of the document that captures the transitional requirements the system must possess. It defines the realm of conditions that must be satisfied prior to physically implementing the system in a production environment. This includes the transference of support responsibilities to the Performing Organization. Data conversion requirements, and development and delivery of Consumer training programs and materials fall into this category.
  • Requirements Traceability Matrix: - A table that illustrates logical links between individual non-functional requirements and other types of system artifacts, including other Non-Functional Requirements, Use Cases/User Stories, Architecture and Design Elements, Code Modules, Test Cases, and Business Rules.

Requirements and SDLC Methodologies

There are numerous SDLC Methodologies (Work Flow Patterns). Regardless of the methodology chosen, the goal is to capture requirements as accurately as possible, the level of requirement details differ greatly depending on the stage you are in within a particular methodology.

If you are using Waterfall methodology or acquiring a COTS application, the primary goal of this phase, is to create detailed Functional and Non-Functional Requirements upfront without a need for redefining requirements at a later stage or phase.

Iterative and Incremental methodologies are enhanced versions of Waterfall methodology. As with the linear-sequential life cycle model, Iterative maintains a series of phases that are distinct and cascading in nature. Each phase is dependent on the proceeding phase before it can begin and requires a defined set of inputs from the prior phase. A fair amount of time is spent in the System Requirements Analysis Phase. After this phase of the project, the requirements are categorized based on priorities and a finite set of deliverables in multiple iterations are established. A limited set of requirements are constructed and implemented, and then the process repeats again. Each output from any given iteration potentially serves as the input to the downstream requirements in the next iteration. As in the Waterfall methodology, the requirements are locked down once this phase completes for a given set of requirements. Typically, there is an established and agreed upon change control process, which allows for changes in requirements.

Although Iterative and Agile are similar, they differ in that the requirements in Agile methodology continuously evolve. The left over requirements are given consideration along with the new functionality for the next iteration, which form the product backlog. The requirements in Agile are prioritized and re-prioritized by the product owner(s) before each iteration or sprint. The multiple iterations continue until all functionality has evolved into a complete system. Usually, there is no separate change control process as the high-level requirements captured initially are continuously elaborated.

For a COTS Acquisition, all the Functional and Non-Functional Requirements are captured before a Request for Proposal (RFP) is sent out. The System Requirements Analysis Phase for COTS is similar to the above-mentioned methodologies, such as defining the business need; identifying Stakeholders captured in the Business Case and Stakeholders Map, defining data requirements, and system functionality all need to be documented in the Functional and Non-Functional Requirements.

The following diagram illustrates some representative categories of requirements that the team consider when defining tasks and activities throughout the system development project.

EDIT NOTE: Insert Diagram Figure 3-1 System Requirements Analysis Considerations

Define Process Model[edit | edit source]

Define the Process Model may begin at any time after the Project Team has started collecting specific Functional and Non-Functional Requirements. The resulting Process Model of the system, also often referred to as the “To Be” model, illustrates the system processes as they are envisioned for the new/modified system. Over time, this pictorial top-down representation of the major business processes will be decomposed into manageable functions and sub-functions until no further breakdown is possible. When combined with the detailed set of Functional and Non-Functional Requirements and the supporting Logical Data Model, this Process Model should completely address not only the full list of business needs to be satisfied by the new/modified system, but also the vision for how the new/modified system will provide and support this functionality.

Remembering that much of System Requirements Analysis is iterative, the Project Team must ensure that as requirements are updated as a result of continued efforts to determine Functional and Non-Functional Requirements, the Project Team must also refine the Process Model to accommodate those changes.

The deliverable is a Process Model: A graphical representation of the decomposition of all business processes that interact with the system.

Define Logical Data Model[edit | edit source]

A logical data model captures the data that supports the processes and business rules - it identifying entities and their relationships to other entities, and defining attributes with their business definitions. A Database Designer with the help of a Business Analyst is responsible for designing the logical representation of the data to support the business need. A Data Dictionary and Glossary must be created during development of the Logical Data Model. This will also serve as a reference for a common understanding of business words and meanings for all the Stakeholders. Typically, this model will evolve throughout the iterations of capturing and documenting the Business Requirements. This becomes the foundation of the data repository (or Physical Data Model) and is the basis for the DBA to create the physical database, it is important that the Data Dictionary is clear in its definitions, and that all the data has been modeled appropriately.

Deliverables:

  • Logical Data Model – Diagrams and Data Dictionary that define data elements, their attributes, and logical relationships as they align within a Business Area, with no consideration yet given to how data will be physically stored in actual databases.
  • Data Dictionary - A collection of detailed information on the data elements, fields, tables and other entities that comprise the data model underlying a database or similar data management system
  • 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 application are compiled. If incomplete documentation is available for the existing data, analysis is done to determine the business need of the available data.
  • Data Conversion Requirements – Requirements that are applicable for the data transfer between the existing system and the new system. These requirements are temporary in nature in that once the transition from existing to the new system is complete, they are no longer needed.
  • Archiving and Retention Requirements – Businesses retain documents not only for Business Intelligence purposes but also for compliance requirements. Retention of documents involves systematic archiving, keeping all the different versions, with each one an exact copy of the original document. This is different than “backing up” which may mean only keeping the most recent copy. The intent of back up procedures is for more a disaster-recovery precaution than a document-retention practice.
Reconcile Functional and Non-Functional Requirements with Models[edit | edit source]

At this point in the System Requirements phase, the Project Team ensures that the Process and Logical Data Models accommodate all business rules. An analysis is done to validate and cross-reference all requirements to the Process and Data Models. A walkthrough and review of the Requirements, the Process Model, and/or the Logical Data Model is held with the Stakeholders.

Deliverables:

Validated Functional and Non-Functional Requirements and Models – An updated set of Functional and Non-Functional Requirements, Process and Logical Data Models that have been modified to address any gaps or weaknesses identified during the review of these documents.

System Design[edit | edit source]

In the System Design phase, the Project Team builds upon the work performed during System Requirements Analysis, and results in a translation of the functional and non-functional requirements into a complete technical solution. This solution dictates the technical architecture, standards, specifications, and strategies to be followed throughout the building, testing, and implementation of the system.

This phase consists of the following processes and deliverables:

  • Prepare for System Design, where the existing project repositories are expanded to accommodate the design work products, the technical environment and tools needed to support System Design are established, and training needs of the team members involved in System Design are addressed.
  • Define Technical Architecture, where the foundation and structure of the system are identified in terms of system hardware, system software, and supporting tools, and the strategy is developed for distribution of the various system components across the architecture. This Technical Architecture document is created by the Application Architect with the assistance of the Business Analyst and the Application Development Lead.
  • Define System Standards, where common processes, techniques, tools, and conventions that will be used throughout the project are identified in an attempt to maximize efficiencies and introduce uniformity throughout the system. These standards can be broken down into three categories:
  • Technical Development standards - describe naming conventions, programming techniques, screen formatting conventions, documentation formats, and reusable components. These may be established for all projects in a large data processing/IT shop, or may be developed uniquely for a particular project. In addition, they may be unique to a development team or industry- standard and universally accepted.
  • Configuration Management standards - provide the basis for management of the development of individual software components of the system. These standards ensure that functions such as controlling and tracking changes to the software being developed, along with backup and recovery strategies, are inherent in the development process.
  • Release Management standards - establishing at this point in the lifecycle ensures that the right level of planning occurs surrounding both the initial and subsequent releases of the system to the Customers and Stakeholders. These standards are also necessary for successfully managing migrations of the application to the various testing environments.
  • Create Physical Database, where the actual database to be used by the system is defined, validated, and optimized to ensure the completeness, accuracy, and reliability of the data. The database architect creates the physical database using the physical database model based on the logical model created in the system requirements phase. The business analyst may assist in the design. When designing the database, it is important to accurately estimate anticipated data usage and volumes. Answers to basic questions will help determine the most efficient database schemas, and will enable the team to optimize the database to achieve desired performance.
Sample considerations include:
  • Expectations surrounding the use of the data.
  • The number of users expected to access the data simultaneously during normal usage.
  • Anticipated peak user loads on the system.
  • The need for audit trails.
  • Data retention needs (e.g., is it necessary to save specific details of each record, or is it sufficient for historical purposes to simply maintain summarized data?).
  • Multiple environments may be needed for development, testing, quality assurance, and production of the system
  • Prototype System Components, where various components of the solution may be developed or demonstrated in an attempt to validate preliminary functionality, to better illustrate and confirm the proposed solution, or to demonstrate “proof-of-concept.”
  • Produce Technical Specifications, where the requirements of the system are translated into a series of technical specifications for all components of the system, setting the stage for System Construction. The Business Analyst plays a crucial role in the development of the Technical Specifications document. Designing a complete solution means considering each aspect of the requirements and designing a set of Technical Specifications that supports all dimensions of the project. The Technical Specifications should be detailed enough to provide all of the necessary information to the developer that they should be able to start – and complete – the assignment without any further questions. Some of the numerous aspects included in this document are:
  • Detailed module specs for all system components, whether they are common routines, GUI elements, report and batch functions, or interfaces;
  • The approach for implementing the security strategy (defined in the Technical Architecture) throughout each module of the system;
  • System performance expectations and a strategy for meeting them given anticipated system usage and peak processing loads;
  • Test Plans and Cumulative testing strategies enabling validation of all levels of the application from individual modules through a completely integrated system;
  • A complete data conversion approach addressing the cleansing and loading of historical data as well as population of new data not currently available in any existing system;
  • Documentation and training strategies aligned with the overall application, enabling development of comprehensive training curricula, and supporting materials; and
  • Deployment plans addressing the distribution and transition of the system that can be reviewed with and validated by the Consumers.

Key security activities for this phase include 2:

  • Conduct the risk assessment and use the results to supplement the baseline security controls;
  • Analyze security requirements;
  • Perform functional and security testing;
  • Prepare initial documents for system certification and accreditation; and
  • Design security architecture.

System Construction[edit | edit source]

In the System Construction Phase, the Project Team builds and tests the various modules of the application, including any utilities that will be needed during System Acceptance and System Implementation. As system components are built, they will be tested both individually and in logically related and integrated groupings until a full system test has been performed to validate functionality. The documentation and training materials are also developed by the Business Analyst during this phase.

This phase consists of the following processes:

  • Prepare for System Construction, where the system development and testing environments are established, and where the Project Team is instructed in the processes and tools that will be used throughout this phase.
  • Refine System Standards, where standards established in System Design are enhanced and adjusted as the Project Team becomes more familiar with the project environment, or in response to changes in the strategic or technical direction of the project.
  • Build, Test, and Validate (BTV), where individual system components and utilities are constructed and tested to ensure that they perform to the Functional and Non-Functional Requirements. Data conversion utilities are also written during this phase.
  • Conduct Integration and System Testing, where logically related components of the system are assembled and tested as single units, and a complete end-to-end system test is performed.
  • Produce User and Training Materials, where all User-related documentation and training materials are developed.
  • Produce Technical Documentation, where all materials intended for the Project Team of individuals ultimately responsible for the on-going maintenance and support of the system are created. Some the required documentation identified in the Requirements phase may include the Updated Technical specifications, Integration Plan, Maintenance Manual, Operations Manual, System Administrator Manual, Help Desk Scripts, etc.

System Acceptance[edit | edit source]

In the System Acceptance Phase, the focus of system validation efforts shifts from those team members responsible for developing the application to those who will ultimately use the system in the execution of their daily responsibilities. Typically, these would be the business area stakeholders also indentified initially during Project Initiation Phase. This phase of the SDLC is important because it is the last time that rigorous testing will be performed on the system before it goes into production. It is also very likely the first time that Customer will be able to exercise the application in a near-production environment, which adds a unique perspective to the testing efforts. In addition to confirming that the system meets functional and non functional user expectations, activities are aimed at validating all aspects of data conversion and system deployment.

This phase consists of the following processes:

  • Prepare for System Acceptance, where the system acceptance environment is established, and where the testing team is instructed in the use of processes and tools necessary throughout this phase. Preparation of both the testers and the environment in which they will operate is crucial to the success of this phase. User and training materials must be distributed in advance of this effort, and any training sessions needed to familiarize the testers with the application must be conducted. The User Acceptance Test Plan must be reviewed with the acceptance testing team to ensure a clear understanding of expectations and outcomes during this phase.
  • Validate Data Initialization and Conversion, where the processes and utilities used to populate the system database are tested to confirm that they provide a starting point from which the new system can begin processing. Confirmation before the system begins production that all utilities and processes needed to load data into the system work correctly, and that any data carried forward from another system is migrated completely and accurately is crucial to project success. A comprehensive set of completed test plans identifying all data initialization and conversion tests that were performed, along with the detailed outcomes of these tests, the list of defects identified as a result of these tests, and the results of any subsequent retests. These test results are contained in the Acceptance Test Plan section of the Technical Specifications.
  • Test, Identify, Evaluate, React (TIER), where the system functions and processes undergo a series of exhaustive acceptance tests to validate their performance to specifications, and where examination of test results determines whether the system is ready to begin production.
  • Refine Supporting Materials, where the various materials that support the use, operation, and maintenance of the system are updated to reflect any necessary adjustments resulting from acceptance test results.

Key security activities for this phase include:

  • Integrate the information system into its environment;
  • Plan and conduct system certification activities in synchronization with testing of security controls; and
  • Complete system accreditation activities.

System Implementation[edit | edit source]

The System Acceptance Phase, the final phase of the lifecycle, comprises all activities associated with the deployment of the application. These efforts include training, installation of the system in a production setting, and operational use by the end users. Transition of responsibility of maintenance for the application from the Project Team to the application support team occurs.

This phase consists of the following processes:

  • Prepare for System Implementation, where all steps needed in advance of actually deploying the application are performed, including preparation of both the production environment and the Customer communities.
  • Deploy System, where the full deployment plan, initially developed during System Design and evolved throughout subsequent System Development Lifecycle Phases, is executed and validated.
  • Transition to the Support Team, where responsibility for and ownership of the application are transitioned from the Project Team to the unit in the Support Team that will provide system support and maintenance.

The following diagram illustrates every phase, process, and deliverable in the system development life cycle.

EDIT NOTE: Insert SDLC Chart across different project phases

Software Quality Assurance (SQA)[edit | edit source]

Software quality assurance provides the foundation on which all system development activities should occur so that the highest quality system possible will be delivered. According to the IEEE Standard Glossary of Software Engineering Terminology, quality is defined as the degree to which a system, component, or process meets specified requirements and Customer needs and expectations.

Software Quality Assurance programs should be comprised of three components – quality standards, quality assurance processes, and quality controls.

  • Software Quality Standards define the programming standards, and development/testing standards to be followed throughout the project.
  • Software Quality Assurance Processes define practices and procedures to be used by the Project Team to meet the quality standards, and to provide management with evidence that these procedures are being followed.
  • Software Quality Controls comprise a series of reviews and audits that evaluate deliverables with respect to defined standards and acceptance criteria. These controls include software testing techniques and peer reviews.

SQA efforts must be performed throughout all phases of the project. Ideally, there should be a separation of duty from the team members responsible for delivering the system and those responsible for quality assurance; unfortunately, many agencies do not have the resources to provide an independent unit to perform these tasks. In many instances, these tasks will be performed by the Project Team.

Project Roles and Responsibilities[edit | edit source]

When staffing system development projects, there are a number of roles that should be considered. Team members may be tasked with several roles. The roles identified within the SDLC are representative of those that are typically required in a system development effort and are described in Figure 3-3.

EDIT NOTE: Insert Roles & responsibilities chart here


SDLC at a Glance[edit | edit source]

The following table lists all SDLC phases’ processes, some techniques available for use in executing these processes and process deliverables (outcomes).


EDIT NOTE: Insert SDLC at a glance chart here - incl tools & deliverables

References[edit | edit source]

^ New York State Office for Technology, 2003, The New York State Project Management Guidebook, Release 2, Section III: System Development Life Cycle, http://www.cio.ny.gov/pmmp/guidebook2/index.htm

^ NIST Special Publication 800-64 Revision 2, Security Considerations in the System Development Life Cycle, October 2008