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






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






3. An analysis model that illustrates processes that occur along with the flows of data to and from those processes.






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






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






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






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






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






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






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






11. A practitioner of business analysis.






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






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






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






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. Information that is used to understand the context and validity of information recorded in a system.






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






18. A methodology that focuses on rapid delivery of solution capabilities in an incremental fashion and direct involvement of stakeholders to gather feedback on the solution's performance.






19. A specific actionable testable directive that is under the control of the business and supports a business policy.






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






21. An error in requirements caused by incorrect incomplete missing or conflicting requirements.






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






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






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 representation and simplification of reality developed to convey information to a specific audience to support analysis communication and understanding.






26. A stakeholder responsible for assessing the quality of and identifying defects in a software application.






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






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






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






30. Any unique and verifiable work product or service that a party has agreed to deliver.






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






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






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






34. An analysis model that depicts the logical structure of data independent of the data design or data storage mechanisms.






35. The problem area undergoing analysis.






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






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






38. A target or metric that a person or organization seeks to meet in order to progress towards a goal.






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






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






41. Defining whether or not a relationship between entities in a data model is mandatory. Is shown on a data model with a special notation.






42. A team activity that seeks to produce a broad or diverse set of options through the rapid and uncritical generation of ideas.






43. A diagramming technique used in root cause analysis to identify underlying causes of an observed problem and the relationships that exist between those causes.






44. An uncertain event or condition that if it occurs will affect the goals or objectives of a proposed change.






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






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






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






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






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






50. A stakeholder who authorizes or legitimizes the product development effort by contracting for or paying for the project.