Presentation is loading. Please wait.

Presentation is loading. Please wait.

2010 UBO/UBU Conference Title: Information Managements (IMs) Requirements Management and Delivery Framework: Developing the Blueprints for IT Systems Session:

Similar presentations

Presentation on theme: "2010 UBO/UBU Conference Title: Information Managements (IMs) Requirements Management and Delivery Framework: Developing the Blueprints for IT Systems Session:"— Presentation transcript:

1 2010 UBO/UBU Conference Title: Information Managements (IMs) Requirements Management and Delivery Framework: Developing the Blueprints for IT Systems Session: W-4-1100

2 Objectives Provide a high-level overview of Requirements Management Present IMs Requirements Delivery Framework Present Benefits of Requirements Management and Delivery Framework Provide overview of the Requirements lifecycle Discuss the roles and responsibilities associated with IMs Requirements Delivery Framework Illustrate how IM aligns with MHSs strategy 2

3 What Is Requirements Management? Requirements Management are the activities that control requirements development including change control, requirements attributes definition, and requirements traceability. Business Analysis Body of Knowledge (BABOK) 3

4 Why Is Requirements Management Important? Requirements Management allows you to solve the right problem and build the right Information Technology (IT) solution via the following activities: – Eliciting, organizing, and documenting required functionality and constraints – Tracking and documenting trade-offs and decisions – Easily capturing and communicating business requirements 4

5 Requirements Management Benefits IM follows a streamlined and repeatable requirements process which: – Complies with MHS IM/IT mandate – Improves product quality – Controls development and sustainment costs – Improves cycle time 5

6 Requirements Benefits to the IT Process Lifecycle IM directly supports the top three highest value, highest complexity IT lifecycle functions } 6

7 IMs Requirements Delivery Framework 7

8 Requirements Delivery Framework Benefits The Requirements Delivery Framework provides a standardized, documented methodology that is tailored, transparent, and template-driven and addresses the following challenges: – Outdated requirements – Inconsistent documentation – Lack of stakeholder involvement, feedback, and approval – Requirements that do not meet all of the quality criteria 8

9 IMs Requirements Delivery Quality Criteria 9 CriteriaDefinition IdentifiedEach requirement is uniquely identified via an alphanumeric expression ClearAll readers of a requirement should arrive at the same interpretation of its meaning. ConciseEach requirement must contain only words necessary to clearly communicate what is needed. CompleteAll known requirements are documented and all conditions under which a requirement applies are stated. ConsistentThe requirements can be met without causing conflict with any of the other requirements. CorrectEach requirement must accurately describe the functionality to be built. Only the source (customer, user, stakeholder) of the requirement can determine its correctness. TestableThe requirement must be written so that testers can demonstrate that the system satisfies the requirement. FeasibleMeeting the requirement should be achievable. SingularEach requirement expresses a single, unique idea. Solution-freeEach requirement expresses the what and why of the need; not how to do it.

10 IMs Requirements Lifecycle 10 Pre- Investment Pre- Execution Re- Costing Acquisition Pre Investment Business Requirements Specification (BRS) Pre Execution BRS ASR PIR TRRCDRPDRSRR ITR Costing Strategic Planning Submissions Management Requirements Delivery Business Architecture / Management of Data and Information BPR Lifecycle Management BPR Assessment Form (As-Is, To-Be Business Processes) Initial Business Case Submit Need Assess Final Business Case Governance Milestones AnalyzeApprove Planning >> Elicitation >> Analysis >> Specification >> Validation

11 Requirements Lifecycle: From a Bright Idea to a Baselined Set of Requirements 11 PlanningElicitationAnalysisSpecificationValidation Approval BRS Baseline Iterative Process Submit Support Request Form Analyze Submission Present Submission to Appropriate Portfolio Board Approve Submission Iterative Process After a submission is approved, it enters the first phase of the requirements process – Planning. This lifecycle can be used for any software development methodology including the following: Waterfall Agile Spiral Incremental

12 Planning 12 Requirements Planning is a preparatory phase of the requirements lifecycle during which stakeholders, roles and responsibilities, communication methods, requirements approach, and metrics are identified. Activities Identify High-level Business Requirements Identify Stakeholders Develop Project Scope Create Requirements Management Plan Configure and Verify Traceability Structure Mechanisms Client-led interviews Working groups Stakeholder / user interviews Stakeholder / user surveys Artifacts Requirements Management Plan 1 Communications Plan 1 Business Case Metrics 1 One Requirements Management Plan and one Communications Plan are required.

