1. Requirements Review & Inspection
1.1. 9 Quality Measures (according to IIBA - BABOK)
1.1.1. "While quality is ultimately determined by the needs of the stakeholders who will use the requirements or the designs, acceptable quality requirements exhibit many of the following characteristics” - IIBA
1.1.1.1. Atomic
1.1.1.1.1. self-contained and capable of being understood independently of other requirements or designs.
1.1.1.2. Complete
1.1.1.2.1. enough to guide further work and at the appropriate level of detail for work to continue.
1.1.1.2.2. based on perspective or methodology, as well as the point in the life cycle where the requirement is being examined or represented.
1.1.1.2.3. For functional requirements
1.1.1.2.4. For non-functional requirements
1.1.1.3. Consistent
1.1.1.3.1. aligned with the identified needs of the stakeholders and not conflicting with other requirements.
1.1.1.3.2. No subset of individual requirements described within it are in conflict with one another.
1.1.1.4. Concise
1.1.1.4.1. contains no extraneous and unnecessary content
1.1.1.5. Feasible
1.1.1.5.1. reasonable and possible within the agreed-upon risk, schedule, and budget
1.1.1.5.2. feasible enough to investigate further through experiments or prototypes.
1.1.1.6. Unambiguous
1.1.1.6.1. the requirement must be clearly stated in such a way to make it clear whether a solution does or does not meet the associated need.
1.1.1.7. Testable
1.1.1.7.1. able to verify that the requirement or design has been fulfilled.
1.1.1.7.2. Acceptable levels of verifying fulfillment depend on the level of abstraction of the requirement or design.
1.1.1.8. Prioritized
1.1.1.8.1. ranked, grouped, or negotiated in terms of importance and value against all other requirements.
1.1.1.9. Understandable
1.1.1.9.1. represented using common terminology of the audience.
1.1.1.9.2. Both users and developers can fully comprehend individual requirements.
1.1.2. Other viewpoint from Scopemaster.com
1.1.2.1. Requirements quality attributes examined
1.2. Requirements Reviews
1.2.1. Peer-review
1.2.1.1. Peer desk-check: ask one colleague to look over your work product
1.2.1.2. Pass-around: invite several colleagues to concurrently examine a deliverable
1.2.1.3. Walkthrough: the author describes a deliverable and a committee comments on it.
1.2.2. Fagan Inspection
1.2.2.1. The term Fagan is named after Michael Fagan (IBM), who incorporated various software formal software inspection methods.
1.2.2.2. a given activity has a predefined entry and exit criteria.
1.2.2.2.1. Can also be applied to: Design documents, source code, test documentation, and project plan
1.2.2.3. Participants
1.2.2.3.1. Author: BA who wrote requirements
1.2.2.3.2. People who provides info: Various people can be sources of requirements
1.2.2.3.3. People who will use the work product: developer, tester, project manager, user manual writer.
1.2.2.4. Entry Criteria
1.2.2.4.1. A checklist before deciding to proceed with the inspection
1.2.2.4.2. the high- and low-level documents must comply with specific entry criteria before they can be used for a formal inspection process.
1.2.2.5. Inspection Stages
1.2.2.5.1. Planning:
1.2.2.5.2. Overview
1.2.2.5.3. Preparation
1.2.2.5.4. Inspection Meeting
1.2.2.5.5. Rework
1.2.2.5.6. Follow-up
1.2.2.6. Exit criteria
1.2.2.6.1. Follow-Up’s goal is to ensure all open issues were resolved and errors were properly corrected
1.2.2.6.2. All issues raised during inspection have been addressed.
1.2.2.6.3. Changes in the requirements and related work products were made correctly
1.2.2.6.4. All open issues have been resolved or properly planned.
1.2.2.7. More references
1.2.2.7.1. Guidelines and Characteristics: Fagan Inspection |Professionalqa.com
1.2.2.7.2. LinkedIn: Fagan Inspection Approach
1.3. Writing Acceptance Criteria
1.3.1. Overview
1.3.1.1. a set of conditions of satisfaction being placed on the system.
1.3.1.2. define the minimum conditions for an application to be considered business-ready.
1.3.1.3. Often written by customers
1.3.1.4. used for testing requirements.
1.3.2. Suggestions
1.3.2.1. Focus on stakeholders’ business objectives or the conditions that would bring benefits to the project sponsor
1.3.2.1.1. High-priority features that must be operating properly
1.3.2.1.2. Essential non-functional qualities that must be satisfied
1.3.2.1.3. Severe issues and defects that must be fixed (minor bugs can be allowed)
1.3.2.1.4. Legal issues and regulations that must be observed
1.3.2.1.5. Training materials which must be available
1.3.2.2. Example 1: As a credit card holder, I want to view my statement (or account) balance, so that I can pay the balance due.
1.3.2.2.1. Display statement balance upon authentication.
1.3.2.2.2. Display total balance.
1.3.2.2.3. Show Minimum payment due
1.3.2.2.4. Show Payment due date
1.3.2.2.5. Show error message if service not responding or timeout. For example ‘Sorry, something went wrong with the service. Please try again.’
1.3.2.3. Example 2: As a teacher, I want to generate assessment report, so I can evaluate student performance.
1.3.2.3.1. Show a student’s current assessment score.
1.3.2.3.2. Display past assessment score of the student
1.3.2.3.3. Provide an option to Print / Save / Share.
1.3.2.3.4. Display error message if service not responding.
2. Requirements Capturing
2.1. Most cited top 10 Requirement Engineering problems
2.1.1. Incomplete and / or hidden requirements
2.1.2. Communication flaws between project team and customer
2.1.3. Moving targets (changing goals, business processes and / or requirements)
2.1.4. Underspecified requirements that are too abstract
2.1.5. Time boxing / Not enough time in general
2.1.6. Communication flaws within the project team
2.1.7. Stakeholders with difficulties in separating requirements from known solution designs
2.1.8. Insufficient support by customer
2.1.9. Inconsistent requirements
2.1.10. Weak access to customer needs and / or business information
2.2. Requirements Elicitation
2.2.1. Overview
2.2.1.1. it is the process of identifying the needs and constraints of the various stakeholders for a software system.
2.2.1.2. not just gathering requirements or recording exactly what users say.
2.2.1.2.1. The heart of requirements development
2.2.1.2.2. challenging, critical, error-prone, and communication intensive task
2.2.1.3. Activities: collect, discover, extract, and define requirements
2.2.2. Techniques
2.2.2.1. Technique: Workshop
2.2.2.1.1. Overview
2.2.2.1.2. Effective requirements workshops are made up of five phases:
2.2.2.1.3. What BA should do?
2.2.2.1.4. Read more:
2.2.2.2. Technique: Observation
2.2.2.2.1. What?
2.2.2.2.2. Why?
2.2.2.2.3. Best applications
2.2.2.2.4. Read more:
2.2.2.3. Technique: Questionnaires
2.2.2.3.1. What?
2.2.2.3.2. 4W1H
2.2.2.3.3. Tips
2.2.2.3.4. Read more: