m3requirementsengineeringinthesdlc20100326-100326083449-phpapp01

iii (CC) Creative Commons Copyright and License © 2010.


Copyright and License Notice This document is licensed under the Creative Commons Attribution 3.0 (United States) open source license. Under the terms of this License, you are free to Share (copy, distribute, and transmit) the work; to Remix (adapt) the work. Under the Following Conditions: Attribution (you must attribute the source of this work). For complete terms of this License, please visit: http://creativecommons.org/licenses/by/3.0/us/legalcode.


Table of Contents

OVERVIEW ................................................................................................................................... 1

PROJECT KICK-OFF MEETING AND ADMINISTRATIVE REQUIREMENTS ............................ 2

REQUIREMENTS AND SYSTEMS ANALYSIS ............................................................................ 2

M3 REQUIREMENTS PROCESS METHODOLOGY .................................................................... 3

PROJECT PLAN ........................................................................................................................... 3

CONFIRM VISION, GOALS AND OBJECTIVES .......................................................................... 5

BUSINESS REQUIREMENTS REFINEMENT/ANALYSIS ........................................................... 5

COMPREHENSIVE ANALYSIS TEAM (CAT) .............................................................................. 6

REQUIREMENTS DEVELOPMENT PLAN (RDP) FACILITATION ACTIVITIES .......................... 7

BUSINESS PROCESS MODELING REFINEMENT/ANALYSIS ................................................ 10

USE CASES AND MODELS ....................................................................................................... 11

FUNCTIONAL REQUIREMENTS REFINEMENT/ANALYSIS .................................................... 12

NON-FUNCTIONAL REQUIREMENTS REFINEMENT/ANALYSIS ........................................... 13

SYSTEM/APPLICATION INTEGRATION ANALYSIS ................................................................ 14

DATA MODELING ...................................................................................................................... 15

REQUIREMENTS VERIFICATION ............................................................................................. 16

REQUIREMENTS PRIORITIZATION / SEQUENCING .............................................................. 17

APPLICATION/NETWORK STANDARDS .................................................................................. 18

SOFTWARE REQUIREMENTS SPECIFICATION ..................................................................... 18

SUPPORT FOR PROGRAM OFFICES ...................................................................................... 17

DOCUMENT METHODOLOGIES AND PROCESSES............................................................... 17

LESSONS LEARNED ................................................................................................................. 18

PROPOSED PROJECT TEAM ................................................................................................... 19

CONCLUSION ............................................................................................................................ 19

APPENDICES ............................................................................................................................. 20

APPENDIX A – PROJECT WORK PLAN ................................................................................... 21

APPENDIX B – VISION, GOALS, AND OBJECTIVE DOCUMENT ............................................ 22

APPENDIX C – BUSINESS REQUIREMENTS AND RULES DOCUMENT ............................... 23

APPENDIX D – PROCESS MODELS ........................................................................................ 27

APPENDIX E – USE CASES AND USE CASE MODEL ............................................................ 29

APPENDIX F – FUNCTIONAL REQUIREMENTS DOCUMENT ................................................ 31

APPENDIX G – NON-FUNCTIONAL REQUIREMENTS DOCUMENT ...................................... 33


APPENDIX H – SYSTEM/APPLICATION INTEGRATION ANALYSIS DOCUMENT ................. 34

APPENDIX I – DATA MODELS .................................................................................................. 35

APPENDIX J – REQUIREMENTS TRACEABILITY MATRIX ..................................................... 36

APPENDIX K – SOFTWARE REQUIREMENTS SPECIFICATION ............................................ 38

APPENDIX L – LESSONS LEARNED (COLLECTION FORM) .................................................. 39

APPENDIX M – LESSONS LEARNED DOCUMENT ................................................................. 40

ABOUT THE AUTHOR ............................................................................................................... 41


Table of Figures

Figure 1 – Project Plan M3 Matrix ................................................................................................. 4 Figure 2 – Vision, Goals, and Objectives Document M3 Matrix .................................................... 5 Figure 3 – Business Requirements & Rules Document M3 Matrix ................................................ 6 Figure 4 – RDP Standard Operating Procedures ......................................................................... 8 Figure 5 – RDP Process Steps M3 Matrix ..................................................................................... 9 Figure 6 – Process Modeling Procedure ..................................................................................... 10 Figure 7 – Business Process Models M3 Matrix .......................................................................... 11 Figure 8 – Use Cases and Models M3 Matrix .............................................................................. 12 Figure 9 – Functional Requirements M3 Matrix ........................................................................... 13 Figure 10 – Non-Functional Requirements M3 Matrix ................................................................. 14 Figure 11 – System/Application Integration Analysis M3 Matrix .................................................. 15 Figure 12 – Data Models M3 Matrix ............................................................................................. 16 Figure 13 – Requirements Verification M3 Matrix ........................................................................ 17 Figure 14 – Prioritized and Sequences Requirements M3 Matrix ............................................... 17 Figure 15 – Software Requirements Specification M3 Matrix ...................................................... 17 Figure 16 – Document Methodologies and Processes M3 Matrix ............................................... 17 Figure 17 – Lessons Learned Document M3 Matrix .................................................................... 18 Figure 18 – Project Close-Out Briefings M3 Matrix ..................................................................... 18 Figure 19 – Project Work Plan (Notional) ................................................................................... 21 Figure 20 – Project Vision, Goals, and Objectives Template ...................................................... 22 Figure 21 – Business Requirements Document Table of Contents (Notional)............................ 23 Figure 22 – Business Requirements Document Template ......................................................... 26 Figure 23 – Current Environment BPMN Example ..................................................................... 28 Figure 24 – Future State BPMN Example ................................................................................... 28 Figure 25 – Use Case Template ................................................................................................. 30 Figure 26 – Functional Requirements Document (FRD) Template ............................................. 32 Figure 27 – Non-Functional Requirements Document Template ................................................ 33 Figure 28 – System/Application Integration Model ..................................................................... 34 Figure 29 – Entity Relationship Diagram (ERD) ......................................................................... 35 Figure 30 – Requirements Traceability Matrix (RTM) Template ................................................. 37 Figure 31 – Software Requirements Specification (SRS) Template ........................................... 38 Figure 32 – Lessons Learned Collection Form ........................................................................... 39 Figure 33 – Lessons Learned (Best Practices) Document Template ......................................... 40

M3 | Requirements Engineering Support for the Software Development Life Cycle

M3 (CC) Creative Commons Copyright and License © 2010. 1 | P a g e

Overview Consistent with a business’s strategy and goals, this model creates a proven process to understand the immediate needs of an aggressive and adaptive approach supporting iterative, incremental, and Agile Software Development. A robust requirements methodology and execution strategy is also integral to the success of the M3 (M-cubed) model. Accordingly, we created a technique relying on proven requirements engineering best practices and lessons learned through experiences with our Federal Health Care customers and projects. The technical approach and methodology specifically draws on our recent work supporting the requirements and decisions for the Captain James A. Lovell Federal Health Care Center (JAL-FHCC), the first Federal Health Care Center. The JAL-FHCC will merge the North Chicago Veterans Affairs Medical Center and the Naval Health Clinic Great Lakes. The FHCC project involved successful collaboration with stakeholders at all levels to develop an aggressive requirements definition and documentation process. Through this partnership, the solutions and ultimately this evolving model are based on processes on accepted by the Government and the best practices within the Software Development Life Cycle (SDLC). The byproduct of this effort is a baselined set of processes and a methodology branded as “M3.” M3 is “Modular,” “Measurable,” and Maturable;” and this interconnected set of processes provide a defined and managed approach in supporting SDLC activities from inception through development. The M3 approach reduces project cost, as users are able to perform conventional tasks and workflow alignments on an abbreviated timeline. This methodology, and the evolving processes, also significantly reduces project risk by embedding proven processes and standards-based criteria consistent with the Software Engineering Institute’s Capability Maturity Model Integration (CMMI®), the Project Management Institute’s Body of Knowledge (PMBOK©), and the International Institute of Business Analysis (IIBA) Business Analysis Body of Knowledge (BABOK®).



Project Kick-Off Meeting and Administrative Requirements Working with multiple-vendor projects and Program Offices involves coordination across various intra-agency offices and highly effective facilitation services. This coordination must occur while also successfully identifying requirements, performing design, creating software solutions, and implementing/deploying those solutions. During a project kick-off, this model outlines a technical approach to all involved parties, including the milestones associated with the proposed methodology for requirements gathering. M3 offers and effective and efficient methodology that facilitates a focus on the business (i.e., functional) and technical requirements in the SDLC. This methodology was developed as a practical model used for the effective high level business requirements gathering and refinement supporting the on-going requirements analysis for the JALFHCC in North Chicago. Stakeholder buy-in to the process at the kick-off is crucial.

Requirements and Systems Analysis M3 is structured to define and translate business requirements into actionable and technical specifications for a successful and optimal solution meeting stakeholder needs. This methodology uses the underlying foundations of the iterative software development methodologies (e.g., Rational Unified Process (RUP), Agile, etc.), combined with a modular (i.e., incremental or SCRUM-oriented) process of analysis and project development from start to finish. A structured, modular approach, enhanced with iterative tasks, optimizes resources. When measured with benchmarked standards (e.g., VA, DoD, Federal, and industry best practices and standards), this approach establishes a sound framework that will mature (i.e., scale) throughout the project’s life cycle. M3 is both functional (including interviews, brainstorming sessions, and other supporting processes) and technical. This approach is supported with a proven track record within the Federal Health Care sector.



M3 Requirements Process Methodology The M3 Process (Modular, Measurable, and Maturable) is the cornerstone of a solid results-oriented requirements methodology. M3 is ultimately a decision support tool that delivers: rapid requirements development; analysis of requirements sequencing; appropriate documentation; development of business process models and use cases; and analysis of business/functional, non-functional, and technology options and solutions. M3 supports customer engagement and decision-making by providing a detailed list of business, functional, non-functional, and technical requirements. These requirements will verify and validate customer wants, needs, and desires balanced with appropriate identification, evaluation, and development criteria. M3 delivers a modularized and logical “building block” means for bringing together all recommendations and decisions into the artifacts detailed in the following recommended list of deliverables. The M3 Process is a results-oriented and performance-measured methodology – incorporating iterative and incremental processes, which will support customers in their stewardship of both projects and processes. M3 is based on experience and tempered with standards-based practices. Paralleling the Agile software development model, M3 complements a rapid and agile interrelated set of business processes to design, develop, or purchase the right information technology solution, at the right time, and on budget. Essential to meeting the rapid solution and requirements needs of customers is a collaborative working relationship with stakeholders and an iterative analysis and incremental documentation development methodology. This methodology will validate and benchmark the process standards and technical/system requirements identified in a Scope of Work document. Project Plan The critical document in managing the requirements and systems analysis phase of a project is the Project Plan. This Plan will provide a comprehensive Work Breakdown Structure (WBS) detailing the M3 methodology applied to the appropriate resources required to meet the needs of our team and stakeholders/customers. The WBS framework appears below and is consistent with best practices identified by the Project Management Institute (PMI®). The first step in the Project Plan is to develop and implement an Integrated Program Schedule (IPS). The IPS will depict the scope of the entire task and communicate how work is delivered in accordance with stakeholder/customer requirements (policies, procedures, and processes). The IPS will serve as the framework for contract planning (including planned start dates, finish dates, effort estimates in hours, durations, and activity dependencies), budgeting, and reporting. It will also identify all activities/tasks,



assigned resources, activities/tasks timelines (critical path dependencies), milestone evaluations, and major elements of subcontracted work. The IPS will be developed in Microsoft Project and will be resource-loaded by labor category, and then baselined after customer review and concurrence. Follow-on reviews shall be held whenever approved contract requirements change or work plans are authorized to be restructured. In these instances, the IPS will be re-baselined. In order to ensure customers are aware of progress at all times, the project schedule shall be updated weekly with actual performance information. This information will include the task percentage complete along with started and finished deliverables. The process of creating the IPS will include the incorporation of WBS information into a Monthly Performance Reporting process. M3 embeds a commitment to keeping all stakeholders up-to-date on project progress by ensuring the delivery of a quality product that meets customer expectations, within schedule and budget, will be upheld throughout the period of performance. Figure 1 (Project Plan M3 Matrix) below introduces the M3 methodology as a Project Controls Management tool across the project planning process. The matrix consists of the four core process areas:

1. Project Management 2. Business Analysis 3. Technical Analysis 4. Quality Assurance

Each core process area is measured by a metric agreeable to the customer and the project team. The metrics are not generic; rather metrics are tailored to each project derived from industry standards. Collectively these “metric cubes” become a powerful management and project controls tool ensuring alignment with project scope, goals, and the customer’s requirements.

PROCESS METRIC PROJECT MANAGEMENT PMI® standards based on Cost, Schedule, and Quality.

BUSINESS ANALYSIS International Institute of Business Analysis (IIBA) Business Analysis Body of Knowledge (BABOK®) will be the starting point to shape appropriate and applicable metrics for business analysis.

TECHNICAL ANALYSIS Institute of Electrical and Electronics Engineers (IEEE) and other applicable Standards Developing Organization’s technical specifications.

QUALITY ASSURANCE (QA) / RISK MANAGEMENT

CMMI® for Services (CMMI-SVC) is the benchmark set of processes measuring the delivery of quality and consistent services and products.

Figure 1 – Project Plan M3 Matrix



Confirm Vision, Goals and Objectives Regardless of a project’s size or scope, documenting the vision, goals, and objectives provides the foundation to understand the business drivers supported by any information technological solution – and the solution is not always technological. Leveraging existing documentation (e.g., proposal/purpose) and stakeholder acceptance, the project team shall accurately document the Vision, Goals, and Objectives. Key to establishing the project’s goal is working collaboratively and collectively with multiple levels of stakeholders – from business (or process) owners to end users. Beginning with a common awareness and shared sense of vision, goals, and objectives, the M3 processes ensure successful project outcomes.




QA / RISK MANAGEMENT CMMI® for Services (CMMI-SVC) is the benchmark set of processes measuring the delivery of quality and consistent services and products.

