Test your basic knowledge |

Instructions:
  • Answer 50 questions in 15 minutes.
  • If you are not ready to take this test, you can study here.
  • Match each statement with the correct term.
  • Don't refresh. All questions and answers are randomly picked and ordered every time you load a test.

This is a study tool. The 3 wrong answers for each question are randomly chosen from answers to other questions. So, you might find at times the answers obvious, but you will see it re-enforces your understanding as you take the test each time.
1. A description of the requirements management process.






2. A team activity that seeks to produce a broad or diverse set of options through the rapid and uncritical generation of ideas.






3. A cohesive bundle of externally visible functionality that should align with business goals and objectives. Each is a logically related grouping of functional requirements or non-functional requirements described in broad strokes.






4. A set of user stories requirements or features that have been identified as candidates for potential implementation prioritized and estimated.






5. An approach to decision-making that examines and models the possible consequences of different decisions. Assists in making an optimal decision under conditions of uncertainty.






6. Requirements that have been shown to demonstrate the characteristics of requirements quality and as such are cohesive complete consistent correct feasible modifiable unambiguous and testable.






7. A systematic approach to elicit information from a person or group of people in an informal or formal setting by asking relevant questions and documenting the responses.






8. A model that defines the boundaries of a business domain or solution.






9. A stakeholder who provides products or services to an organization.






10. A prototype developed to explore or verify requirements.






11. A group of related information to be stored by the system. Can be people roles places things organizations occurrences in time concepts or documents.






12. A subset of the enterprise architecture that defines an organization's current and future state including its strategy its goals and objectives the internal environment through a process or functional view the external environment in which the busine






13. Metadata related to a requirement used to assist with requirements development and management.






14. A requirements workshop is a structured meeting in which a carefully selected group of stakeholders collaborate to define and or refine requirements under the guidance of a skilled neutral facilitator.






15. A diagramming technique used in root cause analysis to identify underlying causes of an observed problem and the relationships that exist between those causes.






16. A high-level informal short description of a solution capability that provides value to a stakeholder. Is typically one or two sentences long and provides the minimum information necessary to allow a developer to estimate the work required to impleme






17. The work to identify the stakeholders who may be impacted by a proposed initiative and assess their interests and likely participation.






18. A description of an organization's business processes IT software and hardware people operations and projects and the relationships between them.






19. A type of high-level business requirement that is a statement of a business objective or an impact the solution should have on its environment.






20. A brief statement or paragraph that describes the problems in the current state and clarifies what a successful solution will look like.






21. A data element with a specified data type that describes information associated with a concept or entity.






22. Any unique and verifiable work product or service that a party has agreed to deliver.






23. A quality control technique. They may include a standard set of quality elements that reviewers use for requirements verification and requirements validation or be specifically developed to capture issues of concern to the project.






24. An iteration that defines requirements for a subset of the solution scope. Would include identifying a part of the overall product scope to focus upon identifying requirements sources for that portion of the product analyzing stakeholders and plannin






25. A practitioner of business analysis.






26. A prototype that is continuously modified and updated in response to feedback from users.






27. A group or person who has interests that may be affected by an initiative or influence over it.






28. A characteristic of a solution that meets the business and stakeholder requirements. May be subdivided into functional and non-functional requirements.






29. The activities that control requirements development including requirements change control requirements attributes definition and requirements traceability.






30. A system trigger that is initiated by humans.






31. Analysis done to compare and quantify the financial and non-financial costs of making a change or implementing a solution compared to the benefits gained.






32. Statements of the needs of a particular stakeholder or class of stakeholders. They describe the needs that a given stakeholder has and how that stakeholder will interact with a solution. Serve as a bridge between business requirements and the various






33. A description of the planned activities that the business analyst will execute in order to perform the business analysis work involved in a specific initiative.






34. A brief statement or paragraph that describes the why what and who of the desired software product from a business point of view.






35. A stakeholder responsible for assessing the quality of and identifying defects in a software application.






36. The number of employees a manger is directly (or indirectly) responsible for.






37. An analysis model that depicts the logical structure of data independent of the data design or data storage mechanisms.






38. Requirements that have been demonstrated to deliver business value and to support the business goals and objectives.






39. Any methodology that emphasizes planning and formal documentation of the processes used to accomplish a project and of the results of the project. Emphasize the reduction of risk and control over outcomes over the rapid delivery of a solution.






40. A validation technique in which a small group of stakeholders evaluates a portion of a work product to find errors to improve its quality.






41. The stakeholder assigned by the performing organization to manage the work required to achieve the project objectives.






42. The problem area undergoing analysis.






43. The work that must be performed to deliver a product service or result with the specified features and functions.






44. A process in which a deliverable (or the solution overall) is progressively elaborated upon. Will result in a self-contained "mini-project" in which a set of activities are undertaken resulting in the development of a subset of project deliverables.






45. A graphical representation of the entities relevant to a chosen problem domain the relationships between them and their attributes.






46. A matrix used to track requirements' relationships. Each column in the matrix provides requirements information and associated project or software development components.






47. An analysis model showing the life cycle of a data entity or class.






48. The process of checking a product to ensure that it satisfies its intended use and conforms to its requirements. Ensures that you built the correct solution.






49. The process of apportioning requirements to subsystems and components (i.e. people hardware and software).






50. The ability to identify and document the lineage of each requirement including its derivation (backward traceability) its allocation (forward traceability) and its relationship to other requirements.