13 Elicitation 13 Requirement Elicitation is a phase of learning, uncovering, extracting, surfacing, and discovering the needs of customers, users, and other potential stakeholders. Activities Initiate project Form workgroup Define project objective and Scope Identify Stakeholders Choose elicitation techniques Explore attributes, capabilities and business rules Mechanisms Client-led interviews Working groups Stakeholder / user interviews Stakeholder / user surveys Artifacts Stakeholder List Project Charter, Plan, and Schedule Questionnaires/Surveys Agendas/Meeting Minutes

14 Analysis 14 Requirements analysis is the compilation of tasks that go into determining the needs or conditions for the final solution. During this phase analysis models with screenshots, high-level use case packages, and business process diagrams are created, requirements are prioritized, and impacts and risks are assessed. Activities Create analysis model Screenshots High-level use case diagram Business process flows Prioritize requirements Mechanisms Client-led interviews Analysis tools (i.e. Rational Rose) Rapid Prototyping Tools Artifacts Process Maps Use Cases (as-is and to-be) Context Diagrams Business Rules Prioritized Requirements

15 Specification 15 Requirements Specification defines what the product needs to do without addressing how it will be done. During this phase, all business requirements are compiled and ambiguities from possible conflicting requirements of various stakeholders or users are resolved. Activities Document workflow requirements Eliminate ambiguities & store requirements Write use cases with normal flow, alternate flows, and any additional business rules Complete process flow diagrams Mechanisms Requirements Management Repository (e.g., DOORS) AKO/DKO Artifacts Business Requirements Specification (BRS) Enterprise Architecture Models

16 Validation 16 Requirement Validation is ensuring that the stated requirements support and are aligned with the goals and objectives of the business. Activities Peer review requirement specifications Inspect requirement specifications Iterate requirements as needed Mechanisms Peer review sessions Client lead reviews Artifacts Approved BRS Requirements Traceability Matrix (RTM)

17 Roles and Responsibilities Within IM 17 RoleResponsibilities Information Management Division Serve as a liaison between the Warfighter, clinical-business mission owners, Services stakeholders, and the OCIO Information Manager (IM) Identify and define the functional and performance requirements that support the MHS Core Functional Areas (i.e., Clinical, Force Health Protection, Business) through their representation of their respective DASDs Serve as, or identify, additional SMEs. Participate on various IPTs and IRD Workgroups to support requirements related activities in the process IM AnalystServe as experts on MHS capabilities and functional requirements in one or more of the MHS Core Functional Areas (e.g., Clinical, Force Health Protection, and Business) Assist Information Managers with developing both high-level and detailed functional requirements and manage capabilities Review, validate, and prioritize submissions, and develop the IRD CONOPS and assist with its subsidiary artifacts, which may include JCIDS documents Assists with creating POM and Fiscal Year (FY) Investment Portfolio submissions

18 IMs Strategic Alignment with MHS IM aligns with MHSs strategic action plans: – Governance Implemented Governance structure – Innovation Enterprise wide collaboration – Interoperability Seamless exchange of information – Maximize Portfolio Value Improve development and sustainment costs – Requirements and Business Architecture Requirements Delivery Framework – Streamline IM/IT Lifecycle Improved cycle time and product quality 18

19 Business Capabilities Supported by IM Medical Service Accounts (MSA) – The MSA function consists of billing and collecting funds for medical and dental services, including elective cosmetic procedures, from: DoD beneficiaries (where applicable…this is usually DoD civilians assigned to overseas installations); civilian emergency patients; other patients authorized treatment in MTFs (foreign military officers). MSA provides a complete and reliable financial record of transactions including collection control, accounts receivable, and deposits. Medical Affirmative Claims (MAC) – The mission of the Medical Affirmative Claims is to enact the Federal Claims Collection Act (31 USC 3711-3720A). The goal of MAC is to recover the reasonable value of medical care rendered for injuries or illnesses provided at Government expense to DoD beneficiaries under circumstances creating a third party tort liability. Example: If an active duty member was involved in a motor vehicle accident (for which the Government provided healthcare), the Government is required to seek restitution for those costs from the insurance company of the person at fault. Third Party Collection Program (TPCP) – The TPCP requires MTFs to bill Other Health Insurance for outpatient visits or inpatient stays to include pharmacy, lab, and radiology services. Example: My wife maintained health care insurance while I was on active duty even though she was entitled to free healthcare as my spouse (she had the insurance because she traveled extensively for work and wasnt always near an MTF) so when my wife went to the MTF where we were assigned, the MTF was allowed to bill her insurance company for her care. 19

