Software Engineering Requirements Quiz

Podcast

Play an AI-generated podcast conversation about this lesson

Questions and Answers

Which of the following best describes non-functional requirements?

Statements of services the system should provide.

Detailed descriptions of system inputs and outputs.

High-level abstract statements of system functions.

Constraints on the services or functions offered by the system. (correct)

What do domain requirements generally refer to?

Specifications of user interface components.

Constraints originating from the domain of operation. (correct)

Legal constraints applicable to the system.

Requirements defined by user interactions.

Which component is crucial for defining usability requirements?

Memory allocation for the service.

Integration with other systems.

User interaction and ease of use. (correct)

Processing speed of the system.

What is a key characteristic of external requirements?

They can be derived from competitive systems. Signup and view all the answers

What differentiates user requirements from system requirements?

User requirements are less formal than system requirements. Signup and view all the answers

Which of the following statements is true regarding functional requirements?

Functional requirements detail specific functionality or services of the system. Signup and view all the answers

Which of the following is NOT considered a type of requirement?

Operational requirements Signup and view all the answers

Which aspect is emphasized in non-functional requirements?

The performance of the system under load. Signup and view all the answers

What is required for users of the MHC-PMS system to authenticate themselves?

Health authority identity card Signup and view all the answers

Which statement is a verifiable non-functional requirement?

The average number of errors should not exceed two per hour after training. Signup and view all the answers

What is a defining characteristic of domain requirements?

They impose constraints based on the system's operational domain. Signup and view all the answers

Which of the following is NOT typically measured under usability requirements?

Transaction processing speed Signup and view all the answers

What does a goal in the requirements context represent?

A general intention of the system users. Signup and view all the answers

Which of the following best describes a characteristic of a non-functional requirement?

It defines how the system should behave under certain conditions. Signup and view all the answers

Which measure is used to assess the speed of a system?

Processed transactions/second Signup and view all the answers

What is a reliability measure in system requirements?

Rate of failure occurrence Signup and view all the answers

What is the main purpose of using design description languages in system specifications?

To define an operational model of the system Signup and view all the answers

Which of the following specifications would be most beneficial for reducing ambiguity in requirements?

Mathematical specifications Signup and view all the answers

Why are requirements and design often considered inseparable in practice?

Requirements often change based on design contexts Signup and view all the answers

Which characteristic makes natural language specifications appealing for writing requirements?

They are expressive, intuitive, and universally understood Signup and view all the answers

What is a key guideline for writing clear and effective requirements?

Use a standard format consistently throughout Signup and view all the answers

What challenge is often faced when using natural language for specifications?

Difficulties in achieving precision without sacrificing readability Signup and view all the answers

Which type of requirements may specifically be influenced by regulatory standards?

Domain requirements Signup and view all the answers

What common pitfall occurs in the documentation of functional and non-functional requirements?

They tend to be mixed-up, leading to confusion Signup and view all the answers

Study Notes

Requirements Engineering

Requirements engineering is the process of establishing the services that the customer requires from a system, and the constraints under which it operates and is developed.
The requirements themselves are the descriptions of the system services and constraints generated during the requirements engineering process.
Requirements can range from abstract statements to detailed specifications.
Requirements may serve dual purposes; as a basis for a bid for a contract or as the basis for a contract itself. Both must be defined in detail, as they may be called requirements.

What is a Requirement?

Requirements can vary in level of abstraction from high-level to detailed mathematical specifications.
This variability is an unavoidable aspect of the process.
Requirements can be a basis for a bid or contract, and therefore require open interpretation in some cases and detailed specifications in others.

Types of Requirement

User Requirements: Natural language descriptions and diagrams of system services and operational constraints. Targeted at customers.
System Requirements: Structured documentation detailing system functions, services, and operational constraints. Often used as part of legal contracts between parties.

User and System Requirements Definition

Examples of user requirements are:
- The Mentcare system shall generate monthly management reports showing the cost of drugs prescribed by each clinic during that month.
- On the last working day of each month, a summary of drugs prescribed, their cost, and the prescribing clinics will be generated.
- The system shall generate the report for printing after 17.30 on the last working day of the month.
- Reports for each clinic will list the individual drug names, total prescriptions, the number of doses prescribed, and the total cost.
Example of system requirements:
- The system will have access controls for authorized users

Different Types of Requirements Specification

Flowchart outlining the various levels and those involved in each step of required specifications.
- User requirements -> system end-users, client managers, client engineers, contractor managers, system architects
- System requirements -> system end-users, client engineers, system architects, software developers

Functional and Non-functional Requirements

Functional Requirements: Statements of system services, how it reacts to inputs, and its behavior in specific situations. Can also include what the system should not do.
Non-functional Requirements: Constraints on services or system functionalities, including timing, development processes, standards, or domain constraints. These are often broader system-wide requirements.

