181) Requirements specified are incorrect or inappropriate. Which of the below could be root causes?
a. The wrong user representatives or inappropriate surrogates are involved
b. User representatives speak for themselves, not for those they represent
c. Managers do not provide access to user representatives
d. Business requirements are not clearly established
182) All requirements seem to be equally important. Which of the below could be root causes?
a. Fear that low-priority requirements will never be implemented.
b. Insufficient or evolving knowledge about the business and its needs.
c. The product isn’t usable unless a large, critical set of functionality is implemented.
d. Unreasonable customer or developer expectations
183) There are conflicting requirements priorities among stakeholders. Which of the below could be root causes?
a. Different user classes have conflicting needs
b. Lack of focus on the original product vision, or the vision evolves during the project
c. Unclear business objectives, or lack of agreement on business objectives
d. Changing business objectives
184) There are conflicting requirements priorities among stakeholders. Which of the below could be possible solutions?
a. Perform sufficient market research
b. Establish and communicate business objectives
c. Base priorities on vision, scope, and business objectives
d. Identify favored user classes or market segments
185) Rapid descoping late in the project could be resolved by:
a. Define priorities early on.
b. Use priorities to guide decisions about what to work on now and what to defer.
c. Reprioritize when new requirements are incorporated.
d. Adjust scope periodically, not just late in the project
186) Developers find requirements vague and ambiguous. They have to track down missing information and they misunderstand requirements and have to rework their implementations. This can possibly be avoided by:
a. Train BAs in writing good requirements.
b. Avoid using subjective, ambiguous words in requirements specifications.
c. Have developers and customers review requirements early for clarity and appropriate detail.
d. Model requirements to find missing information and enhance details.
187) Developers find requirements vague and ambiguous. They have to track down missing information and they misunderstand requirements and have to rework their implementations. This can possibly be avoided by:
a. Build prototypes and have users evaluate them.
b. Refine requirements in progressive levels of detail.
c. Document business rules.
d. Define terms in a glossary
188) Requirements contain TBDs, information gaps, and open issues. This can possibly be resolved by:
a. Review requirements to identify information gaps.
b. Assign responsibility for resolving each TBD or open issue to an individual.
c. Prioritize TBDs to be resolved if time is tight.
d. Track each TBD or open issue to closure before baselining a set of requirements.
189) Stakeholders assume that functionality in the existing system will be replicated in a new system. This can possibly be avoided by:
a. Reverse engineer the existing system to understand its full capabilities.
b. Write a requirements specification that includes all the desired functionality for the new system.
c. Build as-is and to-be process models so that stakeholders are clear on what the future system will and won’t do
d. Don’t replicate old functionality that might not be needed
190) Product doesn’t achieve business objectives or meet user expectations. This can possibly be avoided by:
a. Perform market research to understand market segments and their needs.
b. Engage product champions representing each user class throughout the duration of the project.
c. Have customers participate in requirements reviews.
d. Have users write acceptance tests and acceptance criteria.
191) Product does not achieve performance goals or satisfy other quality expectations that users have. The possible root causes are:
a. Quality attribute requirements were not elicited and specified.
b. Stakeholders don’t understand nonfunctional requirements and their importance.
c. The requirements template or tool being used doesn’t have sections for nonfunctional requirements.
d. Users don’t state their assumptions about the system’s quality characteristics
192) Product does not achieve performance goals or satisfy other quality expectations that users have. The possible solutions are:
a. Educate BAs and customers about nonfunctional requirements and how to specify them.
b. Have BAs explore nonfunctional requirements during elicitation.
c. Use an SRS template that includes sections for nonfunctional requirements.
d. Use Planguage to specify quality attributes precisely.
193) Some planned requirements were not implemented. The possible root causes could be:
a. Individual requirements were not discretely identified and labeled
b. Requirements were inadvertently overlooked during implementation.
c. Responsibilities for implementing requirements were not assigned.
d. The status of individual requirements was not tracked accurately
194) Some planned requirements were not implemented. The possible solutions could be:
a. Keep requirements current and make them available to the whole team.
b. Make sure the change control process includes communication to stakeholders.
c. Store requirements in a requirements management tool.
d. Track the status of individual requirements
195) Requirements move in and out of scope. The possible solutions could be:
a. Clearly define the business objectives, vision, and scope.
b. Use the scope statement to decide whether proposed requirements are in or out of scope.
c. Record the rationale for rejecting a proposed requirement.
d. Ensure that the change control board has the appropriate members and a shared understanding of project scope.
196) Requirements move in and out of scope. The possible root causes are:
a. Vision and scope are not clearly defined.
b. Business objectives are not clearly understood and communicated.
c. Scope is volatile, perhaps in response to changing market demands.
d. Requirements priorities are poorly defined.
197) People don’t know the scope or understand scope changes. The possible root causes are:
a. Requirements changes aren’t communicated to all affected stakeholders.
b. Requirements specifications aren’t updated when requirements change.
c. Customers request changes directly from developers.
d. Not everyone has ready access to the requirements documentation.
198) People don’t know the scope or understand scope changes. The possible solutions are:
a. Define an owner for each requirement.
b. Define trace links between requirements and other artifacts.
c. Include all affected areas in requirements communications.
d. Establish a change control process that includes the communication mechanisms.
199) Requirements changes take much more effort than planned. The possible root causes are:
a. Insufficient impact analysis of proposed requirements changes.
b. Developers underestimate the impact of requirements changes.
c. Team members are afraid to be honest about the impact of proposed changes.
d. Change requests do not provide enough information to permit good impact analysis.
200) Stakeholders bypass the change control process and customers request changes directly from developers. Possible root causes are:
a. Change control process isn’t practical and effective.
b. Change control board is ineffective.
c. Stakeholders don’t understand or accept the change control process.
d. Management doesn’t require that the change control process be followed
201) Stakeholders bypass the change control process and customers request changes directly from developers. Possible solutions are:
a. Ensure that the change control process is pragmatic, effective, efficient, and accessible to all stakeholders.
b. Make the change control process flexible in how it handles small versus large changes.
c. Establish and charter an appropriate change control board.
d. Enlist management to commit to and champion the change control process
a. The wrong user representatives or inappropriate surrogates are involved
b. User representatives speak for themselves, not for those they represent
c. Managers do not provide access to user representatives
d. Business requirements are not clearly established
182) All requirements seem to be equally important. Which of the below could be root causes?
a. Fear that low-priority requirements will never be implemented.
b. Insufficient or evolving knowledge about the business and its needs.
c. The product isn’t usable unless a large, critical set of functionality is implemented.
d. Unreasonable customer or developer expectations
183) There are conflicting requirements priorities among stakeholders. Which of the below could be root causes?
a. Different user classes have conflicting needs
b. Lack of focus on the original product vision, or the vision evolves during the project
c. Unclear business objectives, or lack of agreement on business objectives
d. Changing business objectives
184) There are conflicting requirements priorities among stakeholders. Which of the below could be possible solutions?
a. Perform sufficient market research
b. Establish and communicate business objectives
c. Base priorities on vision, scope, and business objectives
d. Identify favored user classes or market segments
185) Rapid descoping late in the project could be resolved by:
a. Define priorities early on.
b. Use priorities to guide decisions about what to work on now and what to defer.
c. Reprioritize when new requirements are incorporated.
d. Adjust scope periodically, not just late in the project
186) Developers find requirements vague and ambiguous. They have to track down missing information and they misunderstand requirements and have to rework their implementations. This can possibly be avoided by:
a. Train BAs in writing good requirements.
b. Avoid using subjective, ambiguous words in requirements specifications.
c. Have developers and customers review requirements early for clarity and appropriate detail.
d. Model requirements to find missing information and enhance details.
187) Developers find requirements vague and ambiguous. They have to track down missing information and they misunderstand requirements and have to rework their implementations. This can possibly be avoided by:
a. Build prototypes and have users evaluate them.
b. Refine requirements in progressive levels of detail.
c. Document business rules.
d. Define terms in a glossary
188) Requirements contain TBDs, information gaps, and open issues. This can possibly be resolved by:
a. Review requirements to identify information gaps.
b. Assign responsibility for resolving each TBD or open issue to an individual.
c. Prioritize TBDs to be resolved if time is tight.
d. Track each TBD or open issue to closure before baselining a set of requirements.
189) Stakeholders assume that functionality in the existing system will be replicated in a new system. This can possibly be avoided by:
a. Reverse engineer the existing system to understand its full capabilities.
b. Write a requirements specification that includes all the desired functionality for the new system.
c. Build as-is and to-be process models so that stakeholders are clear on what the future system will and won’t do
d. Don’t replicate old functionality that might not be needed
190) Product doesn’t achieve business objectives or meet user expectations. This can possibly be avoided by:
a. Perform market research to understand market segments and their needs.
b. Engage product champions representing each user class throughout the duration of the project.
c. Have customers participate in requirements reviews.
d. Have users write acceptance tests and acceptance criteria.
191) Product does not achieve performance goals or satisfy other quality expectations that users have. The possible root causes are:
a. Quality attribute requirements were not elicited and specified.
b. Stakeholders don’t understand nonfunctional requirements and their importance.
c. The requirements template or tool being used doesn’t have sections for nonfunctional requirements.
d. Users don’t state their assumptions about the system’s quality characteristics
192) Product does not achieve performance goals or satisfy other quality expectations that users have. The possible solutions are:
a. Educate BAs and customers about nonfunctional requirements and how to specify them.
b. Have BAs explore nonfunctional requirements during elicitation.
c. Use an SRS template that includes sections for nonfunctional requirements.
d. Use Planguage to specify quality attributes precisely.
193) Some planned requirements were not implemented. The possible root causes could be:
a. Individual requirements were not discretely identified and labeled
b. Requirements were inadvertently overlooked during implementation.
c. Responsibilities for implementing requirements were not assigned.
d. The status of individual requirements was not tracked accurately
194) Some planned requirements were not implemented. The possible solutions could be:
a. Keep requirements current and make them available to the whole team.
b. Make sure the change control process includes communication to stakeholders.
c. Store requirements in a requirements management tool.
d. Track the status of individual requirements
195) Requirements move in and out of scope. The possible solutions could be:
a. Clearly define the business objectives, vision, and scope.
b. Use the scope statement to decide whether proposed requirements are in or out of scope.
c. Record the rationale for rejecting a proposed requirement.
d. Ensure that the change control board has the appropriate members and a shared understanding of project scope.
196) Requirements move in and out of scope. The possible root causes are:
a. Vision and scope are not clearly defined.
b. Business objectives are not clearly understood and communicated.
c. Scope is volatile, perhaps in response to changing market demands.
d. Requirements priorities are poorly defined.
197) People don’t know the scope or understand scope changes. The possible root causes are:
a. Requirements changes aren’t communicated to all affected stakeholders.
b. Requirements specifications aren’t updated when requirements change.
c. Customers request changes directly from developers.
d. Not everyone has ready access to the requirements documentation.
198) People don’t know the scope or understand scope changes. The possible solutions are:
a. Define an owner for each requirement.
b. Define trace links between requirements and other artifacts.
c. Include all affected areas in requirements communications.
d. Establish a change control process that includes the communication mechanisms.
199) Requirements changes take much more effort than planned. The possible root causes are:
a. Insufficient impact analysis of proposed requirements changes.
b. Developers underestimate the impact of requirements changes.
c. Team members are afraid to be honest about the impact of proposed changes.
d. Change requests do not provide enough information to permit good impact analysis.
200) Stakeholders bypass the change control process and customers request changes directly from developers. Possible root causes are:
a. Change control process isn’t practical and effective.
b. Change control board is ineffective.
c. Stakeholders don’t understand or accept the change control process.
d. Management doesn’t require that the change control process be followed
201) Stakeholders bypass the change control process and customers request changes directly from developers. Possible solutions are:
a. Ensure that the change control process is pragmatic, effective, efficient, and accessible to all stakeholders.
b. Make the change control process flexible in how it handles small versus large changes.
c. Establish and charter an appropriate change control board.
d. Enlist management to commit to and champion the change control process
No comments:
Post a Comment