Business Analyst: Difference between revisions

Jump to navigation Jump to search
← Older edit
Cpd (talk | contribs)
475 edits
mNo edit summary
Cpd (talk | contribs)
475 edits
mNo edit summary
 
(4 intermediate revisions by the same user not shown)
Line 1: Line 1:
[[File:Nobody mess with my Best Amigos (BA) !.png]]
[[File:Nobody mess with my Best Amigos (BA) !.png]]


Thao Lan NGUYEN THI organized 2 training sessions about the job of '''Business Analyst''' (also known as "BA") in IT Development in May 2016 and April 2017.
 
 
Thao Lan NGUYEN HOANG organized 2 training sessions about the job of '''Business Analyst''' (also known as "'''BA'''") in IT Development in May 2016 and April 2017.
 


== Session 1 ==
== Session 1 ==
Line 222: Line 225:


=== Analysis ===
=== Analysis ===
{| class="wikitable" style="width: 60%;"
|-
| '''Definition'''|| Requirements analysis involves refining the requirements to ensure that all stakeholders understand them and scrutinizing them for errors, omissions, and other deficiencies.


==== Definition ====
|-
Requirements analysis involves refining the requirements to ensure that all stakeholders understand them and scrutinizing them for errors, omissions, and other deficiencies
| '''Frequently used techniques'''||
 
====Frequently used techniques & output ====
'''Techniques :'''
 
* Prioritize the requirements
* Prioritize the requirements
* Create a data dictionary
* Create a data dictionary
* Analyze requirement feasibility
* Analyze requirement feasibility
 
|-
'''Output'''
| '''Output'''|| Requirements [solid]: Prototype (visual form), Document (textual form)
 
|}
Requirements [solid]: Prototype (visual form), Document (textual form)


=== Specification ===
=== Specification ===
 
{| class="wikitable" style="width: 60%;"
==== Definition ====
|-
Requirements specification is to document requirements of different types in a  consistent, accessible, and reviewable way that is readily understandable by the intended  audiences
|'''Definition'''|| Requirements specification is to document requirements of different types in a  consistent, accessible, and reviewable way that is readily understandable by the intended  audiences.
 
|-
====Frequently used techniques & output ====
| '''Frequently used techniques'''||
'''Techniques :'''
* Specify non-functional requirements
* Specify non-functional requirements
* Record business rules
* Record business rules
* Identify requirement origins
* Identify requirement origins
 
|-
'''Output:'''
| '''output''' || User requirements typically are represented in the form of use cases or user stories.
 
|}
User requirements typically are represented in the form of use cases or user stories.


===Validation===
===Validation===
 
{| class="wikitable" style="width: 60%;"
==== Definition ====
|-
 
|| '''Definition''' || Validation ensures that the requirements are correct, demonstrate the desired quality characteristics, and will satisfy customer needs. Requirements that seem fine when you read them might turn out to have ambiguities and gaps when developers try to work with them.
Validation ensures that the requirements are correct, demonstrate the desired quality characteristics, and will satisfy customer needs. Requirements that seem fine when you read them might turn out to have ambiguities and gaps when developers try to work with them
|-
 
| '''Frequently used techniques'''||
====Frequently used techniques & output ====
'''Techniques :'''
* Simulate the requirements
* Simulate the requirements
* Define acceptance criteria
* Define acceptance criteria
|-
| '''output''' || User requirements typically are represented in the form of use cases or user stories, that are understood correctly by Dev team and Stakeholders
|}


'''Output:'''
User requirements typically are represented in the form of use cases or user stories, that are understood correctly by Dev team and Stakeholders


===Sources===
===Sources===
Line 272: Line 269:
* Microsoft.Press.Software.Requirements.3.3rd.Edition.Aug.2013.pdf
* Microsoft.Press.Software.Requirements.3.3rd.Edition.Aug.2013.pdf
* [https://www.slideshare.net/MarrajuBollapRagada/agile-vs-iterativevswaterfall Quick understanding about Waterfall / Iterative / Agile]
* [https://www.slideshare.net/MarrajuBollapRagada/agile-vs-iterativevswaterfall Quick understanding about Waterfall / Iterative / Agile]
== References ==
* [https://docs.google.com/presentation/d/1O94mnfFULC_mSGIw63lmPuIUBHK25ENIMz9T7-CMDYk BA Training Course - Part 1 (by Thao Lan NGUYEN HOANG)]
* [https://docs.google.com/presentation/d/1sPMHC_HnyKx4s6ewHeYxZ-DUWe_1R70-Q--Dop_bZVQ BA Training Course - Part 2 (by Thao Lan NGUYEN HOANG)]
* [https://docs.google.com/presentation/d/1T0P99QI7L5Ha9Xf8teJLWpnPIrFHhyptn8m0P8pqGrE BA Training Course - Part 3 (by Thao Lan NGUYEN HOANG)]
* [https://docs.google.com/presentation/d/12HM3EQTGqkcofnOmSpfirRC5T3by5Zbn3ojfQesNiH0 BA Training Course - Part 4 (by Thao Lan NGUYEN HOANG)]
Retrieved from "https://wiki.officience.com/Business_Analyst"