30 SRE Revision Questions
30.1 Short Answer
30.1.1 Lecture 1
30.1.1.1 What are performance requirements?
Performance requirements are a type of non-functional requirement which describe the required performance characteristics of the system, such as response time, throughput, capacity, scalability, and availability. These requirements are used to ensure that the system meets the performance expectations of the users and stakeholders. Performance requirements can include aspects such as:
- Response time: The time it takes for the system to respond to a user’s request.
- Throughput: The number of transactions or requests the system can handle in a given period of time.
- Capacity: The maximum number of users or amount of data the system can support.
- Scalability: The ability of the system to handle an increase in load or workload.
- Availability: The percentage of time the system is operational and available to users.
30.1.1.2 What are security requirements?
Security requirements are a type of non-functional requirement describing the measures which need to be taken to protect the system and its data from unauthorised access, use, disclosure, disruption, modification, or destruction. These requirements are used to ensure the confidentiality, integrity, and availability of the system and its data. Security requirements can include aspects such as:
- Authentication: Before allowing access to users, the system should be able to confirm their identity.
- Authorisation: To guarantee that users can only access the resources they are authorised to access, the site should be able to enforce access controls.
- Data encryption: The product should be able to encrypt sensitive data to protect it from unauthorised access or disclosure.
- Data integrity: The system should be able to detect and prevent unauthorised changes to data.
- Access control: The site should be able to restrict access to certain resources or functionality based on user roles or other attributes.
- Auditing and logging: For the sake of security and compliance, the system should be able to monitor and record user actions.
30.1.2 Lecture 2
30.1.2.1 Compare Between Functional and Nonfunctional Requirements
| Category | Functional Requirements | Non-Functional Requirements |
|---|---|---|
| What they describe | What the system should do | How the system should behave |
| Examples | User input, transaction processing, reports | Response speed, usability, reliability |
| How to check | Easy to check manually | Often needs metrics and load testing |
| Goal | Deliver features for users | Ensure quality, experience, and stability |
| The question they answer | “What should the system do?” | “How should the system work?” |
30.1.3 Lecture 3
30.1.3.1 Why is SRS also known as the blackbox specification of system ?
SRS document is a contract between the development team and the customer. Once the SRS document is approved by the customer, any subsequent controversies are settled by referring the SRS document.
The SRS document is known as black-box specification because it consideres the system a black box whose internal details are not known and only its visible external (i.e. input/output) behaviour is documented. SRS document concentrates on what needs to be done and carefully avoids the solution (“how to do”) aspects.
It should be carefully written using end-user terminology. If necessary later a formal requirement specification may be developed from it.
30.1.4 Lecture 4
30.1.4.1 Explain Brainstorming Techniques
Brainstorming is one of the creativity techniques for requirements eliciation. It performed through the following steps:
- ideas are collected within a certain time frame, usually in groups of 5 to 10 people.
- The ideas are documented by a moderator without discussing, judging, or commenting on them at first.
- Participants use ideas of other participants to develop new original ideas or to modify existing ideas. After that,
- the collected ideas are subjected to a thorough analysis.
This technique is especially effective when a large number of people of different stakeholder groups are involved. Among the advantages of this technique is that a large number of ideas can be collected in a short amount of time and multiple people can expand on these ideas collaboratively.
30.1.5 Lecture 7
30.1.5.1 Explain Requirements Validation principle “Involvement of the correct stakeholders”
The choice of stakeholders for requirements validation depends on two aspects:
- the goals of the validation
- the requirements that are to be audited
When assembling the auditing team, two aspects need to be considered.
The author of a requirement shouldn’t review it
Generally, it should be avoided that the author of a requirement is also the person to validate it. The author will make use of his or her prior knowledge when reading or reviewing the requirement. This prior knowledge can negatively influence the identification of errors because potential erroneous passages of the requirements documentation or the requirements are implicitly and subconsciously amended by the author’s own knowledge and can thus easily be overlooked.
Identifying both internal and external auditors
Suitable auditors can be identified within or outside of the developing organization. Internal audits are performed by stakeholders that are mem- bers of the developing organization and can be used to validate inter- mediate results or preliminary requirements. An internal validation is easy to coordinate and organize because the stakeholders are available from within the organization. An external audit requires a higher degree of effort because it identifies auditors and (potentially) hires them for pay- ment. In addition, external auditors have to become familiar with the con- text of the system to be developed. Due to the high effort, an external audit should be performed only on requirements that exhibit a high level of quality.
30.1.5.2 Explain Requirements Validation principle “Validation from Different Views”
Validating requirements from different views (also known as prespective-based validation) is one of the six principles of requirements validation and has proven itself in practice. In this principle, requirements are validated and agreed upon from different perspectives (e.g., by different people having different backgrounds). Comparable methods are used in other disciplines as well. For instance, in a legal trial, circumstances are often reported from the perspective of different people so that a sound overall picture can be gained.
30.2 MCQ and T/F
- Lecture 1 - 3: The “V” model is actually a test-design technique not an SDLC model; however, in the exam solve it as ‘SDLC Model’
- Lecture 3 - 1: There are two answers in the sheet. Solve it “Software Requirements Specification”
- Lectures 5 & 6 - 61 or 11: The ERD and DFD are data modeling techniques; however, solve it as False