vault backup: 2022-06-13 10:42:47

content/notes/requirements-elicitation.md

@@ -4,4 +4,58 @@ tags:
 - info201
 ---
 
+- A process by which analysts gather information on what the system should do, from as many sources as possible. 
+- All methods are effective but some are more efficient than others. 
+- Different methods can be combined for more comprehensive fact-finding.
+
+# Characteristics of good Analysts
+Impertinence ⇒ question everything, assume nothing 
+Impartiality ⇒ find the best solution to the business problem 
+Relax ⇒ constraints assume anything is possible but eliminate the infeasible 
+Attention ⇒ to detail be precise, comprehensive, and consistent 
+ReFraming ⇒ be creative and “think outside the box”
+
+# Stakeholders
+- Internal stakeholders — people within the organisation, e.g., employees, volunteers, ….
+- External stakeholders — people outside the organisation, e.g., suppliers or shipping companies.
+- Operational stakeholders — people who regularly interact with the system, e.g., accountants, factory supervisors, customers, ….
+- Executive stakeholders — people who don’t directly interact, but use the information or have a financial interest, e.g., senior managers, board of directors, regulatory authorities, ….
+
+![stakeholders diagram|300](https://i.imgur.com/W1ivdjH.png)
+
+# Information Gathering
+- Existing Information
+- Interview and discussions
+- Observew and document business process
+- Prototypes
+- Questoinnaires
+- Vendor Solutions
+
+# Validation of Requirements
+- Make sure gathered information is correct. 
+- Structured walk-through: 
+	- effective way to implement quality control early in project 
+	- verify and validate system requirements 
+	- review of findings from investigation 
+	- review of models based on findings 
+- Project manager responsible for system quality. 
+- Schedule review soon after document creation. 
+- Review conducted by experienced analyst and stakeholders, presented by analyst.
+
+# Requirements in Agile Methodologies
+
+- Requirements should be decoupled: 
+	- must be as independent as possible 
+	- identify which requirements to implement not when to implement them 
+- Every iteration includes a requirements collection and prioritisation activity: 
+	- important requirements are implemented next 
+	- less important requirements held to later iterations, or not implemented at all 
+	- [scrum](notes/scrum.md): product backlog 
+	- [UP](notes/unified-processes.md): inception & elaboration phases 
+	- [xp](notes/extreme-programming.md): user stories
+
+[interviewing](notes/interviewing.md)
+
+[participant-observation](notes/participant-observation.md)
+
 

content/notes/requirements-engineering.md

@@ -4,7 +4,7 @@ tags:
 - info201
 ---
 
-> “…to cover all of the activities involved in discovering, documenting, and maintaining a set of requirements for a computer-based system.� - Kotonya and Sommerville, 2001, p. 8
+> “…to cover all of the activities involved in discovering, documenting, and maintaining a set of requirements for a computer-based system.<EFBFBD>? - Kotonya and Sommerville, 2001, p. 8
 
 Requirements engineering is a robust methodology for the development of requirements. It is made  up of three main steps.
 
@@ -15,14 +15,10 @@ This is where you identify all the requirments of the system. [requirements-elic
 
 This is also where you should learn about the domain of the system and the stakeholders
 
-
 # 2 Documenting
-
 This is where the requirements are specified and refined, and models and documents are created. All the requirements are compiled into a [requirements document](notes/requirements-document).
 
-
 # 3 Maintenance
-
 This occurs throughout development and is primarly focuses on managing changes in the environment of the system. 
 
 It important to manage what is being discovered and documented. This allows you to keep the client updated and manage scope creep.

content/notes/review-i201.md

@@ -18,8 +18,8 @@ tags:
 	- properties of good ones [requirements-guidelines](notes/requirements-guidelines.md)
 	- functional vs not [furps](notes/furps.md)
 	- importance (moscow) 
-- elicitation
-	- stakeholders techniques
+- elicitation [requirements-engineering](notes/requirements-engineering.md)
+	- stakeholders techniques [stakeholders](notes/stakeholders.md)
 	- outcome validation
 
 # business functions and use cases