Figure 2 – Vision, Goals, and Objectives Document M3 Matrix Business Requirements Refinement/Analysis Requirements are the lifeline of all information technology projects. From elicitation through delivery of either a developed or Commercial-off-the-Shelf (COTS) solution, ensuring the project’s requirements are managed appropriately is critical. A conventional requirements management framework follows the processes of elicitation, prioritization, validation, and testing/acceptance. M3 provides an interwoven mechanism supporting requirements traceability and accountability from a project’s beginning through closure – and all points in between. Although the quality and continuous process improvement aspects of M3 support a robust and agile requirements engineering environment, the Modular dimension of the methodology highlights an iterative and incremental approach to requirements. In the detailed processes below, the initial goal is to lock down accurate and validated requirements as quickly as possible. This will include, at a minimum:



1. Defining requirements 2. Analyzing and prioritizing requirements 3. Documenting requirements 4. Validating requirements

PROCESS METRIC

PROJECT MANAGEMENT PMI® standards based on Cost, Schedule, and Quality.




Figure 3 – Business Requirements & Rules Document M3 Matrix Comprehensive Analysis Team (CAT) Business Requirements Refinement and Analysis requires a systematic approach. A subset of the project team shall be organized into a Comprehensive Analysis Team (CAT). The CAT will focus on identifying: the policies that drive the business and services performed; the data that is used and defined in the actions or as a result of the actions; and the outcome goals of the actions themselves. To realize this series of tasks, multiple strategies may be employed, such as brainstorming, key stakeholder and Subject Matter Expert (SME) interviews, Appreciative Inquiry (AI) workshops, and other industry standard practices required to rapidly identify and collect the business needs from the various stakeholder groups. These groups include local, department or enterprise offices, and the appropriate information technology stakeholders. A Communications Plan – consisting of all “information sharing” tools used by the project team and all stakeholders – will ensure the success of the “business analysis” phase of the project. The CAT consists of a Senior Technical or Senior Business Lead, Senior Business Process Re-engineering (BPR) Specialist/BPR Specialist, SME/Business Analyst, and a Documentation Specialist (tool operator). This team, or any subset, will provide direct support to customer(s) and stakeholders. It is an assumption that customers will provide access to, and/or appoint, representatives knowledgeable in the Business Function under analysis to support requirements gathering efforts.



Requirements Development Plan (RDP) Facilitation Activities The following plan extracted from an RDP template documents the activities of the CAT. These are the means to refine, develop, and prioritize requirements throughout the project:

RDP: Standard Operating Procedure (SOP) Description SOP A: Prepare the Kick-Off Package – Procedures and responsibilities for developing Business Function kick-off and related Business Area baseline packages. SOP B: Develop Process Models Standard – Procedures and responsibilities for documenting “As-is” and “Best Practices” process activities. SOP C: Identify and Review References Standard – Procedures and responsibilities for identifying, reviewing, and documenting references to recognize current business practices. SOP D: Developing and Defining Business Rules Standard – Procedures and responsibilities for developing and defining business rules and constraints. SOP E: Identify and Document SWOT – Methodology for identifying and documenting Strengths, Weaknesses, Opportunities, and Threats (SWOT). SOP F: Identify BPR/Business Process Improvement (BPI) Objectives – Procedures and responsibilities for developing the overarching goals to identify the applicable major improvements the proposed solution will achieve. SOP G: Develop BPR/BPI Recommendations – Procedures and responsibilities for the CAT and stakeholders to document legislative, policy, and/or procedures necessary to support policy decisions. SOP H: Plan and Conduct a Workshop/Interview – Procedures and responsibilities for planning, organizing, executing, and documenting workshops/interviews. SOP I: Develop the Data Model – Standard procedures and responsibilities for developing a normalized data model that satisfies a business need. SOP J: Analyze and Reengineer Forms – Responsibilities, and procedures for the development and approval of the Forms Analysis and Reengineering process. SOP K: Identify Information Exchange Requirements – Standard procedures and responsibilities for identifying and documenting Information Exchange Requirements. SOP L: Provide Administrative/Technical Support – General guidelines for conducting meetings and visits to ensure understanding and consistent execution. SOP M: Conduct Interim Technical Reviews (ITR) – Responsibilities and procedures for conducting ITRs to provide a more detailed requirements artifact. SOP N: Integrate Business Function and Task Analysis Artifacts – Procedures and responsibilities for incorporating the individual functional task artifacts into the Business Function, ensuring consistency in the artifacts produced. SOP O: Encyclopedia Management – Standard procedures and responsibilities for managing a master dictionary or glossary of terms. SOP P: Documenting and Maintaining Information Requirements – Standard guidance for creating, linking, and updating Information Requirements.



SOP Q: Assemble Business Function Deliverable – Artifacts, and production procedures to be included in the Business Function Packages. SOP R: Define Scope – Procedures and responsibilities for defining the scope of Business Functions, Business Areas, and Tasks. SOP S: Measure Performance – Standard procedures and responsibilities for capturing and using process metrics.

Figure 4 – RDP Standard Operating Procedures In order to develop consistent, cohesive, and quality functional requirements for a Business Function and systems engineering process, a process must be in place to ensure collaboration occurs between all teams. The following matrix maps RDP processes to the M3 framework and the applicable SOP. This matrix delineates the level of coordination to achieve the goal of delivering a quality product and world-class services. M3 RDP Process SOP Reference

Mod

ular

• Conduct Pre-Workshop Activities • Complete Task Analysis Teams’ handoff packages • Refine Business Function scope and definition • Analyze current environment • Create “As-is” process model • Create “As-is” core business rules and requirements • Capture assessments for interagency “To-be” model • Review Business Function • Validate “As-is” environment

SOP R SOP A SOP H SOP L SOP C SOP E SOP B SOP P SOP S

Mea

sura

ble

• Conduct Pre-Workshop Activities • Complete Task Analysis Teams’ handoff packages • Refine Business Function scope and definition • Analyze future environment • Create “To-be” process model • Create “To-be” core business rules and requirements • Capture assessments for “Best Practices” model • Review interagency Business Function • Validate “To-be” environment

SOP M SOP A SOP L SOP F SOP E SOP B SOP K SOP P SOP S

Step

s St

eps



M3 RDP Process SOP Reference M

atur

able

• Conduct Pre-Workshop Activities • Complete Task Analysis Teams’ handoff packages • Refine Business Function scope and definition • Create interagency “Best Practices” process model • Create interagency “Best Practices” core business rules

and information requirements • Document BPR/BPI recommendations • Document BPR/BPI benefits • Deliver high level business requirements for RCS

SOP M SOP A SOP L SOP N SOP O SOP G SOP Q SOP S

