Requirements Management in Program Quality - Overview
Understanding requirements management in program quality is crucial for successful project outcomes. This overview covers the importance of defining clear requirements, potential challenges, and the significance of meeting stakeholder expectations in project delivery.
Download Presentation
Please find below an Image/Link to download the presentation.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author. Download presentation by click this link. If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.
E N D
Presentation Transcript
PROGRAM MANAGEMENT OFFICE Program Quality Management Requirements Overview March, 2014
Agenda What is a Requirement? What could go Wrong? Getting it Right Types of Requirements OneMontclair Documents for Requirements Questions & Answers
Swing Example How Customer Explained It How the Consultant Described It How the Project Leader Understood It How the Developers Wrote It What the Testers Received to Test How It Was Supported How Patches Were Applied How Operations Installed It How It Performed Under Load The Disaster Recovery Plan
Swing Example What the Customer ACTUALLY Needed
What is a Requirement? So, what is a Requirement in industry-speak, then? A condition or capability needed by a stakeholder to solve a problem or achieve an objective. A condition or capability that must be met or possessed by a solution or solution component to satisfy a contract, standard, specification, or other formally posed documents. From The Guide to the Business Analysis Body of Knowledge Version 2.0 Framework (BABOK) by the International Institute of Business Analysis (IIBA)
What is a Requirement? It is also an agreement between two parties which defines completion of work. Service Provider and Customer Engineer and Manager Tester and Provider When all the requirements are satisfactorily met, the work is done.
What could go wrong? I need to get my house painted Requirements are not specific or not documented I said to paint the room Blue, I don t want White You said to paint the room Requirements are not complete I painted all 4 walls What about the ceiling?
What could go wrong? Mis-matched expectations I expected you to use a paint roller on the walls it would have been much faster I always use a paint brush Unimportant details not relevant to the job Really? That is going to cost extra. Use only horse-hair paintbrushes and use a new brush for each color.
What could go wrong? Un-measurable Requirements The paint has to make the room look bright and airy. Uh OK Unattainable Requirements Sure, no problem We will discuss that later You have to paint around the furniture don t move anything.
What could go wrong? Changing Requirements OK, another two days and more money That shade of blue is all wrong I want a lighter shade. Accepting Requirements from Anyone My Mom said to paint the ceiling white but I want it to be pink. Sure, no problem
Getting it Right Apply SMART techniques when writing effective requirements. Each requirement should be: S Specific M Measureable A Attainable R Relevant T Testable
Getting it Right Use a hierarchical Approach review at each level of decomposition with relevant stakeholders and trace the relationships Business Requirements Requirements Traceability Matrix (RTM) Functional Requirements Business Rules & Data Requirements Decide early the types and format of requirements documentation required Test Plans and Scripts
Getting it Right Review and Discuss Discussion sessions or Joint Application Design (JAD) sessions The technical teams from both sides of the contract meet to review, revise, and agree on the requirements Diagrams (work flows) help The output is better understanding and agreement on both sides
Getting it Right Involve all groups or teams that will be stakeholders for the project when reviewing the requirements Customers (who pay the bill ) Users Testers Support staff Approvers Specify who can request changes to agreed requirements and ensure that an impact analysis is performed on any changes (budget, schedule, resources)
Types of Requirements Requirement Type Definition Business Requirement A business requirement is a goal of the organization requesting the system. Functional Requirement A functional requirement is a decomposed business requirement into greater detail. Each business requirement will have 1:n functional requirements. Business Rules A business rule is the logic upon which the data will be processed such as a formula, comparison with other data, edit checks or other rules. Each functional requirement will also have a 1:n relationship with the business rules. Data Requirements Where will the system get the data it needs? Will it be entered by the user or sent/retrieved by another system? How much data for each field? Where will the data go? Again, there can be 1 or more data requirements for each business rule. Non-Functional Requirement A non-functional requirement is a quality attribute that the system must have. These attributes are not system features (functional requirements), but they do influence how the functionality of the system is implemented. Non-functional requirements usually deal with some aspect of usability, performance, or security or are operational in nature.
OneMontclair Requirements Documents Document Name Description and Required Content This is the subset of the OneMontclair Program Business Requirements applicable to this project. It defines the customer needs and the requirements of the organization often expressed in ability to perform statements. Project Business Requirements These define what the project must achieve, and according to what quality measures (e.g., key performance indicators or tangible objectives.) Business Requirements are decomposed through discussion and data gathering with the business function personnel Use Cases / Use Case Models / Scenarios Use Cases and Scenarios describe the various functions to be performed by the system in terms of users and roles as defined in the Application User Group / Roles Matrix. Focus is on particular user role s activities within a business process, not the entire business process itself Swimlane Process Flows Swimlane Process Flows describe the various functions to be performed by the application(s) in graphical flow-chart form displaying multiple roles, their activities, and their interactions Business Rules A set of necessary requirements that have to be accommodated within the implemented processes Elaboration of Business Requirements The BRD is required for all projects each project selects the requirements documents to be used. OM-STD-001 Project Document Requirements Requirements Phase
OneMontclair Requirements Documents Directly related to the performance of a system or application Functional Requirements Describe what the system, process, product, or service must do to fulfill the business requirements Non-Functional Requirements quality attributes that a system must have (e.g., usability, performance, capacity, security, etc.) User Groups / Roles Matrix with CRUD Mapping describes the various user and administrative roles and groups who will access the applications and their relative access and security requirements to various data as defined in the Project Data Architecture. The defined set of User Groups and Roles will be reflected in the Use Cases, Scenarios, and Swimlane Process Flows State Transition Diagrams describes data objects used or managed within the context of the project, the various states in which these objects can exist and the triggers that will cause the objects to change from one state to another. Project Data Flow and Integration Requirements Document describes how major data items must be stored and flow among the various applications. Project Technology-Related Requirements
OneMontclair Requirements Documents Requirements that address the business requirements but are not directly implemented into the system or application (e.g., creating a new organizational position, new required business policy) Project Non-Technology Requirements Content: (ID, non-technology related requirement, priority, source, mapped to business requirements) individual, standalone, SMART statements or conditions Project Data Migration and Conversion -Business Requirements and Business Rules Document This document describes the Business Rules and business requirements that directly apply to data migration for this project. Project Requirements Traceability Matrix (RTM) (Contains references to all level of current Project Requirements with bi- directional traceability to higher level requirements as well as to designs, releases, and tests) This is an Excel file or database tool used to inter-relate the various requirements to each other and to product releases and tests. This document is used to perform impact analyses when requirements or sub-systems change on the project. It is also used to ensure that all business and customer requirements are ultimately implemented and tested. This document is maintained and statused throughout the project lifecycle.
Questions? Concerns? Suggestions?
