Quiz 3 solutions
Upcoming SlideShare
Loading in...5
×

Like this? Share it with your network

Share
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
395
On Slideshare
395
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
6
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Software Engineering Quiz # 3 Solutions MCQs Cutting and Overwriting is not allowed. 1. For which of the following practices does requirements engineering provides appropriate mechanisms and tools? a. Analyzing need b. Unambiguous specification of the solution c. validating the specification d. All of the above 2. Are requirements validation and analysis distinct requirements activities? a. Yes, because requirements validation needs a complete draft of the requirements document while the requirements analysis works with incomplete requirements. b. Yes, because requirements validation works with incomplete requirements while the requirements analysis needs a complete draft of the requirements document. c. Yes, because validation can only be done with testing while analysis can be done with prototyping. d. No, they are not distinct activities as they both work on requirements and aid in their elicitation. 3. Requirement Engineering is a generic process that does not vary from one software project to another. a. True b. False 4. Three things that make a requirements elicitation difficult are problems of a. budgeting b. scope c. understanding d. volatility e. b, c and d 5. It is relatively common for different customers to propose conflicting requirements, each arguing that his or her version is the right one. a. True b. False
  • 2. Short Answers Define the requirements engineering term “Stakeholder” and give some examples of stakeholders. A stakeholder is anyone who should have some direct or indirect influence on the system requirements. Examples of stakeholders are end-users who will interact with the system, clients who are paying for the system, system developers, and regulators such as standards bodies, domain experts such as aeronautics engineers in an autopilot SW project. Would a „multi choice questionnaire‟ be a good tool for requirements elicitation? Why or Why not? No. The MCQ will be too skewed towards the viewpoint of the person who composes it. A good RE process aims to elicit the views of all the different stakeholders in the project. A MCQ would not allow new requirements to be suggested during the elicitation process or for stakeholders to give non-standard answers. A MCQ will be written in the language of the author and may be misunderstood by different stakeholders, who then have no forum to clarify misunderstandings. Aside: Since it is easy to process results, MCQ would be good for gaining opinions from a large number of users once initial requirements had been elicited and analyzed. Might be good in the requirements validation phase. Give an Example of ‘unverifiable requirement’, and then rewrite that requirement so that it is verified. Unverifiable: •The software must be developed in such a way that it can be used by inexperienced users. Verifiable: 90% of new users from the XXX Department, will be able to score 75% or more in the system tutorial test (see appendix A) after attending a 4 hour initial training workshop (see appendix B). Aside: A requirement is verifiable iff there is some finite cost-effective way in which a person or machine can check to see if the SW product meets the requirement. (Note, unverifiable is not the same as ambiguous)