A Business Analyst ……..  Provides solutions to:  Process improvement  Organizational change  Technology components  Utilize their techniques, skills, and abilities required to clearly define a problem faced by the business, working with the development team the BA determines the scope of the solution to the problem. A Business Analyst is Not……  Project Manager  Organizational Developer  Quality Assurance  Technical Designer  Coder, Tester and Implementer Knowledge Areas 1. Enterprise Analysis 2. Business Analysis Planning and Monitoring 3. Elicitation 4. Types of Requirements 5. Solution Assessment and Validation 6. Requirements Management and Communication 1. Enterprise Analysis  Define & Document Business Problem and Need  Assess Capability Gaps  Determine Solution Approach  Define Solution Scope  Define Business Case 2. Business Analysis Planning and Monitoring  Plan BA Approach  Conduct Stakeholder Analysis  Plan BA Activities  Plan BA Communication  Plan Requirements Management Process  Manage BA Performance 3. Elicitation/Requirements Gathering is the practice of collecting the requirements of a system from users, customers and other stakeholders.  Prepare for Elicitation  Conduct Elicitation Activity  Document Elicitation Results  Confirm Elicitation Results 4. Types of Requirements Business Requirements • Sounds Like a high-level business goal or objective. • Example: “Expand the number of customers we have by 50% next year. • Why it’s important: Establishes the business case for the project. Types of Requirements Use Case • Sounds like the name of a process, collection of individual steps. • Example: “Customers will be able to plan an adventure.” • Why it’s important: Use cases are containers for functional requirements in context. Types of Requirements Quality Attribute • Sounds like a quality characteristic that a system should posses, e.g. performance, security, etc. • Example: The system should be able to accommodate 100 simultaneous users. • Why it’s important: The system should ensure a certain quality of service to users. Types of Requirements Data Definition • Sounds like information the system will create, update, read, or delete. • Example: If I enter a name I want to see their address. • Why it’s important: A system can’t work without data. Types of Requirements Functional Requirement • Sounds like a single statement of one individual function. (Will, or Shall statements) • Example: With the correct 4 digit pin the system will allow the user access the ATM machine. • Why it’s important: These are the detailed functional requirements of the system. Types of Requirements External Interface • Sounds like getting information from or giving information out. • Example: Perform a search, get a result. • Why it’s important: Almost every system communicates with something else in the universe. Types of Requirements Design Constraint • Sounds like a limitation of the solution or implementation. • Example: “The UI has to function with IE8 and above.” • Why it’s important: Design constraints must be considered when the solution is determined. Types of Requirements Solution Idea • Sounds like a solution or statement of design. • Examples: We will only be able to accept electronic applications. • Why it’s important: Work backwards from the solution idea to the underlying business requirements. “What's the problem we are trying to solve?” Types of Requirements Business Rule • Sounds like a policy determined by management, or some regulatory agency, that limits what people or an automated system can do. • Example: “Customers must be registered before they can use the ATM machine. • Why it’s important: System must ensure compliance with all business rules. 5. Solution Assessment and Validation  Assess and Contribute Proposed Solutions  Allocate Requirements  Assess Organizational Readiness  Define Transitional Requirements  Validate Solutions  Evaluate Solution Performance 6. Requirements Management and Communication  Manage Solution Scope and Requirements  Manage Requirements Traceability  Maintain Requirements for Re-use  Prepare Requirements Package  Communicate Requirements Defining Project Roles  Business Domain  Solution Domain  Project Sponsor  Software Developer  Product Owner  Software Tester  User (Actor)  Application Architect  Subject Matter  Database Administrator Expert(SME)  Network Architect/Engineer) Typical Role of BA  ROI (Return on Investment)  Key Facilitator  Liaison Between Business Organization and Solution Developers  Examine Business Problem and Needs  Ensure Needs Are Valid, Understood and Met  Identify, Validate, and Document Requirements  Ensure Solutions Satisfy those Needs  Advocate for the Business Summary: The Business Case  Good Requirements are Essential for Project Success  Its Important to Know What a Good Requirement Sounds Like  There is a Cost Associated With Missed or Ambiguous Requirements that can be quite large  Getting Requirements Right Can Save Substantial Rework, Time, and Money  Requirements Engineering Involves Developing and Managing Requirements Cost of Requirements Errors* Relative Cost to Repair A Defect at Different Project Life Cycle Phases 200 $200 Post Release 180 160 140 120 100 80 60 40 20 0 *Adapted from Managing Software Requirements, Dean Leffingwell and Don Widrig. Organizing Requirements  Creating a Requirements Document is really about packaging the requirements  Create a requirements set or package that reflects the requirements for a particular system, sub-system, or a number of systems together  Define requirements that are applicable to the entire system; global requirements  Define requirements that are specific to sub-systems and eventually to individual use cases Software Tools  Contour Conclusion  IIBA International Institute of Business Analysis  Questions?  My contact information  [email protected]  Hampton Sublett PMO Group  [email protected]  Hope You Enjoyed the Presentation!