Figure 5 – RDP Process Steps M3 Matrix Each CAT will utilize the M3 methodology with the objective of documenting the manner in which customer(s) currently conduct business. Throughout the process of conducting workshops and interviews, the project team will validate and document business requirements, functional requirements, and non-functional requirements. In collaboration with the stakeholders and customers, the project team shall draft recommendations for specific Business Functions and processes arising from the interviews and workshops with end users, identified SMEs, and business owners. This requirements process methodology directly aligns to the M3 framework and will support the customer from decision to implementation, or development, as appropriate. In conducting the requirements and systems analysis, the project team, in cooperation with stakeholder/customer partners, will develop and produce the Business Requirements Document and the Business Rules Document. These artifacts will describe the specific business needs and requirements at a high level. They will also provide an actionable stepping stone in the decision support process. With requirements defined, analysis of the requirements begins. Requirements analysis consists of verifying and validating the requirements in an iterative process with stakeholders before progressing to the next Modular stage. The final stage in validating business requirements will be to establish a Requirements Traceability Matrix (RTM). Parallel to the process of finalizing the business requirements, the project team works with SMEs (business and technical) to begin crafting the business rules. Derived from the business requirements, the business rules will consolidate the operational and execution framework for the final deliverable (Software Requirements Specification). With proven successes in rapidly defining, documenting, and validating business requirements, M3 empowers the project team in the ability to move quickly through the requirements “business analysis” phase of the project.

Step

s



Business Process Modeling Refinement/Analysis

Providing an abstract model of business processes – both those already existing and those required – is integral to completing the business requirements and appropriate artifacts. Following accepted documentation practices, the Business Process Modeling Notation (BPMN) visualizes representations of business processes. These Business Process Models will provide a clear and accurate “picture” of current processes that may include high-level overviews down to detailed micro-level tasks and actions within a business process. The project team shall produce a current environment (“As-is”) set of functional Business Process Models. The current environment models will provide a detailed functional description of existing business processes according to the principles of BPMN. All models will be verified and validated as current and accurate by the customers, stakeholders, and appropriate SMEs. Business process modeling will continue through an iterative process until accepted by the customer as valid and final.

Figure 6 – Process Modeling Procedure

•Refine Business Function Scope

•Identify Customerdriven objective

•Build Cross functionalTeam CAT

•Benchmark current processes

•Design To‐Be process model

•Validate To‐Be processes

•Perform Trade‐off Analysis

•Document “Best Practices”

•Document BPR/BPI Recommendations

•Document High‐Level Business Requirements

•Conduct Workshops or Interviews

•Create Activity Models

•Create ProcessModels

• Identify value addingProcesses

Design To‐Be Processes

Map & Analyze As‐Is Process

Prepare for Analysis

Document CollaborativeResults



Applying the M3 methodology, the project team will filter the business requirements for the project through the current environment Business Process Models to arrive at a draft version of the future state (“To-be”) models. The future state Business Process Models build on the acceptance of the requirements and the current environment models. This process shortens the iterations needed to develop accepted business process models. The final business process models will be compliant with BPMN, v2.0. They will be consistent with the Unified Modeling Language (UML) or Systems Modeling Language (SysML) required for entry into many requirements management tools (e.g., the Dynamic Object-Oriented Requirements System (DOORS), Rational RequisitePro, etc.).




QA / RISK MANAGEMENT

CMMI® for Services (CMMI-SVC) is the benchmark set of processes measuring the delivery of quality and consistent services and products.

Figure 7 – Business Process Models M3 Matrix

Use Cases and Models The M3 methodology is a “building block” process, progressing from requirements and modeling to use cases and appropriate context diagrams or models. Using the framework of the tasks decomposed to an appropriate level of detail, the project team shall generate an initial draft Use Case Model Document, derived from the future state Business Process Models. Future state models and use cases will capture approximately 80% of the basic flow processes and tasks required to complete the Use Case Model. In an iterative manner, the project team shall review the draft Use Case Model with business SMEs and stakeholders. The review will identify all actors and will provide a graphical representation of the functionalities provided by the System under Discussion. The representation will illustrate actors, goals, and any related dependencies between use cases (i.e., different actions or processes between actors and goals). Additionally, the project team shall capture appropriate alternative flows or extensions to Business Process Models and/or Use Cases (i.e., how the processes can happen differently). This modular and modulating (incremental and iterative)



process ensures traceability and repeatability throughout the M3 process and beyond. The process reflects the many lessons learned using similar methodologies in health care and other Government projects. Moreover, the Modular and Measurable approach ensures the capability to trace business functions from end users and enterprise stakeholders throughout the evolution of requirements and associated artifacts.





Figure 8 – Use Cases and Models M3 Matrix Functional Requirements Refinement/Analysis The project team shall decompose the features and functions identified in the Business Requirements Document, and the Business Rules Document, to provide a more detailed or “granular” analysis of functional requirements. The functional requirements include, but are not limited to:

1. Features 2. Functions 3. Technical specifications 4. System(s) parameters 5. System(s) constraints 6. Appropriate algorithm or data processing specifications

The resulting analysis document of functional requirements (Functional Requirements Document) creates the critical link between business needs/requirements and the technical solution. To ensure continuity and traceability of the dependencies exposed in the analysis of functional requirements, the RTM acts as the initial filter to validate functional requirements through a “map and gap” approach. Once the functional requirements are mapped to existing business requirements on the RTM, the project team shall verify and validate all functional requirements with appropriate stakeholders



and SMEs. This validation will include a review of standards and compliance to ensure compatibility with existing and proposed architectures.





Figure 9 – Functional Requirements M3 Matrix Non-Functional Requirements Refinement/Analysis The project team shall research, define, and document all non-functional requirements required. The non-functional requirements include, but are not limited to:

1. Interface(s), human processes and systems 2. Audit and Regulatory requirements (including Medical-Legal) 3. Operational requirements (system behavior and attributes) 4. Information Assurance requirements (privacy and information security) 5. Quality Assurance 6. Patient Safety 7. Training and Implementation Assumptions

Non-functional requirements will be reviewed, validated, and verified in the same M3 process as the business requirements. These include the “system execution” and “system evolution” qualities, such as usability, maintainability, and scalability. Non-functional requirements include those items listed in “Application/Network Standards.”



PROCESS METRIC





Figure 10 – Non-Functional Requirements M3 Matrix System/Application Integration Analysis The project team shall review and document all potential interfacing systems. The analysis of these interfacing systems within the M3 methodology provides a recommendation of those functions that should migrate to the System under Discussion and/or those functions or features that do not require a technical or electronic solution. The System/Application Integration Analysis shall include a similar review as the functional and non-functional requirements with verification and validation from business and technical SMEs. The Integration Analysis builds on the business needs and requirements documented previously. Known potential interfacing systems include, but are not limited to:

• Data Connections (internal and external facing) • Health Information Exchanges (HIE) • Nationwide Health Information Network (NHIN)

These systems include Web Services Description Language (WSDL) and/or other messaging services that may interface with the System under Discussion (e.g., Health Level 7 (HL7), Simple Object Access Protocol (SOAP), etc.).



PROCESS METRIC





Figure 11 – System/Application Integration Analysis M3 Matrix Data Modeling The M3 methodology provides the needed incremental (Modular) approach to derive data models (conceptual and logical) based on the Business Requirements Document, Use Case Model, extension of the functional and non-functional requirements artifacts, and the creation of an Activity Model. The Activity Model provides the framework necessary to understand the relationship between different data entities within the System under Discussion and interfacing systems, including functional and technical processes. The Conceptual Data Model will be delivered in a UML-compliant format as an Entity Relationship Diagram (ERD) visualizing the construct of the proposed solution. The Logical Data Model will detail the semantics of the structure of the overall data model visually as an ERD that includes all entities, relationships, and significant attributes normalized to the third normal form (3NF). Furthering this effort, the project team shall develop data models in concert with the more business-oriented requirements gathering process, leveraging the experience and expertise of functional and technical SMEs in applying the M3 methodology. This iterative and Modular approach shortens modeling and model development time as an element embedded within the overall Project Plan.



