The document discusses the role of a business analyst in a software project. It explains that a business analyst is involved in requirements gathering and representation. This includes eliciting requirements through preliminary discussions with customers, reviewing requirements with other roles like architects and UX designers, and specifying requirements. Requirements can be represented through user stories, use cases, documents, and other methods. User stories are written from the perspective of users and define what they want to do. Use cases outline interactions between actors and a system. Together, clearly documented requirements help ensure a project delivers business value through the right software solution.

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

2. Agenda
• Who is Business Analyst
• What are the requirements
• User stories
• Use cases
• Examples

3. How does the project begin?

4. How does the
project begin?

5. Question
Who is involved in development
process?

6. How client sees…

9. How developers see…

12. What happens if mix All?

14. How project fails looks like

15. Projects success statistics

16. Who is Business Analyst?

17. Project fails by activities

18. Working in Team
BA Architect
UX
No
business
value
No
software
SOLUTION:
- business value
- strong architecture
- awesome design
No
usability

19. How Agile Requirements looks like?
1. Preliminary elicitation with customer
2. Review high level requirements with Architect and UX
3. Clarifying details with customer
4. Specification requirements
5. Grooming session with Team
6. Planning iteration, break down stories by tasks and
tasks estimation

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

21. How to represent requirements?
Requirements representation
• User stories
• Use cases
• Documents
• Mockups
• Prototypes
• States flow / flow charts/ activity diagram

22. User story
A 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

23. User story
As a <User> I want to <Do something> so that <Expected outcome>
Who? What? Why?
Acceptance criteria
Defines conditions for “satisfaction”
Definition of done
Defines conditions for “readiness”

24. What is a User story

25. How good your User story is?

26. Use case
Use 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

27. Use case
More about elements
Actor – anyone or anything that performs a behavior (who is using the system)
• Class of Users (Role)
• External Systems
Preconditions – what must be true or happen before use case to be initiated
Main 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

28. How Use Cases describe the system
behavior

29. Use case example
Description: Pay by credit card
Actor – Buyer
Preconditions
- User is authorized in the system
- Amount in cart is more than 0
Main scenarios
1. Enter credit card number
2. Enter credit card expiration date
3. Enter CVV number
4. Proceed payment
Alternative paths
A1. Continue shopping
A2. Logout
Exception
E1. There is not enough money in the credit card account
Post condition
Payment is done

30. User stories & Use case

35. For Reading
Karl Wiegers – Software
Requirements
(3rd Edition)
Mike Cohn - User Stories
Applied For Agile Software

36. Inspired by Technology.
Driven by Value.
Questions?
Skype: ruslan.tsopa
Facebook: tsopa.ruslan