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. Any recognized association of people in the context of an organization or enterprise.






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






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






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






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






7. An informal solicitation of proposals from vendors.






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






9. Assesses the effects that a proposed change will have on a stakeholder or stakeholder group project or system.






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






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






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






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






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






15. An approach to decision-making that examines and models the possible consequences of different decisions. Assists in making an optimal decision under conditions of uncertainty.






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






17. The set of tasks and techniques used to work as a liaison among stakeholders in order to understand the structure policies and operations of an organization and recommend solutions that enable the organization to achieve its goals.






18. An assessment that describes whether stakeholders are prepared to accept the change associated with a solution and are able to use it effectively.






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






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






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






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






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






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






25. Software developed and sold for a particular market.






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






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






29. All materials used by groups within an organization to define tailor implement and maintain their processes.






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






31. A deliverable-oriented hierarchical decomposition of the work to be executed by the project team to accomplish the project objectives and create the required deliverables. It organizes and defines the total scope of the project.






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






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






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






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






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






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






38. A system of programming statements symbols and rules used to represent instructions to a computer.






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






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






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






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






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






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






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






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






47. A fixed period of time to accomplish a desired outcome.






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






49. The work done to evaluate requirements to ensure they are defined correctly and are at an acceptable level of quality. It ensures the requirements are sufficiently defined and structured so that the solution development team can use them in the desig






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