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. A prototype that shows a shallow and possibly wide view of the system's functionality but which does not generally support any actual use or interaction.






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






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






4. An activity within requirements development that identifies sources for requirements and then uses elicitation techniques (e.g. interviews prototypes facilitated workshops documentation studies) to gather requirements from those sources.






5. A quality control technique. They may include a standard set of quality elements that reviewers use for requirements verification and requirements validation or be specifically developed to capture issues of concern to the project.






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






7. A stakeholder who uses products or services delivered by an organization.






8. A comparison of a process or system's cost time quality or other metrics to those of leading peer organizations to identify opportunities for improvement.






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






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






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






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






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






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. A list and definition of the business terms and concepts relevant to the solution being built or enhanced.






16. The analysis technique used to describe roles responsibilities and reporting structures that exist within an organization.






17. Analysis done to compare and quantify the financial and non-financial costs of making a change or implementing a solution compared to the benefits gained.






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






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






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






21. An assessment of the costs and benefits associated with a proposed initiative.






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






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






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






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






26. Something that occurs to which an organizational unit system or process must respond.






27. A technique that subdivides a problem into its component parts in order to facilitate analysis and understanding of those components.






28. The activities that control requirements development including requirements change control requirements attributes definition and requirements traceability.






29. A visual model or representation of the sequential flow and control logic of a set of related activities or actions.






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






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






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






33. Work carried out or on behalf of others.






34. A description of the types of communication the business analyst will perform during business analysis the recipients of those communications and the form in which communication should occur.






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






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






37. A description of the planned activities that the business analyst will execute in order to perform the business analysis work involved in a specific initiative.






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






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






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






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






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






43. A partial or preliminary version of the system.






44. A practitioner of business analysis.






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






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






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






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






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






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