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. An analysis model describing the data structures and attributes needed by the system.






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






3. Activities performed to ensure that a process will deliver products that meet an appropriate level of quality.






4. The set of tasks and techniques used to work as a liaison among stakeholders in order to understand the structure policies and operations of an organization and recommend solutions that enable the organization to achieve its goals.






5. The human and nonhuman roles that interact with the system.






6. A use case composed of a common set of steps used by multiple use cases.






7. A set of processes rules templates and working methods that prescribe how business analysis solution development and implementation is performed in a particular context.






8. 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






9. An analysis model that provides a graphical alternative to decision tables by illustrating conditions and actions in sequence.






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






11. An approach to software engineering where software is comprised of components that are encapsulated groups of data and functions which can inherit behavior and attributes from other components; and whose components communicate via messages with one a






12. An informal solicitation of proposals from vendors.






13. A deficiency in a product or service that reduces its quality or varies from a desired attribute state or functionality.






14. A group of related tasks that support a key function of business analysis.






15. A unit of work performed as part of an initiative or process.






16. 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.






17. Limitations on the design of a solution that derive from the technology used in its implementation.






18. A practitioner of business analysis.






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






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






21. An assessment that describes whether stakeholders are prepared to accept the change associated with a solution and are able to use it effectively.






22. An analysis model that describes a series of actions or tasks that respond to an event. Each is an instance of a use case.






23. A stakeholder who uses products or services delivered by an organization.






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






25. 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.






26. The quality attributes design and implementation constraints and external interfaces that the product must have.






27. A structured examination of an identified problem to understand the underlying causes.






28. A comparison of a process or system's cost time quality or other metrics to those of leading peer organizations to identify opportunities for improvement.






29. A requirements package that describes business requirements and stakeholder requirements (it documents requirements of interest to the business rather than documenting business requirements).






30. A measure of the profitability of a project or investment.






31. 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






32. A requirements document written primarily for Implementation SMEs describing functional and nonfunctional requirements.






33. A representation of requirements using text and diagrams. Can also be called user requirements models or analysis models and can supplement textual requirements specifications.






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






35. A graphical method for depicting the forces that support and oppose a change. Involves identifying the forces depicting them on opposite sides of a line (supporting and opposing forces) and then estimating the strength of each set of forces.






36. A stakeholder who authorizes or legitimizes the product development effort by contracting for or paying for the project.






37. 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.






38. The process of checking that a deliverable produced at a given stage of development satisfies the conditions or specifications of the previous stage. Ensures that you built the solution correctly.






39. A state or condition the business must satisfy to reach its vision.






40. Tests written without regard to how the software is implemented. These tests show only what the expected input and outputs will be.






41. The area covered by a particular activity or topic of interest.






42. A means to elicit requirements by conducting an assessment of the stakeholder's work environment.






43. A type of peer review in which participants present discuss and step through a work product to find errors. Are used to verify the correctness of requirements.






44. An evaluation of proposed alternatives to determine if they are technically possible within the constraints of the organization and whether they will deliver the desired benefits to the organization.






45. A business model that shows the organizational context in terms of the relationships that exist among the organization external customers and providers.






46. A description of the requirements management process.






47. Assesses the effects that a proposed change will have on a stakeholder or stakeholder group project or system.






48. A formal type of peer review that utilizes a predefined and documented process specific participant roles and the capture of defect and process metrics. See also structured walkthrough.






49. 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.






50. Are responsible for the construction of software applications. Areas of expertise include development languages development practices and application components.