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






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






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






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






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






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






7. A requirements document written primarily for Implementation SMEs describing functional and nonfunctional requirements.






8. A requirements document issued when an organization is seeking a formal proposal from vendors. Typically requires that the proposals be submitted following a specific process and using sealed bids which will be evaluated against a formal evaluation m






9. A condition or capability that must be met or possessed by a solution or solution component to satisfy a contract standard specification or other formally imposed documents.






10. Any effort undertaken with a defined goal or objective.






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






12. A graphical method for depicting the forces that support and oppose a change. Involves identifying the forces depicting them on opposite sides of a line (supporting and opposing forces) and then estimating the strength of each set of forces.






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






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






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






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






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






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






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






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






21. A real or virtual facility where all information on a specific topic is stored and is available for retrieval.






22. Determine when something is or is not true or when things fall into a certain category. They describe categorizations that may change over time.






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






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






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






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






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






28. A system trigger that is initiated by humans.






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






30. A matrix used to track requirements' relationships. Each column in the matrix provides requirements information and associated project or software development components.






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






32. The problem area undergoing analysis.






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






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






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 cohesive bundle of externally visible functionality that should align with business goals and objectives. Each is a logically related grouping of functional requirements or non-functional requirements described in broad strokes.






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






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






39. A partial or preliminary version of the system.






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






41. A descriptor for a set of system objects that share the same attributes operations relationships and behavior. Represents a concept in the system under design. When used as an analysis model a class will generally also correspond to a real-world enti






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






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






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






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






46. An informal solicitation of proposals from vendors.






47. A group of related information to be stored by the system. Can be people roles places things organizations occurrences in time concepts or documents.






48. An analysis model that describes a series of actions or tasks that respond to an event. Each is an instance of a use case.






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






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