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






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






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






4. A document issued by the project initiator or sponsor that formally authorizes the existence of a project and provides the project manager with the authority to apply organizational resources to project activities.






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






6. A stakeholder who will be responsible for designing developing and implementing the change described in the requirements and have specialized knowledge regarding the construction of one or more solution components.






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






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






9. A stakeholder who helps to keep the solution functioning either by providing support to end users (trainers help desk) or by keeping the solution operational on a day-to-day basis (network and other tech support).






10. A structured process which captures the key characteristics of an industry to predict the long-term profitability prospects and to determine the practices of the most significant competitors.






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






12. A document or collection of notes or diagrams used by the business analyst during the requirements development process.






13. A type of diagram that shows objects participating in interactions and the messages exchanged between them.






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






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






16. A stakeholder with specific expertise in an aspect of the problem domain or potential solution alternatives or components.






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






18. A prototype that dives into the details of the interface functionality or both.






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






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






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






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






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






24. An informal solicitation of proposals from vendors.






25. An analysis model that describes the tasks that the system will perform for actors and the goals that the system achieves for those actors along the way.






26. A stakeholder with legal or governance authority over the solution or the process used to develop it.






27. A set of written questions to stakeholders in order to collect responses from a large group in a relatively short period of time.






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






29. Formal approval of a set of requirements by a sponsor or other decision maker.






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






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






32. Work carried out or on behalf of others.






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






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






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






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






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






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






39. A means to elicit requirements of an existing system by studying available documentation and identifying relevant information.






40. An error in requirements caused by incorrect incomplete missing or conflicting requirements.






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






42. A description of the requirements management process.






43. The problem area undergoing analysis.






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






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






46. The degree to which a set of inherent characteristics fulfills requirements.






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






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






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






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