PROCESS METRIC





Figure 12 – Data Models M3 Matrix Requirements Verification The project team shall work with the business owners and key stakeholders to verify that all requirements are clear, understood, agreed upon, and well written. Requirements shall be complete, correct, attainable, feasible, necessary, testable, measurable, unambiguous, and traceable. Requirements verification and validation shall ensure all business, functional, non-functional, and technical requirements are correct. The M3 methodology verifies requirements at specific intervals during requirements development, documentation, and final reviews. Additionally, M3 includes both formal and informal requirements reviews. Informal requirements verification will take place during collection and assembly of all requirements and associated artifacts. Formal requirements verification will take place during the documentation review and approval processes (e.g., BRD, Business Process Models, Use Cases and Models, and finally the System Requirements Specification Documents). Functional test cases and user acceptance criteria derived from all requirements will validate appropriateness and ensure the solution will meet end-user needs, as articulated in the BRD.



PROCESS METRIC





Figure 13 – Requirements Verification M3 Matrix Requirements Prioritization / Sequencing The project team shall conduct interviews, workshops, and/or conferences to support prioritizing and sequencing all identified requirements. From the project’s beginning (documenting Business Requirements) through the acceptance of the Business Process Models and the Data Models, our team will develop a Requirements Prioritization/Sequencing artifact detailing the business and technical logic supporting a prioritized set of requirements. This artifact may be embedded within the Business Requirements Document and shall include, but is not limited to: initial delivery of core functionalities through the System under Discussion; a sequenced set of functionalities beyond initial delivery; and impact assessment statement and/or legacy system(s) enhancements.





Figure 14 – Prioritized and Sequences Requirements M3 Matrix



Application/Network Standards The project team shall document all applicable Federal, Agency application, infrastructure, and network standards pertinent to the System under Discussion. These standards will be identified and validated by the appropriate SMEs from the customer’s business owner office, information and technology office, and enterprise architecture (as applicable). Additionally, all Application/Network Standards will be vetted against industry best practices and standards (e.g., Nationwide Health Information Network). Software Requirements Specification The Software Requirements Specification and Decision Support will conclude with the delivery of a Software Requirements Specification (SRS) artifact to the customer. In accordance with the M3 methodology, the SRS document builds on and leverages all work previously completed – from beginning to end. The project team shall deliver on time, according to the WBS, a verified and validated SRS reviewed by functional and technical SMEs and stakeholders/customer representatives. The SRS will comply with best practices in the Software Development Life Cycle and with formatting guidance provided by the customer, or applied by the project team. In “building block” fashion, the SRS begins with the creation of the first artifacts and embodies the “blocks” of the business requirements, business process models, functional and non-functional requirements, and the data models. Not simply a “synthesizing” document, the SRS will be the stand-alone artifact supporting completion of the requirements engineering processes. The SRS will consist of the following, at a minimum:

• Vision, Goals, and Objectives • High Level Business Requirements, Assumptions, Constraints, Stakeholders,

and End-Users • Business Requirements • Business Process Models • Use Case Model • Detailed Functional Requirements • Detailed System/Application Integration Requirements • Data Models (Conceptual and Logical) • Requirements Traceability Matrix (RTM)







Figure 15 – Software Requirements Specification M3 Matrix

Support for Program Offices The project team stands ready to support the customer’s Program Office in developing a requirements specification framework and process. We will work closely with the customer and stakeholders to ensure that all recommendations and decisions shall support the customer’s guidance and directions – and align with customer business goals.

Document Methodologies and Processes The project team shall provide comprehensive documentation of applied methodologies and processes. The M3 methodology, aligned with the RDP processes, will adapt to meet the needs and unique requirements of the project. The M3 method provides a built-in means of documenting the project’s progression, as each artifact contributes to the next layer or level of the project. The end result is supported by a Project Plan and Communications Plan that will guide and direct the storage of each artifact or document throughout the project’s life cycle.





Figure 16 – Document Methodologies and Processes M3 Matrix



Lessons Learned The project team shall collect and evaluate lessons learned and best practices throughout the project’s life cycle, as a vital element of the M3 methodology. These lessons learned will be incorporated into the project, and once integrated into the Project Plan provide the necessary Modular, Measurable, and Maturable mechanisms to make critical adjustments as needed. Additionally, the project team shall make available to the customer a final copy of lessons learned, formatted according to the appropriate standards. This process will be documented and monitored both in the WBS and in the Communications Plan – both monitored through the project’s Project Plan.





Figure 17 – Lessons Learned Document M3 Matrix Supporting the Lessons Learned Document, the project team shall prepare the appropriate project end briefings and updates for the customer, as requested. The final project “out-briefs” will be tracked and monitored through the WBS, Communications Plan, and the project’s Project Plan.





Figure 18 – Project Close-Out Briefings M3 Matrix



Proposed Project Team

The project team shall be composed of management, functional, technical, and support resources with a track record of successful program execution within the appropriate business space (e.g., Federal Health Care). These resource types offer the requisite skills to ensure the timely and successful achievement of this project and to bring technology to bear rapidly in support of the customer’s goals and objectives. Conclusion

Requirements engineering and analysis is an evolving field, and increasingly more automated each year. Requirements management systems are more sophisticated and will accomplish many (if not all) of the individual tasks described in this article – from the modularity, the measurability, and the maturability of each phase. Why M3, or similar more manual methods? Familiarization with the requirements process “from soup to nuts” benefits new practitioners as well as seasoned pros. Requirements tools are wonderful and simplify many of the elements discussed; understanding what that tool is doing, why, and how benefits the requirements analyst or engineer.

According to a 2005 IEEE blog article, “Why Software Fails,”1 there are twelve sources of failed software projects. Of these sources, six (or seven) point to requirements analysis and documentation. No single cause or sphere of an IT project is an ultimate culprit. There are typically many factors and elements contributing to failing and failed projects. Communicating with the stakeholders and end-users is a proven best practice to improve the odds of project success. M3 is a consistent methodology delivering modular milestones, with measurable results, and is highly scalable to meet the needs of small and large projects.

1 Robert N. Charette, “Why Software Fails,” IEEE Spectrum (September 2005). http://spectrum.ieee.org/computing/software/why-software-fails/0.



Appendices

The appendices provide sample templates and examples of work products referenced in the M3 model and methodology.

Appendix A – Project Work Plan: provides the project roadmap, incorporating the Work Breakdown Structure (WBS).

Appendix B – Vision, Goals, and Objective Document: documents the approved vision, goals, and objectives for the project; this may be included within a separate Project Charter document.

Appendix C – Business Requirements and Rules Document: documents the business (functional) needs and requirements for the project; included within this document are the business or environmental rules providing the governance framework for the system.

Appendix D – Process Models: the business process models visually document the current and future business processes.

