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. Metadata related to a requirement used to assist with requirements development and management.






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






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






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






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






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






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






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






9. A system trigger that is initiated by time.






10. The work done to ensure that the stated requirements support and are aligned with the goals and objectives of the business.






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






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






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






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






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






16. The business benefits that will result from meeting the business need and the end state desired by stakeholders.






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






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






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






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






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






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






23. A practitioner of business analysis.






24. A deficiency in a product or service that reduces its quality or varies from a desired attribute state or functionality.






25. A partial or preliminary version of the system.






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






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






28. Information that is used to understand the context and validity of information recorded in a system.






29. A formal type of peer review that utilizes a predefined and documented process specific participant roles and the capture of defect and process metrics. See also structured walkthrough.






30. Strengths Weaknesses Opportunities and Threats. It is a model used to understand influencing factors and how they may affect an initiative.






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






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






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






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






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






36. An analysis model that illustrates product scope by showing the system in its environment with the external entities (people and systems) that give to and receive from the system.






37. Requirements that have been demonstrated to deliver business value and to support the business goals and objectives.






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






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






40. An analysis of requirements-related risks that ranks risks and identifies actions to avoid or minimize those risks.






41. The stakeholder assigned by the performing organization to manage the work required to achieve the project objectives.






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






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






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






45. Software developed and sold for a particular market.






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






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






48. A description of the requirements management process.






49. Meets a business need by resolving a problem or allowing an organization to take advantage of an opportunity.






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