Functional Requirements for the MHC-PMS

A user can search appointments across all clinics.
The system generates a daily list of patients for each clinic's appointments.
Staff are uniquely identified by an 8-digit employee number.

Requirements Imprecision

Problems arise from imprecisely stated requirements that can be interpreted differently by developers and users.
Ambiguous terms like search in a requirement can lead to misinterpretations. E.g., a user might want to search for patient names in all clinics versus within a single clinic.

Requirements Completeness and Consistency

Requirements should be complete and consistent.
Complete requirements should list all needed facilities.
Consistent requirements should have no conflicts or contradictions.
In practice, producing a complete and consistent document is often impossible.

Non-functional Requirements

Non-functional requirements define system properties and constraints, like reliability, response time, and storage needs.
Can also include constraints on I/O devices, system representations, and process requirements for IDE and development methodologies.
These can be more important than functional requirements because without these the system may be useless.

Types of Non-functional Requirement

Classification tree diagram to highlight the different types of nonfunctional requirements.
- Product, Organizational, and External Requirements
  - Efficiency, Dependability, Security, Regulatory, Ethical
  - Usability, Performance, Environmental, Operational, Development, Legislative, Accounting, Safety/Security.

Non-functional Classifications

Product Requirements: Specifications for product behavior like speed and reliability.
Organisational Requirements: Requirements from internal business policies and standards.
External Requirements: Requirements stemming from outside factors like legislation.

Examples of Non-functional Requirements in the MHC-PMS

Examples relating to a Medical Health Care system (MHC-PMS):
- Product Requirement: System accessibility during normal working hours.
- Organizational Requirement: User authentication with a health authority ID card.
- External Requirement: System adherence to patient privacy rules.

Goals and Requirements

Non-functional requirements are often difficult to precisely state and can be difficult to verify.
Goals are often general user intentions such as ease of use.
Verifiable non-functional requirements use measurable benchmarks that are objectively test-able.

Usability Requirements

Medical staff should be able to use all system functions after a period of training.
The system should be easy to use with minimal errors by medical staff.
User training will minimize errors after four hours of training, the average number of errors from an experienced user should not exceed two per hour of system use.

Metrics for Specifying Non-functional Requirements

Table detailing various metrics for specific non-functional requirements.

Domain Requirements

The operational domain of a system (e.g., a train control system) imposes certain requirements. (Examples: Braking characteristics in various weather conditions)
New functional requirements, constraints on existing functionalities, and specified calculations are further types of domain requirements.
The system may be considered unworkable without the satisfaction of domain requirements.

Train Protection System

The train's deceleration must be calculated as a function of control factors and gradient.

Domain Requirements Problems

Requirements expressed in application domain terminology might not be easily understood by software engineers;
Domain specialists may not articulate domain requirements explicitly, due to their familiarity of the field.

Requirements Engineering Processes

Flowchart outlining the spiral process of the requirements engineering process.
- Requirements elicitation, system requirements elicitation, user requirements elicitation.
- Requirements specification, feasibility study, prototyping, reviews.
- Requirements validation

Requirements Elicitation

Collecting requirements from stakeholders (customers, users, etc.) about the application domain and the services and operational constraints of a system—commonly called requirements discovery.
Stakeholder types involved include end-users, managers, maintenance engineers, domain experts, trade unions, etc.

Requirements Elicitation Techniques

Interviewing: Talking to stakeholders about their work and processes.
Observation (ethnography): Observing people performing their tasks to understand their work practices.
- Focused Ethnography: Combines ethnography with prototyping to identify problems in the observed processes.

Interviews in Practice

A mixture of formal and informal interviews are typically used to better capture a complete understanding of stakeholder interactions and work flow.
Interviews can provide a general understanding, however might be less effective for domain-specific requirements

Scope of Ethnography

Requirements derived from observation of how people actually work, not necessarily how they 'should' work.
Requirements derived from people's cooperation and activities.
Important for understanding existing processes but likely not for identifying new system features.

Scenarios

Scenarios are examples of how a system can be used.
Scenarios should include a description of: Starting situation (initial state), normal workflow process, things that can go wrong, concurrent activities, the final state when the scenario is finished.

Scenario for Collecting Medical History in MHC-PMS

Scenario: Initial assumption — patient has seen receptionist with basic details already in the system; a nurse is now collecting medical history.
Normal Scenario: Nurse searches for patient via family name, first name, and date of birth if needed.
Problems/Errors (what can go wrong): Patient record may not exist, information may not be available on existing conditions or medications.
The system shows the initial state and steps for gathering missing information and an estimated final state.