Appendix E – Use Cases and Use Case Model: use cases provide a narrative description of the future state business processes; the Use Case Model may be a visual representation of use cases or a “Context Diagram” explaining the user and system environments.

Appendix F – Functional Requirements Document: this document adapts the business requirements into a more technical language to provide testable functional requirements statements.

Appendix G – Non-Functional Requirements Document: this document adapts the business requirements into a more technical language specifying the characteristics or attributes of the system.

Appendix H – System/Application Integration Analysis Document: this document provides the analysis for the operational context of the system/application and all interfacing systems.

Appendix I – Data Models: Data Models include the Activity Model, the Conceptual Data Model, and the Logical Data Model.

Appendix J – Requirements Traceability Matrix: the Requirements Traceability Matrix provides a tool to associate, monitor, and validate requirements (functional and non-functional) from elicitation through testing and implementation.

Appendix K – Software Requirements Specification: the “capstone” document of the requirements process, the Software Requirements Specification provides a detailed and technical description of the system.

Appendix L – Lessons Learned (collection form): this collection form is a sample used to submit individual lessons learned throughout a project’s life cycle.

Appendix M – Lessons Learned Document: Integral to the M3 method (and continuous process improvement), this document captures and provides meaningful best practices to the team and all project stakeholders.



Appendix A – Project Work Plan

WBS-Task Description Duration Start Date

End Date Resources

Task 1 Project Kick-Off Meeting and Administrative Requirements 25 days PM

Deliverable 1.1 Kick-Off Meeting 10 days PM Deliverable 1.2 Team Roster provided to Contracting Officer (CO) 5 days PM

Deliverable 1.3 Team Roster provided to the CO’s Technical Representative (COTR) 5 days PM

Deliverable 1.4 Complete and document mandatory training 20 days PM Deliverable 1.5 Signed Business Associate Agreement 5 days PM Task 2 Requirements and Systems Analysis 270 days Varies Subtask 2.1 Project Plan 30 days PM Deliverable 2.1 Project Plan 30 days PM Subtask 2.2 Confirm Vision, Goals, and Objectives 30 days CAT Deliverable 2.2 Vision, Goals, and Objectives Document 30 days CAT Subtask 2.3 Business Requirements Refinement/Analysis 90 days CAT Deliverable 2.3 Business Requirements and Rules Document 60 days CAT Subtask 2.4 Process Modeling Refinement/Analysis 90 days CAT Deliverable 2.4 Process Models (“As-is”, “To-be”) 90 days CAT Subtask 2.5 Use Cases and Models 150 days CAT Deliverable 2.5 Use Cases and Models 150 days CAT Subtask 2.6 Functional Requirements Refinement/Analysis 30 days CAT Deliverable 2.6 Detailed Functional Requirements Document 15 days CAT Subtask 2.7 Non-Functional Requirements Refinement/Analysis 10 days CAT Deliverable 2.7 Non-Functional Requirements Document 5 days CAT Subtask 2.8 System/Application Integration Analysis 2 days CAT Deliverable 2.8 System/Application Integration Analysis Document 5 days CAT Subtask 2.9 Data Modeling 30 days CAT Deliverable 2.9 Data Models (Conceptual and Logical) 10 days CAT Subtask 2.10 Requirements Verification 30 days CAT Deliverable 2.10 Prioritized and Sequenced Set of Requirements 10 days CAT Subtask 2.11 Requirements Prioritization / Sequencing 10 days CAT Subtask 2.12 Application/Network Standards 1 day CAT Subtask 2.13 Software Requirements Specification (SRS) 5 days CAT Deliverable 2.11 Software Requirement Specification (SRS) 5 days CAT Task 3 Support for Program Office 270 days Varies

Subtask 3.1 Document methodologies and processes used to capture requirements specifications 270 days PM/CAT

Deliverable 3.1 Overview of requirements specification methodologies and processes 2 days PM/CAT

Subtask 3.2 Capture and communicate lessons learned related to requirements definition processes 270 days PM/CAT

Deliverable 3.2 Lessons Learned Document 2 days PM/CAT Deliverable 3.3 Presentations to the Program Office 1 day PM/CAT

Figure 19 – Project Work Plan (Notional)



Appendix B – Vision, Goals, and Objective Document

This document may be a component of a separate Project Charter document. As a standalone document, however, a project’s vision (purpose), goals (milestones), and objectives (metrics) are excellent reminders for scope and status. Project Vision

The vision statement links the project goals and objectives with organizational strategies and desired outcomes.

This project will capture, document, verify, and validate requirements for the System under Discussion.

Project Goals Project Objectives

A project goal is a specific and tangible desired result. A project objective is a measurable milestone resulting in the successful completion of a project goal.

Requirement statements will be captured accurately. • 100% of requirement statements shall be written in plain English, jargon-free.

• 100% of requirement statements shall be verified by SMEs. • 100% of requirement statements shall be validated by

approved Systems Quality Assurance (SQA) professionals.

Key Stakeholders

Name, Title, Agency/Department/Office Contact Information (telephone, email, etc.)

Ms. Samantha Harkness, Director, Human Resources, ABC Company

Office: 903-565-1234 | Assistant (Jack): 903-565-1246 Email: [email protected]

Figure 20 – Project Vision, Goals, and Objectives Template



Appendix C – Business Requirements and Rules Document

The Business Requirements and Rules Document is the workhorse of the Requirements Engineering process – and the heart of the M3 methodology.

The sample table of contents provides critical information points, and it is customizable to meet the majority of needs. The one caveat is to remember each project is unique and will have unique documentation requirements.

The explanatory table below provides a workflow template for capturing the BRD components and compiling the various information/data sources into a single format. The final version of the BRD should follow customer preferences, typically Microsoft Word© or Portable Document Format (pdf).

Business Requirements Document (BRD)

EXECUTIVE SUMMARY The executive summary is a brief, high-level overview of the document. No more than one page. 1. Introduction The introduction provides an explanation of the business need, context, and relevant historical precedents. 2. Scope The scope section presents the project scope and criteria for success. This section may include scope boundaries, or what is to be considered out of scope for the project. 3. Current Environment The current environment is a brief overview of the business area, situation, existing issues, problems, or conflict requiring the analysis for a technical or process-oriented change. This is an introduction or preface to the two sections following.

Figure 21 – Business Requirements Document Table of Contents (Notional)




3.1 Current Environment Each business process, information system, and interaction shall be referenced in this section. Separate sub-sections may be included for each process or system. 3.3 High Level Needs Previous sections establish context, process, and systems interactions. High level needs provide an opportunity to specifically identify the business/functional needs for the end users. 4. Desired Future State The desired future state describes in detail who, what, where, when, why, and how the System under Discussion will affect business processes. 4.1 Assumptions Business, functional, financial, operational – what are the agreed and shared assumptions about what this project will accomplish? 4.2 Users Who are the consumers of the system, the information, and the processes? 4.3 Constraints What are the limits or boundaries of the System under Discussion? 4.4 Functional Capabilities/High Level Requirements Functional capabilities are the high level needs identified in 3.3. High level requirements are the measurable and testable requirement statements enabling each of the needs. 4.5 Nonfunctional Requirements Nonfunctional requirements are system qualities, characteristics, or attributes not directly related to business process or function (e.g., system speed, storage capacity, and user interface design). 4.6 Risks This section may be an elaboration or basis for project risks (i.e., identified in a Project Management Plan). What are the business, functional, financial, technological barriers to implementing the System under Discussion – or not implementing? Appendix A. Acronyms and Abbreviations Provide a complete list of all acronyms and abbreviations used throughout the document. Appendix B. Definitions Provide definitions for business, functional, and technical terms used throughout the document.




