Lecture 4 - Specification and Validation Flashcards

1
Q

Why do Requirements need test?

A
  • An essential property of a software requirement is that it should be possible to show (validate) that the finished product satisfies it.
  • Requirements that cannot be validated are really just “wishes.”
  • An important task is therefore planning how to verify each requirement.
  • In most cases, acceptance tests are prescribed based on how end-users typically conduct business using the system.
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
2
Q

What is a Requirement Test?

A
  • A test for a requirement is a way to demonstrate whether a system satisfies the requirement.
  • Best to think about and write the tests at the same time as writing the requirement.
  • The test is a type of contract for that requirement
  • Example: The system must process 1000 transactions per minute
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
3
Q

Why do we need tester?

A
  • Engineers aren’t typically great at assessing the testability of requirements.
  • Agile deals with this by bringing testers in right from the start
  • (vs Waterfall when testers see everything much later in the process when it is often too late to change/fix the requirements as they are documented and agreed).
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
4
Q

Define Verifiable

A
  • Definition. A requirements spec is verifiable if (if and only if) every requirement statement is verifiable If there is some finite cost-effective way in which a person or machine can check to see if the SW product meets the requirement
  • We can use test cases, analysis or inspection to decide
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
5
Q

What are Objective Metrics for Non-Functional Requirements?

A

Performance Speed
– Number of processed transactions per second
– User/event response time
– Screen refresh time
Size
– Kilobytes
– Number of RAM chips
Example 3: The installed app requires less th
Reliability
– Time to re-start after system failure
– Percentage of events causing failure
– Probability of data corruption on failure
Robustness
– Time to re-start after system failure
– Percentage of events causing failure
– Probability of data corruption on failure
Integrity
– Maximum permitted data loss after system failure
Ease of Use
– Training time taken to learn 75% of user facilities
– Average number of errors made by users in a given time period
– Number of help frames
Portability
– Percentage of target-dependent statements
– Number of target systems

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
6
Q

What are System Requirements and why are the hard to test?

A

Requirements which apply to the system as a whole.
In general, these are the most difficult requirements to validate irrespective of the method used as they may be influenced by any of the functional requirements.
Hard to test for non-functional system-wide characteristics such as usability.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
7
Q

What are Exclusive Requirements? and why are they hard to test?

A

Requirements which exclude specific behaviour.
For example, a requirement may state that system failures must never corrupt the system database.
It is not possible to test such a requirement exhaustively.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
8
Q

Why are some Non-Functional Tests hard to test?

A

Some non-functional requirements, such as reliability requirements, can only be tested with a large test set.
Designing this test set does not help with requirements validation.
But the tests are still necessary for system delivery and for test during development.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
9
Q

How do we make a test?

A
  • We can use test cases, analysis or inspection to decide If a requirement is has been satisfied
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
10
Q

Define Domain

A

A domain is a representation of real-word conceptual classes, not of software components. It is not a set of a set of diagrams describing software classes, or software objects with responsibilities.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
11
Q

What is Conceptual Class?

A

Conceptual class is an idea, thing, or object
* it represents things in the real world, not classes in code
How do you capture them: UML class diagram

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
12
Q

What is Class?

A

A class is a template of objects. Class is an abstraction of all existing and new objects with similar characteristic.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
13
Q

What is an Object?

A

Objects are instances of a class. Data stored inside the object fields is often
references as state and all object methods define it’s behaviour.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
14
Q

What are the components of a Class?

A

Classes: rectangle containing the class name, and optionally fields/states/attributes and methods/operations

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
15
Q

What types of relationships do Classes have?

A

Associations
Dependency
Aggregation
Generalization

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
16
Q

What is Association?

A

Associations: a type of relationship in which one object uses or interacts with another

17
Q

What is Dependency?

A

Dependency: a weaker variant of association that usually implies that there is no permanent link between objects

18
Q

What is Aggregation?

A

Aggregation: appears between classes when one object merely contains a reference to another.

19
Q

What is Composition?

A

Composition: a type of aggregation shows a “whole-part” relationship between two objects, one of which composed of one or more instances of the other.

20
Q

What is Prototyping?

A

Prototyping is commonly a means for validating the software engineer’s interpretation of the software requirements, as well as for eliciting new requirements.

21
Q

What are the advantages of Prototyping?

A

The advantage of prototypes is that they can make it easier to interpret the software engineer’s assumptions and, where needed, give useful feedback on why they are wrong

22
Q

What are two types of Prototyping?

A
  • Analysis prototypes can be lightweight and need not contain SW at all; they are for discovering what the users want
  • Validation prototypes should be complete, reasonably efficient and robust. It should be possible to use them in the same way as the required system
23
Q

What are some types of prototypes that can be made?

A
  • Software: create a new executable prototype
    – Use rapid prototyping tools (eg UI as html forms)
  • Write a first draft of the user interface
    – Incremental development
  • Modify existing SW to create a prototype for the new system
  • Generate screen mock-ups with drawing software (eg PowerPoint is fine)
  • Draw mock-ups on white-boards or paper
24
Q

What are 3 examples of softwares that are amendable to the prototyping model?

A
  • Software applications that are relatively easy to prototype almost always involve human-machine interaction and/or heavy computer graphics.
  • Other applications that are sometimes amenable to prototyping are certain classes of mathematical algorithms, subset of command driven systems and other applications where results can be easily examined without real-time interaction.
  • Applications that are difficult to prototype include control and process control functions, many classes of real-time applications and embedded software.
25
Q

How do you develop a User Manual?

A
  • Writing a user manual from the requirements forces a detailed requirements analysis and thus can reveal problems with the document
  • Information in the user manual
    – Description of the functionality and how it is implemented
    – Which parts of the system have not been implemented
    – How to get out of trouble
    – How to install and get started with the system