Business Analyst: Difference between revisions

Jump to navigation Jump to search
← Older editNewer edit →
Cpd (talk | contribs)
475 edits
mNo edit summary
Cpd (talk | contribs)
475 edits
mNo edit summary
Line 222: Line 222:


=== 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===
Retrieved from "https://wiki.officience.com/Business_Analyst"