Appendix C. Models This is an optional appendix to include business process models, flow charts, or other diagrams referenced in the document. Appendix D. Gap Analysis of Data Elements in the System under Discussion This is an optional appendix based on interfacing existing (legacy) systems with new or to be developed systems. The gap analysis provides a visualization of the side-by-side parity in displayed data fields. More thorough data analysis is accomplished in the separate data modeling processes and documentation. Appendix E. High-Level Business Rules Analysis Matrix This matrix provides a discussion of associated business rules required by the System under Discussion. Visualization of the business rules in relation to the needs and features, as with the Requirements Traceability Matrix, is a monitoring tool that allows quick identification of gaps and/or potential risk areas (i.e., not having business rules for a particular need or feature).

Appendix F. Requirements Traceability Matrix This matrix starts the accountability chain of documentation for requirements throughout the SDLC and delivery to the customer – “capture to validation” that what users want is what is delivered. Appendix G. Supporting Documents This is an optional appendix that may be used for related but relevant information supporting the needs, features, or describing in detail legacy systems. Appendix H. Enterprise Requirements This section provides the space to include organizational-specific requirements. These may include architectural, security (information assurance), storage, user interface (Section 508), identity management, or other governance requirements for organizational information systems.




Appendix J. Approval Signatures Endorsing the BRD are two specific business owners: functional/business and technical or information systems. Securing the formal approval of both key leaders enables a smooth transition and hand-off of business requirements to the technical or development group(s). Information Systems Managers Chief Information Officer (CIO) or equivalent. Lower level information systems managers may approve based on organizational policies and procedures. Business Owners The responsible or champion business/functional user group owner for the project. Appendix K. Post Sign-Off Additions

Post Sign-Off Approvers Many organizations require subsequent endorsement/approval of any changes made to baselined documents or information systems processes. In addition to recording the signatures, this section should also provide space for a revision history or changes log.

Figure 22 – Business Requirements Document Template



Appendix D – Process Models Business Process Models (BPM) may be included in the BRD or provided separately. The value of accurate and quality BPMs is twofold. First, BPMs give analysts (requirements, systems, and business) and managers an abstract view of the organization’s work and workflow. Answering the journalistic question of “how,” BPMs illustrate how something is done – a process. Once documented, processes are open to analysis, refinement, consolidation, improvement, etc. Second, BPMs provide a glimpse into the human-computer interactions driving the need(s) or a view of how the System under Discussion enhances organizational capabilities – the elusive value added proposition (or What’s In It For Me – WIIFM). BPMs should be documented in an agreed, acceptable, and meaningful form or style that is actionable by the end users (business/functional) as well as the technical/development team(s). Whether created in a BPM software tool, Microsoft Visio©, or drawn by hand, BPMs need to be developed for the current environment (section 3 in the BRD template) and the desired/future environment (section 4 in the BRD). The following examples represent a modification made to a business process within a healthcare setting. The future state model shows a business process reengineering (BPR) modification. Some tips:

1. Tasks (boxes) always begin with an action verb (e.g., Display Information, etc.). 2. Gateway (diamonds) “questions” begin with an action verb (e.g., Merge Updated Data, etc.) –

questions are not placed in the symbol but may be attached as an annotation. 3. Conditional flow connections (flow line beginning with a diamond) mark significant business

rules (i.e., conditional statements) – save these for reuse later. 4. Always make sure models are consistent with current standards. The current BPMN standard

is available at http://www.bpmn.org/.



Current Environment (As-Is)

Figure 23 – Current Environment BPMN Example Future/Desired Environment (To-Be)

Figure 24 – Future State BPMN Example



Appendix E – Use Cases and Use Case Model There are two schools of thought on use cases. One methodology considers use cases as pictograms showing system functionalities (e.g., UML diagrams or models). The other major philosophy states that use cases are short narrative descriptions explaining a process. Functional or business users, stakeholders, and owners may or may not understand visualized use cases. My preference is to provide narrative use cases. Business and functional end users will understand text more easily than diagrams or models. Once entered into a requirements management tool, the visualizations may be created for the technical communities. The opposite is not always true. Requirements or capabilities entered into an automated tool to generate UML-style use cases can produce narrative “translations” – however, the readability is not as precise. The template below provides the use case outline, and once all use cases are written the document or documents becomes the use case model.

Use Case Template Draft Revision History

Date Revision Event # Change and Author’s Name

ID UC001 – Verb + Noun(s) The ID is the shortened name, preferably a key word in the process or project name. The numbering is sequential and may be automatically generated by a requirements management tool. The Verb + Noun(s) is the full use case name. Brief Description Two to three sentences briefly describing the business or systems scenario. Use Case Trigger Use case triggers are events, activities, or other processes that will lead to the execution of this use case. The triggers may be presented in a bulletized list. Use Case Context Diagram An optional section. A context diagram is a visualization of the use case, either in relation to other use cases or within a larger process. Preconditions Description of the process or system state before this use case begins. Preconditions may be presented in a bulletized list. Basic Flow of Events



Use Case Template A sequential series of steps in short declarative sentences describing the activities involved in the use case. NOTE: If the basic flow consists of more than six (6) steps in the basic flow, consider breaking up the use case into two or more use cases. Alternative Flows Sometimes referred to as “extensions.” Alternative flows provide short declarative sentences describing deviations in the basic flow (i.e., default). There may be more than one extension for each use case. Post Conditions Description of the process or system state after this use case ends. Post conditions may be presented in a bulletized list. Activity Diagram An optional section. Recommend including the BPMN group, if represented as a group, or the BPMN model representing this use case. Special Requirements An option section. Triggers, preconditions, post conditions, and alternative flows are the sources for identifying other requirements not previously captured or identified. NOTE: Do not confuse special requirements with business rules (conditional statements). Other Diagrams An optional section. Existing workflow models, or supporting models and diagrams may be included. Business Rule Traceability Matrix This matrix provides a visualization of business rules identified in this use case.

NOTE: All use case business rule traceability matrices will be compiled into a single table within the business requirements document. Requirements Tracing Either a list or table view of the business or functional requirements elaborated in this use case. Issues Tracing An optional section. A table view of identified issues discovered within this use case.

Figure 25 – Use Case Template



Appendix F – Functional Requirements Document The functional requirements document (FRD) is a more detailed analysis of identified functional requirements from the business requirements document (BRD).

