From fb7113aacefe38d0e4152c7b6cb6de2bf76908a0 Mon Sep 17 00:00:00 2001 From: Jet Hughes Date: Mon, 13 Jun 2022 10:42:47 +1200 Subject: [PATCH] vault backup: 2022-06-13 10:42:47 --- content/notes/requirements-elicitation.md | 54 +++++++++++++++++++++++ content/notes/requirements-engineering.md | 6 +-- content/notes/review-i201.md | 4 +- 3 files changed, 57 insertions(+), 7 deletions(-) diff --git a/content/notes/requirements-elicitation.md b/content/notes/requirements-elicitation.md index 537380aa2..9075844b7 100644 --- a/content/notes/requirements-elicitation.md +++ b/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) + diff --git a/content/notes/requirements-engineering.md b/content/notes/requirements-engineering.md index 457d595c9..449ebc815 100644 --- a/content/notes/requirements-engineering.md +++ b/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.�? - 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. diff --git a/content/notes/review-i201.md b/content/notes/review-i201.md index 21c5d0c64..5c39c3ab9 100644 --- a/content/notes/review-i201.md +++ b/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