sdlc. ba role

36
eleks.com Business Analyst Role in the Project. by Ruslan Tsopa, Business analyst

Upload: eleksdev

Post on 07-Jan-2017

1.695 views

Category:

Software


0 download

TRANSCRIPT

Page 1: SDLC. BA Role

eleks.com

Business Analyst Role in the Project.by Ruslan Tsopa, Business analyst

Page 2: SDLC. BA Role

Agenda• Who is Business Analyst• What are the

requirements• User stories• Use cases• Examples

Page 3: SDLC. BA Role

How does the project begin?

Page 4: SDLC. BA Role

How does the project begin?

Page 5: SDLC. BA Role

Question

Who is involved in development process?

Page 6: SDLC. BA Role

How client sees…

Page 7: SDLC. BA Role
Page 8: SDLC. BA Role
Page 9: SDLC. BA Role

How developers see…

Page 10: SDLC. BA Role
Page 11: SDLC. BA Role
Page 12: SDLC. BA Role

What happens if mix All?

Page 13: SDLC. BA Role
Page 14: SDLC. BA Role

How project fails looks like

Page 15: SDLC. BA Role

Projects success statistics

Page 16: SDLC. BA Role

Who is Business Analyst?

Page 17: SDLC. BA Role

Project fails by activities

Page 18: SDLC. BA Role

Working in Team

BA Architect

UX

No busines

svalue

No softwareSOLUTION:

- business value- strong

architecture- awesome design

No usabilit

y

Page 19: SDLC. BA Role

How Agile Requirements looks like?1. Preliminary elicitation with customer2. Review high level requirements with

Architect and UX3. Clarifying details with customer4. Specification requirements5. Grooming session with Team6. Planning iteration, break down stories by

tasks and tasks estimation

Page 20: SDLC. BA Role

What are requirements?Functional requirements - describe the capabilities that a solution must have in terms of the behaviour and information that the solution will manage

Non Functional Requirements - do not relate directly to the behaviour of functionality of the solution, but rather describe conditions under which a solution must remain effective or qualities that a solution must have

Business rules - statements of goals, objectives, and outcomes that describe why a change has been initiated. They can apply to the whole of an enterprise, a business area, or a specific initiative

Page 21: SDLC. BA Role

How to represent requirements?Requirements representation

• User stories• Use cases• Documents• Mockups• Prototypes• States flow / flow charts/ activity diagram

Page 22: SDLC. BA Role

User storyA user story - simple description of a feature told from the perspective of the person who desires the new capability. It contains enough information so that the developers can produce a reasonable estimate of the effort to implement it. Why all like user stories?:• Small• User/Customer centered• Use end user/customer language• Easy to read /understand bridges the gap between technical and

business• Focus on Delivering Value• Useful for Planning• Easily prioritizable and reprioritizable

Page 23: SDLC. BA Role

User storyAs a <User> I want to <Do something> so that <Expected outcome> Who? What? Why?

Acceptance criteriaDefines conditions for “satisfaction”

 Definition of done

Defines conditions for “readiness”

Page 24: SDLC. BA Role

What is a User story

Page 25: SDLC. BA Role

How good your User story is?

Page 26: SDLC. BA Role

Use caseUse case is a list of steps, typically defining interactions between a role (known as an "actor") and a system, to achieve a goal. The actor can be a human, an external system, or time. Elements of a Use Case Depending on how in depth and complex you want or need to get, use cases describe a combination of the following elements:• actor • precondition/triggers• main scenario• alternative paths/exceptions• post condition

Page 27: SDLC. BA Role

Use caseMore about elementsActor – anyone or anything that performs a behavior (who is using the system) • Class of Users (Role)• External SystemsPreconditions – what must be true or happen before use case to be initiatedMain scenarios [Basic Flow] – use case in which nothing goes wrong.• Main Flow is the sequence of steps that helps the Actor achieve his or her

goal. • Main Flow is the most “typical/common” (usually also simple) success

scenario. • Main Flow always ends with success. Alternative paths [Alternative Flow] – these paths are a variation on the main theme. These exceptions are what happen when things go wrong at the system level.Post condition – what is the state of system or what is expecting result after success 

Page 28: SDLC. BA Role

How Use Cases describe the system behavior

Page 29: SDLC. BA Role

Use case exampleDescription: Pay by credit cardActor – BuyerPreconditions- User is authorized in the system- Amount in cart is more than 0Main scenarios 1. Enter credit card number2. Enter credit card expiration date3. Enter CVV number4. Proceed paymentAlternative pathsA1. Continue shoppingA2. Logout ExceptionE1. There is not enough money in the credit card accountPost conditionPayment is done

Page 30: SDLC. BA Role

User stories & Use case

Page 31: SDLC. BA Role
Page 32: SDLC. BA Role
Page 33: SDLC. BA Role
Page 34: SDLC. BA Role
Page 35: SDLC. BA Role

For ReadingKarl Wiegers – SoftwareRequirements (3rd Edition)

Mike Cohn - User Stories Applied For Agile Software

Page 36: SDLC. BA Role

Inspired by Technology.Driven by Value.

Questions?

Skype: ruslan.tsopaFacebook: tsopa.ruslan