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 graphical representation of the entities relevant to a chosen problem domain the relationships between them and their attributes.






2. A type of diagram defined by UML that captures all actors and use cases involved with a system or product.






3. A higher level business rationale that when addressed will permit the organization to increase revenue avoid costs improve service or meet regulatory requirements.






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






5. A technique that subdivides a problem into its component parts in order to facilitate analysis and understanding of those components.






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






7. A stakeholder person device or system that directly or indirectly accesses a system.






8. A small group of stakeholders who will make decisions regarding the disposition and treatment of changing requirements.






9. The product capabilities or things the product must do for its users.






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






11. Software developed and sold for a particular market.






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






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






14. A temporary endeavor undertaken to create a unique product service or result.






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






16. Analysis of discrepancies between planned and actual performance to determine the magnitude of those discrepancies and recommend corrective and preventative action as required.






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






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






19. A prototype developed to explore or verify requirements.






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






21. A list and definition of the business terms and concepts relevant to the solution being built or enhanced.






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






23. Roles and Responsibility DesignationA listing of the stakeholders affected by a business need or proposed solution and a description of their participation in a project or other initiative.






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






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






26. An actor who participates in but does not initiate a use case.






27. A person with specific expertise in an area or domain under investigation.






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






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






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






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






32. Influencing factors that are believed to be true but have not been confirmed to be accurate.






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






34. A generic name for a role with the responsibilities of developing and managing requirements. Other names include business analyst business integrator requirements analyst requirements engineer and systems analyst.






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






36. The number of occurrences of one entity in a data model that are linked to a second entity. Is shown on a data model with a special notation number (e.g. 1) or letter (e.g. M for many).






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






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






39. A prototype used to quickly uncover and clarify interface requirements using simple tools sometimes just paper and pencil. Usually discarded when the final system has been developed.






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






41. An analysis model in table format that defines the events (i.e. the input stimuli that trigger the system to carry out some function) and their responses.






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






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






44. A deliverable-oriented hierarchical decomposition of the work to be executed by the project team to accomplish the project objectives and create the required deliverables. It organizes and defines the total scope of the project.






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






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






47. A description of the types of communication the business analyst will perform during business analysis the recipients of those communications and the form in which communication should occur.






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






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






50. Something that occurs to which an organizational unit system or process must respond.