Business Analyst: Difference between revisions

← Older edit Newer edit →

@@ Line 200: / Line 200: @@
 == Session 4==
+=== Elicitation ===
+====Definition====
+#to draw forth or bring out (something latent or potential)
+#to call forth or draw out (as information or a response)
+These definitions highlight the need to actively engage the stakeholders in defining requirements.
+====Frequently used techniques & output ====
+'''Techniques :'''
+* Hold elicitation interviews
+* Identify champion product
+* Perform document analysis
+'''Output'''
+* Requirements [Stated]: Described from the perspective of the stakeholder. Stated requirements describe the stakeholder’s need from the stakeholder’s perspective.
+* Stakeholder Concerns: Includes issues identified by the stakeholder, risks, assumptions, constraints, and other relevant information
+=== Analysis ===
+==== 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 & output ====
+'''Techniques :'''
+* Prioritize the requirements
+* Create a data dictionary
+* Analyze requirement feasibility
+'''Output'''
+Requirements [solid]: Prototype (visual form), Document (textual form)
+=== Specification ===
+==== 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 ====
+'''Techniques :'''
+* Specify non-functional requirements
+* Record business rules
+* Identify requirement origins
+'''Output:'''
+User requirements typically are represented in the form of use cases or user stories.
+===Validation===
+==== 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
+====Frequently used techniques & output ====
+'''Techniques :'''
+* Simulate the requirements
+* 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
+===Sources===
+* [https://lostechies.com/joeocampo/2007/09/20/agile-vs-traditional-development-cost-models-maybe Traditional Methodology Resource Cost Chart]
+* BABOK v2.0
+* Microsoft.Press.Software.Requirements.3.3rd.Edition.Aug.2013.pdf
+* [https://www.slideshare.net/MarrajuBollapRagada/agile-vs-iterativevswaterfall Quick understanding about Waterfall / Iterative / Agile]

Business Analyst: Difference between revisions

Navigation menu

Search