The Business Analyst Profession

1. The Business Analyst Profession

2. 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.

3. A Business Analyst is Not…… • Project Manager • Organizational Developer • Quality Assurance • Technical Designer • Coder, Tester and Implementer

4. Knowledge Areas • Enterprise Analysis • Business Analysis Planning and Monitoring • Elicitation • Types of Requirements • Solution Assessment and Validation • Requirements Management and Communication

5. 1. Enterprise Analysis • Define & Document Business Problem and Need • Assess Capability Gaps • Determine Solution Approach • Define Solution Scope • Define Business Case

6. 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

7. 3. Elicitation/Requirements Gatheringis 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

8. 4. Types of 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.

9. Types of Requirements • 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.

10. Quality Attribute Types of Requirements • 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.

11. Types of Requirements • 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.

12. Functional Requirement Types of Requirements • 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.

13. Types of Requirements • 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.

14. Design Constraint Types of Requirements • 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.

15. Solution Idea Types of Requirements • 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?”

16. Business Rule Types of Requirements • 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.

17. 5. Solution Assessment and Validation • Assess and Contribute Proposed Solutions • Allocate Requirements • Assess Organizational Readiness • Define Transitional Requirements • Validate Solutions • Evaluate Solution Performance

18. 6. Requirements Management and Communication • Manage Solution Scope and Requirements • Manage Requirements Traceability • Maintain Requirements for Re-use • Prepare Requirements Package • Communicate Requirements

19. Defining Project Roles • Solution Domain • Software Developer • Software Tester • Application Architect • Database Administrator • Network Architect/Engineer) • Business Domain • Project Sponsor • Product Owner • User (Actor) • Subject Matter Expert(SME) Project Manager Business Analyst

20. 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

21. 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

22. Cost of Requirements Errors*Relative Cost to Repair A Defect at Different Project Life Cycle Phases $200 Post Release $50 Acceptance Test $20 Unit Test $10 Build *Adapted from Managing Software Requirements, Dean Leffingwell and Don Widrig.

23. 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

24. Software Tools • Contour

25. Conclusion • IIBA International Institute of Business Analysis • Questions? • My contact information • blevin@ucdavis.edu • Hampton Sublett PMO Group • hsublett@ucdavis.edu • Hope You Enjoyed the Presentation!