Specification Flashcards

(21 cards)

1
Q

What is the main focus of a software specification?

A

A specification focuses on WHAT should be built in a software system, detailing exactly what is to be implemented, but not necessarily HOW it should be built.

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

How are specifications different from requirements?

A

Requirements describe what stakeholders need or want from a system, while specifications detail what the software must do to meet those requirements, often in a more precise and testable way.

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

Give an example of a functional requirement and its related specification.

A

Requirement: “A module convenor needs to check if a student has prerequisite knowledge.”

Specification: “A module interface shall show a list of students who want to take the module; allow viewing of modules/grades; show additional student comments; let the convenor accept/reject students; and allow contacting students for clarification.”

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

What are the typical qualities of a good specification?

A

Good specifications are correct, necessary, feasible, unique, concise, complete, clear, consistent, traceable, and verifiable.

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

Why is traceability important in specifications?

A

Traceability ensures that every specification can be linked back to a user requirement, making it clear which needs are being addressed and helping manage changes and verification.

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

What does it mean for a specification to be testable?

A

A testable specification is one that can be objectively verified as met or unmet, often by being measurable (e.g., “must load within 10s” instead of “must load fast”).

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

Who are the typical readers or users of specifications?

A

Specifications are read by developers, testers, project managers, clients, and other stakeholders involved in the software development process.

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

What are some common formats for writing specifications?

A

Specifications can be written in natural language, structured/tabular formats, or graphical forms such as UML diagrams.

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

What are the advantages and disadvantages of natural language specifications?

A

Advantages: Expressive, intuitive, and universal.

Disadvantages: Can be ambiguous, vague, and open to interpretation.

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

What guidelines help improve natural language specifications?

A

Use a standard format linked to user requirements, distinguish between mandatory (“shall”) and desirable (“should”), emphasize important elements, avoid jargon, and ensure specifications are measurable.

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

When should structured or tabular specifications be used?

A

Structured or tabular specifications are useful when details such as logic, inputs/outputs, conditions, or options need to be explicitly listed, or when exactness is required.

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

What is the purpose of graphical specifications like UML diagrams?

A

Graphical specifications help visualize complex system behaviors and interactions, making it easier to understand and communicate how the system should work.

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

What is the difference between requirements diagrams and specifications diagrams?

A

Requirements diagrams illustrate what stakeholders need, while specifications diagrams show what the system will do to fulfill those needs.

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

What is involved in a specification review process?

A

A team systematically reviews each specification, checking for validity, consistency, completeness, realism, and verifiability, ensuring the specifications are correct, necessary, and important.

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

What makes a specification ‘bad’?

A

A bad specification is ambiguous, incomplete, inconsistent, not testable, not traceable to requirements, or not feasible to implement.

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

Why is it important for specifications to be concise and unambiguous?

A

Concise and unambiguous specifications reduce misunderstandings, make implementation and testing easier, and help ensure the system meets stakeholder needs.

17
Q

What is the relationship between requirements, specifications, and testing?

A

Requirements define stakeholder needs, specifications translate those needs into precise system behaviors, and testing verifies that the implementation meets the specifications.

18
Q

What are some best practices for managing specifications in a team project?

A

Use version control tools (like git) for coordination, ensure all outputs are in markdown, use meaningful tags, and maintain clear links between requirements, specifications, and documentation.

19
Q

What is the role of priorities and risks in specifications?

A

Specifications often include information about the priority and risk of each requirement, helping teams focus on the most critical aspects and manage potential challenges.

20
Q

Why should specifications avoid jargon unless clearly defined?

A

Avoiding undefined jargon ensures that all stakeholders have a shared understanding, reducing the risk of misinterpretation.

21
Q

Guidelines for writing specifications

A

Use a standard format
Distinguish between mandatory (shall) and desirable (should)
Emphasise important elements with bold, italics etc
Avoid jargon, unless clearly specified in the key words section
Make sure the specification is measurable in some form