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 set of written questions to stakeholders in order to collect responses from a large group in a relatively short period of time.






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






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






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






5. The features and functions that characterize a product service or result.






6. A condition or capability needed by a stakeholder to solve a problem or achieve an objective.






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






8. A fixed period of time to accomplish a desired outcome.






9. A defined association between concepts classes or entities. Usually named and include the cardinality of the association.






10. Test cases that users employ to judge whether the delivered system is acceptable. Each acceptance test describes a set of system inputs and expected results.






11. The analysis technique used to describe roles responsibilities and reporting structures that exist within an organization.






12. A requirements document written for a user audience describing user requirements and the impact of the anticipated changes on the users.






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






14. A set of requirements grouped together in a document or presentation for communication to stakeholders.






15. An analysis model describing the data structures and attributes needed by the system.






16. A solution or component of a solution that is the result of a project.






17. A set of defined ad-hoc or sequenced collaborative activities performed in a repeatable fashion by an organization. Are triggered by events and may have multiple possible outcomes. A successful outcome of a process will deliver value to one or more s






18. Limitations placed on the solution design by the organization that needs the solution. Describe limitations on available solutions or an aspect of the current state that cannot be changed by the deployment of the new solution. See also technical cons






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






20. An uncertain event or condition that if it occurs will affect the goals or objectives of a proposed change.






21. A descriptor for a set of system objects that share the same attributes operations relationships and behavior. Represents a concept in the system under design. When used as an analysis model a class will generally also correspond to a real-world enti






22. The process of examining new business opportunities to improve organizational performance.






23. The subset of nonfunctional requirements that describes properties of the software's operation development and deployment (e.g. performance security usability portability and testability).






24. The systematic and objective assessment of a solution to determine its status and efficacy in meeting objectives over time and to identify ways to improve the solution to better meet objectives. See also metric indicator and monitoring.






25. An activity within requirements development that identifies sources for requirements and then uses elicitation techniques (e.g. interviews prototypes facilitated workshops documentation studies) to gather requirements from those sources.






26. Any effort undertaken with a defined goal or objective.






27. A description of the requirements management process.






28. A partial or preliminary version of the system.






29. An analysis model that specifies complex business rules or logic concisely in an easy-to-read tabular format specifying all of the possible conditions and actions that need to be accounted for in business rules.






30. Software requirements that limit the options available to the system designer.






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






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






33. Software developed and sold for a particular market.






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






35. Creating working software in multiple releases so the entire product is delivered in portions over time.






36. The set of processes templates and activities that will be used to perform business analysis in a specific context.






37. The horizontal or vertical section of a process model that show which activities are performed by a particular actor or role.






38. A link between two elements or objects in a diagram.






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






40. A system trigger that is initiated by time.






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






42. The set of capabilities a solution must deliver in order to meet the business need.






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






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






45. An analysis model that shows user interface dialogs arranged as hierarchies.






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






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






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






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






50. A specific actionable testable directive that is under the control of the business and supports a business policy.