Use Cases

Use cases are scenario-based techniques in UML, that identify stakeholders, and describe their interactions with a system.

Requirements Specification

The process of documenting user and system requirements in a formal document.
Documents should be understandable to both end-users/customers without technical background and technical staff.

Ways of Writing a System Requirements Specification

Natural Language: Standard sentences for functional requirements; also use this with forms.
Structured Natural Language: Sentences written on a standardized form that clarifies and details every aspect of the requirement.
Design Description Languages: This approach uses a language like a programming language, but with more abstract features to specify the requirements, by defining an operational model of the system. This approach is now rarely used although it can be useful for interface specifications.
Graphical Notations: Using diagrams, like UML use case and sequence diagrams, commonly used to visually define system functionalities.
Mathematical Specifications: Based on mathematical concepts (e.g., finite-state machines, sets) to define precise requirements. Detailed, but can be difficult for customers to comprehend.

Requirements and Design

Requirements and design are closely interconnected and inseparable
System architecture can be used and shaped by requirements.
Systems may have to interact with other systems and this interaction can shape design requirements.

Natural Language Specification

Using natural language sentences with diagrams and tables to define requirements.
Preferred approach for understandable business system requirements.

Guidelines for Writing Requirements

Standard format for all requirements.
Consistent terminology and use of keywords (e.g., shall, should) for clarity.
Highlighting of specific requirements sections.
Avoid ambiguity and computer jargon.
Include rationale for each requirement.

Problems with Natural Language Requirements

Can be ambiguous and difficult to be precise.
Difficulty in separating functional and non-functional requirements.
Tendency to amalgamate different requirements into one.

Example Requirements for the Insulin Pump Software System

Example requirements: System regularly measures blood sugar and automatically delivers insulin as needed.

Structured Specifications

An approach that standardizes requirements.
Effective for embedded control systems.

Form-Based Specifications

Form-based specifications detail functions and entities, focusing on inputs, outputs, needed information, computations, and actions, pre- and post-conditions, and side effects.

A Structured Specification for an Insulin Pump

Detail example function specifications of an insulin pump and how to calculate it based on pre- and post-conditions.

Tabular Specification

Tables are used to supplement natural language.
Effective when multiple courses of actions with specified criteria should be defined in a tabular format.
Example — the insulin pump system calculates insulin requirements based on the rate of change of blood sugar levels in a tabular format.

Requirements Validation

The process of demonstrating that requirements accurately capture the customer's needs, checking for potential conflicts, and ensuring required functionality, considering possible budgets and available technologies.
Requirements errors can be extremely costly, often more expensive to rectify later.

Requirements Validation Techniques

Requirements reviews: Scrutiny of requirements documentation.
Systematic manual analysis: Manual checking for consistency completeness, usability.
Prototyping: Using executable models to test the system's functions.
Test-case generation: Establishing detailed tests for requirements to evaluate system behavior.

Requirements Reviews

Regular reviews are essential throughout the requirement's definition phase.
Should involve client and contractor staff.
Formal and informal reviews, good communication to resolve issues early.

Review Checks

Check for verifiability (testable?), comprehensibility (understanding), traceability (connected to other requirement), and adaptability (changes possible without significantly impactful changes on other aspects.)

Requirements Management

Process managing changing requirements during development and after deployment.
Tracking changes and assessing impact of change for linked requirements.

Changing Requirements

Business and technological factors change frequently.
The people who use and pay for the system are often different, creating conflicting requirements.
System requirements need to change to adapt.

Requirements Evolution

Requirement changes over time are inevitable due to new understanding of problems and new requirements

Requirements Management Planning

Establishing the level of requirements detail is essential.
Requirements identification, cross-referencing requirements
Change management process, identifying the impact and cost of changes
Traceability policies and tool support are key aspects.

Requirements Change Management

Analyzing and evaluating changes in requirements to determine if proposed changes are valid.
Assessing the impact of proposed changes on the system.
Implementing change on the system documentation and code.

Summary Points - Overall

Requirements for software are statements about what the system does and any operations/constraints on its usage.
Function requirements are statements describing operational functionality or needed computations.
Non-functional includes constraints on the system (e.g., product, organizational, external.)
Requirements engineering is an iterative spiral process, including discovery, classification, negotiation, specification, and validation.
Requirements specification is the formal documentation for the user and system, agreed upon by customers and developers.
Requirements validation is checking requirements to ensure validity, consistency, completeness, and realism.

Studying That Suits You

Use AI to generate personalized quizzes and flashcards to suit your learning preferences.

Description

Test your understanding of software engineering requirements with this quiz. Explore the differences between functional and non-functional requirements, usability, and domain requirements. Perfect for students studying software development and engineering concepts.