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. Alter the way a business analysis task is performed or describe a specific form the output of a task may take.






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






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






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






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






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






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






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






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






10. A business model that shows a business process in terms of the steps and input and output flows across multiple functions organizations or job roles.






11. A validation technique in which a small group of stakeholders evaluates a portion of a work product to find errors to improve its quality.






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






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






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






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






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






17. An iteration that defines requirements for a subset of the solution scope. Would include identifying a part of the overall product scope to focus upon identifying requirements sources for that portion of the product analyzing stakeholders and plannin






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 use case composed of a common set of steps used by multiple use cases.






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






21. A partial or preliminary version of the system.






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






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






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






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






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






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






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. A means to elicit requirements by conducting an assessment of the stakeholder's work environment.






30. A defined association between concepts classes or entities. Usually named and include the cardinality of the association.






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






32. An analysis model that illustrates the architecture of the system's user interface.






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 measure of the profitability of a project or investment.






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






36. A quantifiable level of an indicator that an organization wants to accomplish at a specific point in time.






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






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






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






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






42. A non-actionable directive that supports a business goal.






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






44. A comparison of the current state and desired future state of an organization in order to identify differences that need to be addressed.






45. A characteristic of a solution that meets the business and stakeholder requirements. May be subdivided into functional and non-functional requirements.






46. A description of the requirements management process.






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






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






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






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







Sorry!:) No result found.

Can you answer 50 questions in 15 minutes?


Let me suggest you:

Browse all subjects

Browse all tests

Most popular tests



Major Subjects

Tests & Exams


AP
CLEP
DSST
GRE
SAT
GMAT

Browse all subjects

Browse all tests

Most popular tests