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. The set of capabilities a solution must deliver in order to meet the business need.






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






3. A collection of interrelated elements that interact to achieve an objective. Elements can include hardware software and people.






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






5. A non-proprietary modeling and specification language used to specify visualize and document deliverables for object-oriented software-intensive systems.






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 means to elicit ideas and attitudes about a specific product service or opportunity in an interactive group environment. The participants share their impressions preferences and needs guided by a moderator.






8. A software tool that stores requirements information in a database captures requirements attributes and associations and facilitates requirements reporting.






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






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






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






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






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






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






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






16. All materials used by groups within an organization to define tailor implement and maintain their processes.






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






18. Defining whether or not a relationship between entities in a data model is mandatory. Is shown on a data model with a special notation.






19. A point-in-time view of requirements that have been reviewed and agreed upon to serve as a basis for further development.






20. A continuous process of collecting data to determine how well a solution is implemented compared to expected results. See also metric and indicator.






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






22. A function of an organization that enables it to achieve a business goal or objective.






23. Interfaces with other systems (hardware software and human) that a proposed system will interact with.






24. The business rules an organization chooses to enforce as a matter of policy. They are intended to guide the actions of people working within the business. They may oblige people to take certain actions prevent people from taking actions or prescribe






25. A prototype developed to explore or verify requirements.






26. Ability of systems to communicate by exchanging data or services.






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






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






29. A classification of requirements that describe capabilities that the solution must have in order to facilitate transition from the current state of the enterprise to the desired future state but that will not be needed once that transition is complet






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






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






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






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






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






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






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






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






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






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






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






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






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






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






44. A system trigger that is initiated by humans.






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






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






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






48. A shared boundary between any two persons and/or systems through which information is communicated.






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






50. A conceptual view of all or part of an enterprise focusing on products deliverables and events that are important to the mission of the organization. Is useful to validate the solution scope with the business and technical stakeholders. See also mode