DD1363, Mjukvarukonstruktion

Aktuell kursomgång: period 2-4 07/08

Kursledare: Rand Waltzman
Datorpostadress(er): rand@nada.kth.se

Use Cases/Requirements Review Instructions

You will review the uses cases, functional and non-functional requirements for 2 other groups. These reviews will not be anonymous – you must stand for what you say. This page contains instructions on how to do the reviews and the exact format of the form that you will fill out for each review. You will then send a copy of each review in a pdf file to the respective group coordinators of the uses cases and requirements you review and one copy of both reviews, combined into a single pdf file, to us. Each pdf file should be called “UseCasesRequirementsReviewGroup<X>”. The addresses of the group coordinators can be found here.

State whether each statement below is true or false for 4 use cases of your choice (this is, for each group - if the group did not include 4 uses cases, analyze as many as there are). If it is false, you must explain why with an example.

1. The use-case title is an active-verb goal phrase that names the goal of the primary actor.

2. The primary actor has a well defined behavior.

3. The primary actor has a goal against the system under discussion (SuD) that is a service promise of the SuD.

4. The preconditions of the use case are clearly stated.

5. The preconditions are never checked during the use case.

6. The stakeholders are clearly identified.

7. The stakeholders’ interests are protected in the minimal guarantee.

8. The stakeholders’ interests are satisfied in the success guarantee.

9. The main success scenario has approximately 3-9 steps.

10. The main success scenario runs from trigger to delivery of the success guarantee.

11. The main success scenario permits the right variations in sequencing.

12. Each step in any scenario is phrased as a goal that succeeds.

13. It is clear which actor is operating the goal in each step of each scenario.

14. The intent of the actor is clear in each step of each scenario.

15. Each step of each scenario is at about the same level of detail.

16. There is no reference to the user interface in any step of any scenario.

17. Steps “validate”, as opposed to “check”, conditions.

18. The system both detects and handles each extension condition.

19. After the system is complete, it will be possible to check to see whether the use case accurately describes a behavior that is delivered.

Review the complete set of requirements and say whether or not each of the following conditions is satisfied. For each condition not satisfied, give as many examples as you can that show where the group went wrong.

1. Each requirement is written in consistent, clear, concise language.

2. Each requirement has only one interpretation. If a term could have multiple meanings, it is clearly defined.

3. Related requirements are grouped together.

4. All relevant dependencies are provided for each requirement that does not stand on its own.

5. Each requirement is actually a requirement and not a design or implementation solution.

6. Each functional requirement specifies input and output, as well as function, as appropriate.

7. Expected behavior is specified for all anticipated error conditions.

8. Each requirement is realistically verifiable by testing, demonstration, review, or analysis.

9. Each requirement, on its own, includes enough information to allow a test to be defined.

10. Each functional requirement has an associated test.

11. There are no requirements that apply to the system as a whole.

12. There are no requirements that exclude a specific type of behavior.

13. Each requirement can be changed without a large impact on other requirements.

14. The requirements provide an adequate basis for design and system test.

Although this list is not exhaustive, it will do for a start.

The exact format of the review will be as follows:

<Your Name>

Reviews of Use Cases for Group <X>

[For each use case:]

<Use Case Title>

1. <true or false>

<If false, explanation>

2. …

Requirements Review

1. <condition satisfied or not satisfied>

<If not satisfied, explanation>

2. …

The Use Cases/Requirements for review are listed below. The algorithm for deciding which Use Cases/Requirements you are supposed to review is simple. If you are in Group N, you will review Use Cases/Requirements from Groups N+1 and N+2 (cycle back to Group 1 if this algorithm puts you past Group 24). The only exception to this rule is that Group 15 is missing. Simply skip over that group to 16 if you are supposed to do 15. Even though all members of each group review the same set of Use Cases/Requirements, you are on your honor to write the reviews individually. Once they are written and submitted, feel free to discuss the reviews with the others members of your group to compare notes.

Use Cases/Requirements Group 1

Use Cases/Requirements Group 2

Use Cases/Requirements Group 3

Use Cases/Requirements Group 4

Use Cases/Requirements Group 5

Use Cases/Requirements Group 6

Use Cases/Requirements Group 7

Use Cases/Requirements Group 8

Use Cases/Requirements Group 9

Use Cases/Requirements Group 10

Use Cases/Requirements Group 11

Use Cases/Requirements Group 12