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






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






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






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






5. An organized peer review of a deliverable with the objective of finding errors and omissions. It is considered a form of quality assurance.






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






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






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






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






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






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






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






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






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






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






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






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






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






19. Software developed and sold for a particular market.






20. The work done to evaluate requirements to ensure they are defined correctly and are at an acceptable level of quality. It ensures the requirements are sufficiently defined and structured so that the solution development team can use them in the desig






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






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






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






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






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






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






27. Work carried out or on behalf of others.






28. A requirements document issued to solicit vendor input on a proposed process or product. Is used when the issuing organization seeks to compare different alternatives or is uncertain regarding the available options






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






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






31. An autonomous unit within an enterprise under the management of a single individual or board with a clearly defined boundary that works towards common goals and objectives. Operate on a continuous basis as opposed to an organizational unit or project






32. An informal solicitation of proposals from vendors.






33. A requirement articulated by a stakeholder that has not been analyzed verified or validated. Frequently reflect the desires of a stakeholder rather than the actual need.






34. A process in which a deliverable (or the solution overall) is progressively elaborated upon. Will result in a self-contained "mini-project" in which a set of activities are undertaken resulting in the development of a subset of project deliverables.






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






36. A system trigger that is initiated by humans.






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






38. A requirements workshop is a structured meeting in which a carefully selected group of stakeholders collaborate to define and or refine requirements under the guidance of a skilled neutral facilitator.






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






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






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






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






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






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






45. An organizational unit organization or collection of organizations that share a set of common goals and collaborate to provide specific products or services to customers.






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






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






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






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






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