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 brief statement or paragraph that describes the why what and who of the desired software product from a business point of view.






2. A subset of the enterprise architecture that defines an organization's current and future state including its strategy its goals and objectives the internal environment through a process or functional view the external environment in which the busine






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






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






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






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






7. An organizational unit organization or collection of organizations that share a set of common goals and collaborate to provide specific products or services to customers.






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






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






10. Software developed and sold for a particular market.






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






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






13. Limitations placed on the solution design by the organization that needs the solution. Describe limitations on available solutions or an aspect of the current state that cannot be changed by the deployment of the new solution. See also technical cons






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






15. A structured process which captures the key characteristics of an industry to predict the long-term profitability prospects and to determine the practices of the most significant competitors.






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






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






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






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






20. An analysis model that provides a graphical alternative to decision tables by illustrating conditions and actions in sequence.






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






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






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






24. A condition or capability needed by a stakeholder to solve a problem or achieve an objective.






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






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






27. Identifies a specific numerical measurement that indicates progress toward achieving an impact output activity or input. See also metric.






28. A practitioner of business analysis.






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






30. A unit of work performed as part of an initiative or process.






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






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






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






34. A system trigger that is initiated by humans.






35. A continuous process of collecting data to determine how well a solution is implemented compared to expected results. See also metric and indicator.






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






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






38. A process improvement technique used to learn about and improve on a process or project. Involves a special meeting in which the team explores what worked what didn't work what could be learned from the just-completed iteration and how to adapt proce






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






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






41. Describes any limitations imposed on the solution that do not support the business or stakeholder needs.






42. A person with specific expertise in an area or domain under investigation.






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






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






45. A person or system that directly interacts with the solution. Can be humans who interface with the system or systems that send or receive data files to or from the system.






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






47. The problem area undergoing analysis.






48. A representation and simplification of reality developed to convey information to a specific audience to support analysis communication and understanding.






49. A partial or preliminary version of the system.






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