Functional Requirements Document Template Executive Summary The executive summary is a brief, high-level overview of the document. No more than one page. Purpose The purpose is a clarification of functional requirements and the functional requirements document as both a stand along and contributing to a project’s documentation. Scope The scope section presents the project scope and criteria for success. This section may include scope boundaries, or what is to be considered out of scope for the project. Project References List of references and resources. Acronyms and Abbreviations List of acronyms and abbreviations used in the document. Current System Summary Each business process, information system, and interaction shall be referenced in this section. Separate sub-sections may be included for each process or system. Background Summary of the need for new processes or systems. System Objective Explanation of system (or process) main goal. Current Methods and Procedures Narrative summary of current environment (business process models). System Module Overview If a system or process contains multiple parts (e.g., need for different views, capabilities, etc.), summary of each part of the proposed future state solution. System Access Location of system or process assets. How will users access the system or process? System Users List of authorized user roles and responsibilities by module or subsystem, as applicable. Proposed Methods and Procedures Summary of the system or process.



Functional Requirements Document Template

Summary of Improvements If the system or process is an improvement/enhancement, summarize new functionalities or capabilities in the proposed system or process. Functional Improvements Explanation of how the system or process benefits end users. Improvements to Existing Capabilities Detailed explanation of enhancements to system(s) or process(es). Timelines Current development timeline or schedule, including important milestone events for stakeholders. Assumptions and Constraints List of assumptions and limitations imposed in developing the future state solution. Functional Area System Functions View of the system/process inputs and outputs, and failure or contingency criteria and plans. Design Considerations Description of the system/process, how each part works, and how the components of the system interact. Diagrams or models should be included to visualize more complex connections and interactions. Environment Summary of the hardware and software involved in the future state solution. All hardware, software, and supporting technology should be listed here. Communications Requirements Detailed description of interfacing systems hardware and software. Interfaces List of interfacing systems, communication, or messaging systems and applications. Security Explanation of system security plan. Approval Signatures Required functional, stakeholder, and business owner signature acknowledging receipt and acceptance of document.

Figure 26 – Functional Requirements Document (FRD) Template



Appendix G – Non-Functional Requirements Document The Non-Functional Requirements Document provides additional detail and information for non-functional requirements (i.e., system characteristics and capabilities).

Non-Functional Requirements Document Template Overview The overview is a brief, high-level summary of the document. No more than one page.

Usability Suggested usability characteristics include: speed of uses, required user ability, “learnability”, training materials, documentation, on-line or help, and consistency. Each characteristic documented should provide a testable statement and capability of the system. Reliability Required standards or desired reliability of the system. Including, but not limited to: maximum failure rate, maximum down time, ease of recovery, and maximum known bugs. Performance Performance characteristics include: throughput, response time, resource usage, and degradation under overload conditions. Security Security requirements, internal and external to the system. Supportability Characteristics of the system supportability include: ease of installation, planned maintenance, ease of configuration, ease of testing, etc. Infrastructure Requirements Primarily hardware requirements, but may include software or other applications. Including: clients, servers, networks, peripherals, and web services. Implementation Constraints Description of constraints identified based on the system architecture. Including, but not limited to: languages, operating systems, standards, system interfaces, legacy systems, and databases. Appendix A - Diagrams A separate appendix for each diagram or model from any or all of the seven core areas of the Non-Functional Requirements Document.

Figure 27 – Non-Functional Requirements Document Template



Appendix H – System/Application Integration Analysis Document If models (diagrams) or tables are used for this analysis document, a best practice is to provide a short narrative explanation of the pictorial or data representations for business or functional stakeholders and owners.

Figure 28 – System/Application Integration Model



Appendix I – Data Models The different data models may be compiled into a single document, although this is rarely the case. ERDs may be documented in both Unified Modeling Language (UML) models and/or in tabular presentations.

Figure 29 – Entity Relationship Diagram (ERD)



Appendix J – Requirements Traceability Matrix The Requirements Traceability Matrix (RTM) provides a visual alignment of requirements, use cases, functional and non-functional requirements documents, and test cases. Primarily the RTM shows the mapping of requirements from documentation (BRD, FRD, Use Cases) through testing.



TEST CASE ID RQTS

IDENTIFIED UC_1 UC_1.1 UC_1.2 UC_1.3 UC_1.4 UC_1.5 UC_2 UC_2.1 UC_2.2 UC_2.3 UC_2.4 UC_2.5 UC_3

1 001 6 x x x x x x 1.1 002 7 x x x x x x x 1.2 003 6 x x x x x x 1.3 004 3 x x x 1.4 005 7 x x x x x x x 1.5 006 4 x x x x

2 007 5 x x x x x 2.1 008 3 x x x 2.2 009 3 x x x 2.3 010 4 x x x x 2.4 011 2 x x 2.5 012 3 x x x

3 013 3 x x x 3.1 014 5 x x x x x 3.2 015 4 x x x x 3.3 016 5 x x x x x 3.4 017 6 x x x x x x 3.5 018 8 x x x x x x x x

Figure 30 – Requirements Traceability Matrix (RTM) Template



Appendix K – Software Requirements Specification The Software Requirements Specification (SRS) is the capstone document for the requirements engineering or analysis of a project. SRS Section Source Vision, Goals, and Objectives Vision, Goals, and Objectives Document (or BRD) Key statements for vision, goals, and objectives. High Level Business Requirements, Assumptions, Constraints, Stakeholders, and End-Users BRD Lists of business requirements (or needs), assumptions, constraints, stakeholders, and end-users. Business Requirements BRD List of high-level business requirements. Business Process Models BPMs All business process models. Use Case Model UCs Either use case context diagram or list of all use cases. Detailed Functional Requirements FRD Functional requirements, including features and derived requirements identified. Detailed System/Application Integration Requirements ICD Key elements of interfacing design requirements, including derived requirements identified. Data Models (Conceptual and Logical) ERDs All ERDs, or data models. Requirements Traceability Matrix (RTM) RTM RTM.

Figure 31 – Software Requirements Specification (SRS) Template



Appendix L – Lessons Learned (collection form) There is no secret to collecting lessons learned and best practices throughout a project’s life cycle. It has to be simple and easy to use for the submitters. The following example captures the minimum information necessary to record an issue, lesson learned, or a best practice. Subsequent follow-up will add more detailed information. Forms may be either paper (copies available and sufficient space in each area to add a paragraph) or electronic. This example is a Microsoft InfoPath form.

Figure 32 – Lessons Learned Collection Form



Appendix M – Lessons Learned Document Adapted from the Lessons Learned Collection Form, the final lessons learned document compiles all collected, individual lessons learned and best practices. The final document may be sorted by subject, category, criticality, alphabetically, etc. The subject field from the collection form identifies an issue, lesson learned, best practice, or a general “other.” The category field indicates the document or phase of the requirements process.

Lessons Learned Document Category List of categories, and title of all submitted forms sorted by category. Lessons Learned List of lessons learned, including title, discussion, recommendation(s), impact assessment, and resolution. Best Practices List of best practices, including title, discussion, recommendation(s), impact assessment, and resolution. Appendix – Collection Forms Chronological order of all lessons learned collection forms.

Figure 33 – Lessons Learned (Best Practices) Document Template



About the Author Robert Levy is a senior analyst with ASM Research, Inc. His experiences and expertise are in healthcare information management systems, workflow, and business process and reengineering.

Date post:	14-Dec-2015
Category:	Documents
Upload:	robert-d-levy
View:	213 times
Download:	0 times