20 Q&A Questions? 20

21 Speaker Information Session ID: M-4-1100 21

22 Acronyms 22 AcronymDefinition ASRAlternative Systems Review BRSBusiness Requirements Specification CBTComputer Based Training CDRCritical Design Review IMInformation Management ITRInitial Technical Review OVOperational View PIRPost Implementation Review PDRPreliminary Design Review RTMRequirements Traceability Matrix SIRSystem Incident Report SRRSystem Requirements Review TRRTest Readiness Review

23 Glossary TermDefinition Business Requirement Higher-level statement of goal, objective, or need of the enterprise. It describes why the project is initiated, the things that the project will achieve, and the metrics which will be used to measure its success Business Requirements Engineering A requirements engineering sub-activity consisting of the cohesive collection of all tasks that are primarily performed to produce the requirements and other requirements work products for the customer organizations business enterprise Configuration Management The management activity consisting of the cohesive collection of all tasks that are primarily performed to manage an endeavors baselines of configuration items Change Control Board (CCB)Any team that determines when and if changes are to be implemented to base-lined work products Functional Decomposition A requirements analysis technique for breaking down large required functions into smaller sub- functions Functional Requirement A requirement that specifies a function that a business, application, or component must be able to perform Non-Functional Requirement Condition that does not directly relate to the behavior or functionality of the solution, but rather describes environment conditions under which the solution must remain effective or qualities that the systems must have RequirementA condition or capability needed by a stakeholder to solve a problem or achieve an objective. Requirements Analysis The requirements engineering task during which the reused and elicited raw requirements are analyzed Requirements Engineering The activity consisting of the cohesive collection of all tasks that are primarily performed to produce the requirements and other related requirements work products for an endeavor Requirements EvaluationThe quality control task during which the requirements work products are evaluated Requirements Management The requirements engineering task during which requirements are base-lined, placed under configuration control, and maintained during subsequent iteration 23

24 Glossary TermDefinition Requirements Specification The requirements engineering task during which the analyzed requirements for a system, application, application domain, or component are published in requirements specifications (and related requirements documents) Requirements Traceability Matrix (RTM) A table that correlates any two base-lined documents that require one-to-many, many-to-one, or many-to-many relationships to determine the completeness of the relationships Requirements Validation The requirements engineering task during which the correctness of the identified and/or analyzed requirements is verified by their stakeholders SubmissionAny idea that fosters a change (addition, modification, or removal) to a capability, policy, process, or system System Design Document (SDD) A design work product that is comprehensive description of how the system requirements in the SRS are transformed into more technical system design specifications from which the system is built. It is used to document both high-level system design and low-level detailed design specifications. System Requirement Statement that describe the behavior and information that the solution will manage. It describes capabilities the system will be able to perform in terms of behaviors or operations – a specific system action or response. System Requirements Specification (SRS) The requirements work product that formally specifies the system-level requirements of a single system or an application The requirements specification is the foundation on which the architecture, design, and implementation are built. DOORS (Dynamic Object Oriented Requirements System) A powerful requirements management tool used to capture, link, analyze, and trace requirements that ensures conformance to requirements and compliance with regulations and standards. Technical Specifications Design requirements that define how the AIS must be built to satisfy both business and user requirements. Test Script Set of conditions or variables under which a tester will determine if a requirement or use case upon an application is partially or fully satisfied User Requirement Statement of need of a particular stakeholder or class of stakeholders. It describes the needs that a given stakeholder has and how that stakeholder will interact with a solution. User Requirements serve as a bridge between Business Requirements and the System Requirements. 24

Download ppt "2010 UBO/UBU Conference Title: Information Managements (IMs) Requirements Management and Delivery Framework: Developing the Blueprints for IT Systems Session:"

Similar presentations

Ads by Google