GDMS STRATEGY STUDY PAGE 1 OF 17 Requirements Specification Report <> Prepared by: Release Date: Abstract: This document describes high-level requirements for a system. It provides a detailed description of the functional and informational aspects of the system (doing some specific activity, such as tracking emissions, enforcement, etc.). System scope and objectives are defined, assumptions and constraints are identified, and the interaction and interfaces with the system components and other DEP databases are described. Requirements are needed to state what must be done to ensure a successful system. Organization 1 ________________________________________________________________________________________ Signatory-Title Date Organization 2 ________________________________________________________________________________________ Signatory-Title Date Bureau of Applications Development ________________________________________________________________________________________ Signatory-Bureau of Applications Development (BAD), Bureau Director Date ________________________________________________________________________________________ Signatory-Project Manager Date GDMS STRATEGY STUDY PAGE 2 OF 17 Preface Notes for Preparer: The key deliverable of the Analysis stage is the Requirements Specification Report. This document will focus on defining end user requirements independent of the implementation method. "What" should be enforced rather than "How." The issues identified during the Strategy stage should also be resolved, and the information should be clearly presented to the designers. Items in section 1 , Project Overview mirror those in the Strategy Study. They should not be merely a cut and paste from the earlier document but should reflect further analysis, refinement and reappraisal. Some of the items in the Strategy study will remain valid, others may have changed, still others may be addedGDMS STRATEGY STUDY PAGE 3 OF 17 Table of Contents 1. PROJECT DEFINITION..................................................................................................................................................4 1.1. PROJECT OVERVIEW......................................................................................................................................................4 1.2. OBJECTIVES ...................................................................................................................................................................4 1.2.1. System Objectives.................................................................................................................................................4 1.2.2. Business Objectives..............................................................................................................................................4 1.3. PROJECT ASSUMPTIONS AND CONSTRAINTS.................................................................................................................5 1.3.1. Business Constraints............................................................................................................................................5 1.3.2. Technical Constraints..........................................................................................................................................5 1.4. CRITICAL SUCCESS FACTORS........................................................................................................................................6 1.4.1. Business Critical Success Factors........................................................................................................................6 1.4.2. Technical Critical Success Factors......................................................................................................................6 1.5. PROJECT SCOPE .............................................................................................................................................................7 1.6. REFERENCE DOCUMENTATION.....................................................................................................................................7 2. REQUIREMENTS .............................................................................................................................................................8 2.1. BUSINESS REQUIREMENTS............................................................................................................................................8 2.1.1. Proposed System Architecture.............................................................................................................................8 2.1.2. Functions..............................................................................................................................................................8 2.2. OPERATIONS REQUIREMENTS.......................................................................................................................................9 2.3. TEST REQUIREMENTS..................................................................................................................................................10 2.3.1. Stand-Alone and Link Testing ............................................................................................................................10 2.3.2. Identify Data Sources.........................................................................................................................................10 2.4. PERFORMANCE, INTEGRITY, RECOVERY, AND REGRESSION TESTING.......................................................................10 2.5. PROPOSED SYSTEM ARCHITECTURE...........................................................................................................................10 3. INITIAL STRATEGY .....................................................................................................................................................13 3.1. DELIVERY/INSTALLATION PLAN.................................................................................................................................13 3.2. ACCEPTANCE CRITERIA..............................................................................................................................................13 3.3. TRAINING PLAN...........................................................................................................................................................13 3.4. DATA CONVERSION/LOAD STRATEGY.......................................................................................................................13 4. FORWARD SYSTEM DEVELOPMENT PLAN........................................................................................................14 4.1. DEVELOPMENT APPROACH.........................................................................................................................................14 4.2. DEVELOPMENT PLAN..................................................................................................................................................14 GDMS STRATEGY STUDY PAGE 4 OF 17 1. Project Definition 1.1. Project Overview This section should give a brief summary of the project for executives. It includes a description of the project, the reason the project is being undertaken, who is involved with the project, and the scope of the project. The management summary provides a briefing on the anticipated project and an overview of any issues that may require management action. Include the scope of the strategy study, anticipated number of interviews, anticipated target dates, staffing requirements, and project management and control responsibilities. 1.2. Objectives 1.2.1. System Objectives The system objectives describe what the system must do to support business objectives. • Objective1 • Objective2 • Objective3 etc. 1.2.2. Business Objectives Business objectives include management aims and objectives, performance measures and pertinent issues, and business information needs. Why are we doing the project? What do we expect to accomplish? What is not part of the project? If any of these questions cannot be answered, the project should be re-evaluated. Prioritize goals in an ordered fashion. Measurable objective examples: Reduce paper consumption -Create reports which permits printing of summary information, which will reduce paper consumption by 30%. Provide service -Create data inquiry screens, which will reduce research effort by engineers for required information. Retrieve data quickly and efficiently -Name and address inquiries will not exceed 15 seconds. Reduce workforce -Reduce dependency for lookups via paper documents by 50%. Measure performance -Incorporate manual regional performance guidelines into application. Inform management -Application will provide notices when key performance levels become substandard. Aid decision process -Application will monitor form inventory and provide indicators when stock becomes low. Tie to other source information -Application will be able to accept data via modem from CMIC. Implementation Goals -include Date goals such as operational by beginning of year 2001, allow department to meet Governor's Objective of adopting eCommerce initiatives during his administration GDMS STRATEGY STUDY PAGE 5 OF 17 1.3. Project Assumptions and Constraints Constraints include business and technical boundaries that are relevant to the project and must be taken into account to eliminate any hindrance to the project. These items must be considered in order to meet user expectations of response time, system availability and report processing. 1.3.1. Business Constraints Examples of business constraints include: o Business hours o Staff resources o Financing/budget o Legal obligations o Responsibilities to external items o Scheduled constraints o Deadlines imposed by Legislation/Regulation 1.3.2. Technical Constraints Device characteristics, which should be considered, include disk availability, network throughput and uptime, backup processing and maintenance downtime. Network considerations should be considered if an application performs any database activity across the DEP network to another CPU. Some Network considerations include: Speed of database activity across the network the feasibility of putting part of a database on one machine and one part on another the ability of programs to produce properly coordinated transactions across the network. (For instance, deleting records on one machine while updating records on another machine). The programmer must perform this coordination. Examples of technical constraints include: Hardware Data requirements Response time User usage GDMS STRATEGY STUDY PAGE 6 OF 17 1.4. Critical Success Factors Critical success factors are used to measure the success of the project and identify areas, which must be attended to for success. Critical success factors can be used as identifiable performance indicators. The critical success factors of the project should also be identified to highlight the few key areas where "things must go right" in order for the project to be successful. Failure in any critical success factor area may affect attainment of project goals and ultimately jeopardize the success of the project. Define objectives, critical success factors, and key performance issues and associate these elements to Business Units. 1.4.1. Business Critical Success Factors Critical items include: Knowledgeable sponsor Work flow understood including exceptions Friendly screen layouts Understandable help messages Clear and concise user's guide Training Agreement on or understanding of user requirements Management requirements Two way communication between all parties 1.4.2. Technical Critical Success Factors Critical items include: Quick access to frequently used menu items Time frame requirements Imposed requirements from existing systems Data requirements GDMS STRATEGY STUDY PAGE 7 OF 17 1.5. Project Scope This is a crucial section of this document. The goal here is to clearly and unambiguously define the scope of the application at both management and technical levels. Examples include specific business functions to be automated, the types and numbers of users and their location. This includes what features are to be included and which features are not. Interfaces that may be required with other systems or agencies should also be included. This section provides gross estimates of operation and development efforts. Ensure that the scope is wide enough to make the study meaningful; if major interfaces are omitted the strategy may be so constrained that it has to be redone later with a wider scope. Provide System overview depicting interface with existing systems. 1.6. Reference Documentation (Optional) Site any references which may pertain to the Requirements Specification here. EXAMPLES: Legislative acts Regulations GDMS STRATEGY STUDY PAGE 8 OF 17 2. Requirements Identify existing sources of information. This includes identifying the application procedure utilized to accomplish this task or the current location of data used in this task. Attempt to get volumes, since this data will be used in verifying entity volume. Identify present location of any existing databases or data which will be used for the application and provide a general description of the data conversion requirements. 2.1. Business Requirements 2.1.1. Proposed System Architecture EXAMPLE-XXXXX should be implemented as a client/server application utilizing Oracle client tools and an Oracle database on the host processors. The system should be developed and implemented using the ORACLE RDBMS and supporting application development tools. Interactive screens should be developed using CASE Developer. Reports should be written using any one or combination of "C", COBOL, SQL*Plus, or Discover. Access to the proposed system by regional and remote field offices should be provided through the Department-wide DEC computer network. This system architecture has the following benefits: o Centralized security and access control o Standard database backup and recovery procedures o Department-wide access to XXXX and XXXX support information o A single repository for all XXXX and XXXX support information o Data sharing with other DEP/DCNR applications and databases . 2.1.2. Functions Function Definitions The objective of a function hierarchy is to identify the business functions that will be included in the application system. Function definitions should be non-implementational, i.e. describe only what is done, not how to do it. Complicated functions should be presented as a function hierarchy, showing the decomposition of a complex function into simpler basic sub-functions. through parent-child relationships. Functions eventually become screens, reports, manual processes, and batch programs. Event Definitions Record Event Definitions, including triggering and dependency events, entity usage, and conditions. Classify events as one of the following: o External or Change Event: Any point in the life of an enterprise when, under specified conditions, data is created or changed. It may be identified when an entity is created or deleted, the value of an attribute is changed, or a relationship is connected or disconnected. o Real-Time Event: Any point in the life of an enterprise when, under specified conditions, real-time reaches a predetermined date or time. o System Event: Any point in the life of an enterprise when one or more functions have been completed, and/or triggers the start of another function. . Function Logic Ensure that sufficient function detail has been recorded for each function and event. Include how information flows and what is required. Any system of rules used by the business to decide how to handle awkward cases GDMS STRATEGY STUDY PAGE 9 OF 17 should be identified in the function logic. These could include: decision tables, decision trees, flow charts (not to be confused with data flow diagrams), lookup tables, equations, pseudo code, etc 2.2. Operations Requirements List the business functions to be included in the project. Identify which functions are to be automated and which are manual. A bulleted list or simple hierarchy may suffice at this level. In more complex cases where new business functions are being developed or significantly changed, a Business Process model or Functional Hierarchy Diagram may help to clarify functions and functional relationships. When multiple organizations are involved in the function, identify who does what. Example: The system will include the following functions: • Issuance of Blasters Licenses • New applications for licensing • New licenses • Annual Renewals Related functions that are linked to this project should be explicitly identified along with the nature of the relationship. Identify any automated interfaces between functions in different application systems. Identify interfaces between non-linked systems. Example: When an application is received, the applicant's name needs to be entered into the eFacts system's Client file using the Client screen. Clearly identify related functions that are not included within the scope of this project. Example: While payment of fees is required for issuance of a license, the actual processing of checks and preparation of batch transmittal of revenue forms will not be part of this system. GDMS STRATEGY STUDY PAGE 10 OF 17 2.3. Test Requirements 2.3.1. Stand-Alone and Link Testing To be determined 2.3.2. Identify Data Sources Identify existing sources of information. This includes identifying the application procedure utilized to accomplish this task or the current location of data used in this task. Attempt to get volumes, since this data will be used in verifying entity volume. Identify present location of any existing databases or data which will be used for the application and provide a general description of the data conversion requirements. 2.4. Performance, Integrity, Recovery, and Regression Testing To be determined 2.5. Proposed System Architecture Decide which possible technologies or alternative solutions could be used as a solution to the application. Identify possible alternative solutions, examine the feasibility and reject or defer those that are technically or economically unfeasible. Architecture is a term that is widely and loosely used in the computer industry. Architecture is a term that applies to business practices other than computer systems. An overall Business Architecture is a plan for how that business will operate. System's Architecture is usually a component of the Business Architecture and is a plan for operation of computer systems. A System's Architecture is a plan for the procurement, installation, operation and maintenance of information systems that support the business needs. A System's Architecture can be described in terms of three components: Principles -are statements of the organization's basic philosophies on the use and management of information resources. They serve as a starting point for difficult evaluations and decisions and must be tied to business objectives and priorities. Models -are a visualization of the system. A data flow diagram is a model for visualization of information flow and ERDs are models of data and their relationships. DEP has a Business Information Model and Corporate Data Model that support the Systems Architecture. Standards -for systems include platform, development methods, data definitions and user interfaces. These should be set only for key technologies that are important to the organization. They should be set carefully when the Department is prepared to embrace them. Once defined and implemented, it is very difficult to change a standard. DEP has been working on the development of a System's Architecture for some time through several initiatives including AAP and EL90. Representative components of DEP's System Architecture Principles, Standards, and Models follow. Principles: 1. Systems provide quick and easy exchange of information between organizations consistent with current technology and maintenance of data integrity. 2. Global data is owned and maintained by the Department and is available for use by all applications. Other data that is not global can also be shared but it is owned and maintained by individual Programs and Bureaus. Local and personal data is owned and maintained by individual Programs and Bureaus and is generally not shared. 3. Standard data definitions are defined for global entities. Owners of other shared data are also encouraged to use standard data definitions. GDMS STRATEGY STUDY PAGE 11 OF 17 4. Applications are developed within the guidelines of the Systems Development Methodology (SDM). 5. Applications have a common "look and feel" and user interface. Environment Standards: 1. Platform Standards 2. Windows 2000, Oracle, Microsoft Office 3. DECnet/Ethernet for communications 4. Remote printing 5. Desktop device and network access for everyone who needs access to the system 6. System performance 7. Keypads and desktop devices Development Standards: 1. SDM 2. Oracle CASE*Method and Oracle CASE tools 3. Microsoft Project -Project Management Data Standards: 1. Shared tables 2. Data models (ERD) 3. Access and security 4. Reference codes 5. Validation and integrity 6. Ownership GDMS STRATEGY STUDY PAGE 12 OF 17 Operating Standards: 1. Centralized data backup, recovery and archiving procedures 2. Centralized security and access control 3. Department-wide access to a single source of information Models: 1. Project ERD 2. Project Function hierarchy diagram 3. Various graphic representations of DEP business processes and systems GDMS STRATEGY STUDY PAGE 13 OF 17 3. Initial Strategy 3.1. Delivery/Installation Plan (See attachments.) If, for any reason, the Global Data Management System’s planned implementation date is pushed beyond its scheduled date, users and BAD management will be informed as soon as possible. Since this is an upgrade project coupled with a few user requested modifications to an existing system, the Strategy phase involved careful analysis of the existing forms and reports and the work required to upgrade them. This included running these forms/reports through the automated upgrade process and then assessing what was upgraded automatically to determine the work required for completing a proper upgrade. 3.2. Acceptance Criteria Manpower requirements identify the personnel required to support the time estimates displayed in the Gantt Chart. 3.3. Training Plan Cost estimates identify the estimated cost of the Analysis Stage and subsequent stages of the project. 3.4. Data Conversion/Load Strategy Equipment estimates identify the estimated cost of purchasing the equipment or leasing equipment necessary to compute the Analysis Stage and subsequent stages of the project. 3.5. Cut-Over Plan GDMS STRATEGY STUDY PAGE 14 OF 17 4. Forward System Development Plan 4.1. Development Approach Upon completion of the requirements analysis decisions need to be made about the approach to use in proceeding to subsequent phases of the project. There are two different approaches that can be used for design and development. Decisions about which approach is appropriate for a project can be made utilizing the guidelines under the “Customizing the Methodology to fit the Scale of the Project” section of the SDM. -Program Specifications This is the traditional approach. It is most appropriate for large projects with a large number of programmers. Under this approach detailed program specifications are prepared by the designers for each screen and report. -Prototyping This is a newer approach taking advantage of the speed with which prototypes can be developed and modified using the newer development tools. Under this approach, documentation is prepared identifying what is to be prototyped, but the details of each screen and report are progressively defined through iterative prototyping. The decision on which approach to use needs to be identified in this part of the document and the different tasks and deliverables associated with the chosen approach reflected in the project chart. 4.2. Development Plan The Development plan describes what is involved in the remaining stages, and what the scope of the project entails. The next phase of the project, design, should be specified in detail. Detailed tasks in subsequent phases may not be fully specifiable until the design is completed. They can be outlined at a more general level. Plans for subsequent phases will need to be updated with more accurate figures as the project progresses and more detailed information is discovered. 4.2.1. GANTT CHART The Gantt chart provides a visual outline of the time frame estimated to complete the Design stage in detail and subsequent project stages at a higher level. Quality assurance activities need to be included in the plan. MANPOWER REQUIREMENTS Manpower requirements identifies the personnel required to support the time estimate displayed in the Gantt chart. COST ESTIMATES The Cost estimates identify the estimated costs of the subsequent stages. EQUIPMENT ESTIMATES The Equipment estimates section identifies the estimated cost of purchasing or leasing the equipment necessary to complete the subsequent stages. GDMS STRATEGY STUDY PAGE 15 OF 17 GDMS STRATEGY STUDY PAGE 16 OF 17 Attachments (examples:) <> <> GDMS STRATEGY STUDY PAGE 17 OF 17 Glossary Sample definitions DEP Department of Environmental Protection. GDMS Global Data Management System GUI Graphical User Interface ERD Entity Relationship Diagram

Public Domain

views:397

downloads:77

rating:not rated

reviews:0

posted:1/28/2008

language:English