Perspective-based Scenarios

The efficiency of this reading technique is determined by the scenarios. A scenario describes certain activities that should be performed by the reader while reading the documents. In addition to the activities the scenario contains some questions dealing with the activity.
To be much more precise, a scenario is a collection of procedures that operationalize strategies for detecting defects.
It could be argued that scenarios are another kind of checklist. A checklist is a set of questions or statements without any hint or procedural description of how to read a document. As there is no description in checklists, scenarios have to be separated from them.
The question is how to generate ``good'' scenarios?
The model we use is an abstract description of the different roles in the software development process. The different roles together with a set of questions for each of this roles will determine the scenarios we use for perspective-based reading.
Now the interesting point is:

• Which questions are necessary to support the different roles (in an abstract form and as far as the NASA-process is concerned)?
• What about the degree of ``completeness'' of the questions and activities?

• There are several levels of abstraction in a requirement document (e.g. you can look at the whole system which is described by the requirement-document or you can only look at a function)
• There exists no standard for documenting requirements. A requirement-document can contain:
  • Brief outline
  • Definitions (I/O)
  • Functional Requirements, Functions Algorithms
  • Other aspects that are important for the system...
• Within each role, e.g. tester, several different methods or techniques for testing can be used.

The starting point was an abstract model of the software development process. Each role within this process was characterized by a set of high level activities, e.g. ``Make up the testcases'' for the tester. Then we looked at the NASA process to see how they perform the activities (if at all!). In order to ensure that we can find all the defects, we have used a defect classification scheme. The classification scheme provides some question for each defect class. The next step was that we assigned question to each activity of a role about the results of the activity or the activity itself.
Throughout the development of the scenarios we there were several questions left open:

1. What is the level of detail which is necessary to support the reader? If the scenario is too detailed it will become much more of a checklist than it was intended. If the scenario in not detailed enough it won't provide any help.
2. What are the really important questions that can expose classes of defects while performing the activities of each role?
3. To what extent should the scenario be tailored to a specific environment?

• Defect-based-reading
  To derive a scenario for defect-based reading a defect classification scheme was used as a model. The questions to find the defects of a specific class were derived from a checklist.
  

  

• Perspective-based-reading
  To derive a scenario for perspective-based reading the different roles within the software development process were used as a model. In addition and as a refinement of the roles questions characterizing each defect class were used.

  

Web Accessibility