Chapter 4 - User Requirements

Question 1

What are User Requirements?

Answer 1

User requirements are statements of what the system should do
to meet the needs of its users

They describe the functionality, performance, and constraints of
the system from a user’s perspective

Question 2

Sources of User Requirements

Answer 2

Users themselves (interviews, surveys, focus groups, etc.)

Stakeholders (managers, customers, regulators, etc.)

Existing systems (analyzing current systems to determine what
users like and don’t like)

Market research (analyzing the needs and wants of potential
users)

Question 3

What are System Requirements?

Answer 3

System requirements describe what the software system should do to meet the needs of its users and stakeholders

They define the behavior, performance, and constraints of the system from a technical perspective

Question 4

Sources of System Requirements

Answer 4

Functional specifications and other technical documents

Input from software architects and designers

Standards and regulations that the system must adhere to

Existing systems that the new system must integrate with

Question 5

What are Functional Requirements?

Answer 5

Functional requirements refers to the specific features and functionalities that a software must have to meet the user’s needs.

Functional requirements describe what the software system should do in terms of inputs, processes, and outputs

They specify the behavior and functionality of the system from a
user’s perspective

Question 6

Examples of Functional Requirements

Answer 6

User interfaces:
how users interact with the system

Data management:
how the system stores and retrieves data

Business rules:
how the system enforces business policies and
procedures

Processing logic:
how the system performs calculations and
other operations

Reports and outputs:
how the system presents information to
users

Question 7

Characteristics of Good Functional
Requirements

Answer 7

Clear and concise:
The requirements should be easy to
understand and not open to interpretation

Complete:
The requirements should include all necessary
information

Correct:
The requirements should accurately reflect the needs
of the system’s stakeholders

Consistent:
The requirements should not conflict with each
other

Verifiable:
The requirements should be testable to determine if
they have been met

Question 8

Advantages of Functional Requirements

Answer 8

Provides a clear understanding of the system’s intended behavior and functionality

Guides the development process and helps ensure that the system meets stakeholders’ needs

Provides a basis for testing the system to ensure that it works correctly and meets requirements

Helps manage project scope and provides a basis for estimating project effort and cost

Provides a basis for communicating with stakeholders and managing their expectations

Question 9

Functional Benefits for Different Stakeholders

Answer 9

Users:
Functional requirements ensure that the system meets
their needs and provides the functionality they require

Developers:
Functional requirements guide development efforts
and provide clear goals for development activities

Testers:
Functional requirements provide a basis for testing the
system and ensuring that it works correctly

Project Managers:
Functional requirements help manage
project scope and provide a basis for estimating project effort and cost

Business Stakeholders:
Functional requirements ensure that the
system supports business processes and meets business needs

Question 10

What are Non-Functional Requirements?

Answer 10

Non-functional requirements describe how the system should behave in terms of performance, reliability, security, usability, and other qualities

They specify the quality attributes or characteristics of the system from a user’s perspective

Question 11

Characteristics of Non-Functional Requirements

Answer 11

Performance:
how quickly the system responds to user requests or processes data

Reliability:
how dependable and stable the system is under
normal and adverse conditions

Security:
how well the system protects data and user
information

Usability:
how easy and intuitive the system is to use

Maintainability:
how easily the system can be maintained and
modified

Question 12

Importance of Non-Functional Requirements

Answer 12

Non-functional requirements are critical to the success of the software project as they define how well the system performs
and how easily it can be maintained

Non-functional requirements help ensure that the system is reliable, secure, performant, and easy to use

Question 13

Capturing Non-Functional Requirements

Answer 13

Involve stakeholders in the requirements development process

Use multiple methods to capture requirements (e.g., interviews, surveys, prototypes)

Use clear and concise language to describe requirements

Ensure that non-functional requirements are testable and verifiable

Question 14

Advantages of Non-Functional Requirement

Answer 14

Improved system quality:
Non-functional requirements ensure that the system is reliable, secure, performant, and easy to use. By defining these requirements upfront, software
developers can design and build a high-quality system that meets the needs of the
stakeholders.

Better user experience:
Non-functional requirements, such as usability and accessibility, help ensure that the system is easy to use and meets the needs of the users. This can
improve user satisfaction and adoption of the system.

Reduced risk:
Non-functional requirements, such as reliability and security, help mitigate risk by ensuring that the system is stable and secure. By defining these requirements
upfront, software developers can identify potential issues and address them before they
become bigger problems.

Clear project goals:
Non-functional requirements help establish clear project goals and expectations. This can help ensure that the stakeholders are aligned on the project’s
objectives and reduce the risk of miscommunication and misunderstandings.

Easier maintenance:
Non-functional requirements, such as maintainability and scalability, help ensure that the system is easy to maintain and can grow as the needs of the
stakeholders change over time. This can reduce the total cost of ownership of the system
and improve its long-term viability.

Question 15

Type of Non-Functional Requirements:

Answer 15

Product Requirement

Organization Requirement

External Requirement

Question 16

Product Requirement

Answer 16

Non-functional product requirements specify the characteristics or properties of the system that are not related to its specific functions or features.

These requirements are also known as quality attributes or quality characteristics.

Non-functional product requirements define the quality aspects of the system, which are critical to its success in the marketplace.

They help to ensure that the system meets the needs and expectations of the customers, and delivers value to the organization.

Examples of non-functional product requirements include performance, security, reliability, usability, scalability, maintainability, and compatibility.

Performance requirements specify the response time, throughput, or capacity of the system under different
conditions, such as peak usage or heavy load.

Security requirements specify the level of protection required for the system, such as authentication, access
control, or encryption.

Reliability requirements specify the expected availability, fault tolerance, or error handling capabilities of the system.

Usability requirements specify the ease of use, accessibility, or user interface design of the system.

Scalability requirements specify the ability of the system to handle increasing levels of usage, data volumes, or users.

Maintainability requirements specify the ease of maintenance, modification, or integration with other systems.

Compatibility requirements specify the ability of the system to work with other systems, platforms, or technologies.

Question 17

Organization Requirement

Answer 17

Organization requirements for non-functional requirements specify the constraints, standards, or
policies that the system must conform to in order to meet the needs of the organization.

These requirements are often specific to the organization, and may include legal or regulatory
requirements, industry standards, or internal policies and procedures.

Organization requirements for non-functional requirements help to ensure that the system aligns with
the overall goals and objectives of the organization and operates in a manner that is consistent with its
values and principles.

Examples of organization requirements for non-functional requirements include compliance with data
privacy regulations, adherence to industry best practices, or compatibility with existing IT
infrastructure.

Compliance requirements may include adherence to standards such as HIPAA, PCI, or GDPR, or
compliance with regulations such as SOX, FDA, or FISMA.

Industry-specific requirements may include compliance with standards such as ISO 9001, ISO 27001,
or ITIL, or adherence to industry-specific guidelines or best practices.

Internal policy requirements may include adherence to organizational policies related to security, data
management, or software development processes.

Organization requirements for non-functional requirements may also include constraints related to
budget, resources, or timelines, which may impact the design, development, or implementation of the
system.

Overall, organization requirements for non-functional requirements help to ensure that the system
meets the needs of the organization and operates in a manner that is consistent with its values,
principles, and obligations.

Question 18

External Requirement

Answer 18

External requirements for non-functional requirements specify the constraints, expectations, or standards that are imposed by external stakeholders,
such as customers, partners, or regulatory bodies.

These requirements are often specific to the external environment in which the system will operate, and may include legal or regulatory requirements,
industry standards, or customer expectations.

External requirements for non-functional requirements help to ensure that the system meets the needs and expectations of the external stakeholders
and operates in a manner that is consistent with the external environment in which it will operate.

Examples of external requirements for non-functional requirements include compliance with data privacy regulations, adherence to industry standards,
or compatibility with external systems or technologies.

Compliance requirements may include adherence to standards such as HIPAA, PCI, or GDPR, or compliance with regulations such as SOX, FDA, or
FISMA.

Industry-specific requirements may include compliance with standards such as ISO 9001, ISO 27001, or ITIL, or adherence to industry-specific
guidelines or best practices.

Customer expectations may include requirements related to performance, reliability, security, or usability, as well as expectations related to user
experience, customer service, or support.

External requirements for non-functional requirements may also include constraints related to the external environment, such as the availability of
network infrastructure, or the compatibility of external systems or technologies.

Overall, external requirements for non-functional requirements help to ensure that the system meets the needs and expectations of the external
stakeholders, and operates in a manner that is consistent with the external environment in which it will operate

Question 19

Differences between Functional and
Non-Functional Requirements

Answer 19

Functional Requirements

Non-Functional Requirements

Describe what the system should do

Describe how the system should behave

Are concerned with system features and
functionality

Are concerned with system characteristics and
properties

Can be tested by verifying whether the system
meets specific functionality criteria

Can be tested by verifying whether the system
meets specific performance, security, or usability
criteria

Are typically specified by stakeholders who interact
directly with the system

Are typically specified by stakeholders who have
an interest in the system’s overall performance,
security, or usability

Are often specific to a particular system or
application

Are often general requirements that apply to many
systems or applications

Are usually easier to define and document

Are usually more complex and difficult to define
and document

Examples: login functionality, search functionality,
checkout process

Examples: response time, scalability, reliability,
security, usability

Question 20

Requirement Engineering Process

Answer 20

Requirement Engineering is a systematic process of gathering, analyzing, documenting, validating, and managing software requirements.

Question 21

Steps involved in Requirement Engineering Process

Answer 21

Requirements elicitation:
This step involves gathering requirements from stakeholders using various techniques such as interviews, questionnaires, and workshops. The goal is to identify the needs, goals, and constraints of the stakeholders.

Requirements analysis:
This step involves analyzing the requirements to identify inconsistencies, ambiguities, and conflicts. The goal is to ensure that the requirements are
complete, consistent, and unambiguous.

Requirements specification:
This step involves documenting the requirements in a clear and concise manner using standard templates and notation. The goal is to provide a complete
and accurate description of the requirements that can be used as a basis for design and
implementation.

Requirements validation:
This step involves ensuring that the documented requirements accurately represent the needs and expectations of the stakeholders. The goal is to identify
and correct any errors or omissions in the requirements before the software is developed.

Requirements management:
This step involves tracking changes to the requirements and ensuring traceability throughout the software development life cycle. The goal is to ensure
that the requirements are properly managed and that any changes are properly documented and communicated to stakeholders.

Question 22

Requirement Elicitation and Analysis

Answer 22

Requirement elicitation and analysis are the first two steps in
the Requirement Engineering process.

They involve gathering and analyzing the needs and
requirements of stakeholders to define the scope and features
of a software system.

Question 23

Requirement Elicitation:

Answer 23

Requirement Elicitation: Requirement elicitation involves identifying, gathering, and documenting the needs, expectations, and constraints of stakeholders.

The goal is to understand the stakeholders’ needs and goals, and to collect as much relevant information as possible.

Techniques for requirement elicitation include interviews, focus groups, surveys, observations, and brainstorming sessions.

Question 24

Requirement Analysis:

Answer 24

Requirement analysis involves reviewing and analyzing the gathered requirements to ensure they are clear, consistent, and complete.

This involves identifying any gaps, conflicts, and ambiguities in the requirements, and ensuring that they are relevant and feasible.

Techniques for requirement analysis include reviewing existing documentation, use cases, and prototypes.

Question 25

Four main steps of requirements elicitation and analysis

Answer 25

Requirements Discovery Requirements classification and organization Requirement prioritization and negotiation Requirement Specification Requirement Validation Requirement change management

Question 26

Requirements Discovery

Answer 26

Requirement Discovery is the initial phase where the requirements are collected and gathered from various sources. It is a crucial step that lays the foundation for the entire requirement engineering process. Below are the points explaining Requirement Discovery: Identify stakeholders: The first step is to identify all stakeholders involved in the project, including end-users, customers, developers, and managers. Gather initial requirements: Once stakeholders are identified, the initial requirements are collected by conducting brainstorming sessions, interviews, surveys, and focus groups. Prioritize requirements: Prioritize the requirements based on their importance, criticality, and feasibility. Identify constraints: Identify any constraints that may impact the project, such as time, cost, resources, and technology. Review requirements: Review the requirements for completeness, consistency, and feasibility. Ensure that the requirements are clear and unambiguous. Validate requirements: Validate the requirements with stakeholders to ensure that they meet their needs and expectations. Document requirements: Document the requirements in a clear, concise, and unambiguous manner. Use standard templates and formats for documentation. Update requirements: Update the requirements as necessary

Question 27

Requirements classification and organization

Answer 27

Requirements classification and organization is an important step in requirement elicitation and analysis, which involves categorizing requirements based on their characteristics and organizing them into a structured format. Below are the points explaining Requirements classification and organization: Functional vs. Non-functional: The requirements are classified into functional and non-functional requirements. Functional requirements describe what the system should do, while non-functional requirements describe how the system should perform. Business vs. Technical: Requirements can also be classified as business or technical. Business requirements describe the features and functions required by the end-users, while technical requirements describe the underlying technology, architecture, and infrastructure needed to support the system. User vs. System: Requirements can be further classified as user or system requirements. User requirements describe the needs and expectations of the end-users, while system requirements describe the features and functions needed to support the system. Priority: Requirements can be prioritized based on their importance, criticality, and feasibility. Prioritizing requirements helps to ensure that the most important requirements are addressed first. Traceability: Requirements should be traced throughout the requirement engineering process to ensure that they are addressed and fulfilled. Traceability helps to ensure that the requirements are met, and also helps to manage changes to the requirements. Organizing Requirements: The requirements are organized in a structured format using techniques such as use cases, user stories, and scenarios. These techniques help to ensure that the requirements are clear, concise, and unambiguous.

Question 28

Requirement prioritization and negotiation

Answer 28

Requirement prioritization and negotiation is a crucial step in the requirement elicitation and analysis process, which involves evaluating and prioritizing requirements based on their importance, feasibility, and impact. Below are the points explaining requirement prioritization and negotiation: Identifying Stakeholders: The first step in prioritization and negotiation is to identify all stakeholders who will be impacted by the system. These stakeholders may include end-users, management, developers, testers, and other stakeholders. Determining Requirements Importance: The next step is to determine the importance of each requirement based on its relevance to the stakeholders and the business objectives. High-priority requirements are those that are critical to the success of the project, while low-priority requirements are those that can be addressed later. Evaluating Feasibility: The feasibility of a requirement refers to its technical and operational viability. Feasibility should be evaluated based on the project constraints such as budget, timeline, resources, and technology availability. Resolving Conflicts: Conflicts may arise during requirement prioritization and negotiation. These conflicts can be resolved by identifying the root cause of the conflict and finding a solution that is acceptable to all stakeholders. Negotiation: Negotiation involves discussing and reconciling conflicting requirements among stakeholders. The objective is to find a mutually acceptable solution that meets the business objectives. Documenting the Results: The results of the requirement prioritization and negotiation process should be documented and communicated to all stakeholders. This documentation should include the prioritized requirements, the rationale behind the prioritization, and any trade-offs made during negotiation.

Question 29

Requirement Specification

Answer 29

Requirement Specification is a critical step in the requirement elicitation and analysis process, which involves documenting the requirements in a clear and concise manner. Below are the points explaining Requirement Specification: Documenting Requirements: The first step in Requirement Specification is to document the requirements in a clear and concise manner. The document should include all the functional and non-functional requirements identified during the elicitation process. Defining Requirements: Each requirement should be clearly defined, including the expected behavior, inputs, outputs, and constraints. This helps to ensure that everyone understands what is required. Structuring the Document: The document should be structured in a way that makes it easy to understand and navigate. This includes organizing requirements by category, creating tables and diagrams, and using appropriate headings and subheadings. Reviewing the Document: The Requirement Specification document should be reviewed by stakeholders to ensure that all requirements are included and that they are accurately documented. Validating Requirements: The requirements should be validated to ensure that they are correct, complete, and feasible. This can be done through prototyping, simulation, or other techniques. Updating the Document: The Requirement Specification document should be updated throughout the project as new requirements are identified or existing requirements change. It is important to maintain a clear and up-to-date record of all requirements. Communicating the Document: The final step in Requirement Specification is to communicate the document to all stakeholders. This helps to ensure that everyone understands the requirements and their roles in the project.

Question 30

Requirement Validation

Answer 30

Requirement Validation is the process of checking the requirements for completeness, consistency, correctness, and feasibility. Here are some points that describe this process: Reviews: Requirements documents are reviewed by stakeholders to identify any inconsistencies, errors, or ambiguities. Prototyping: Prototyping can be used to validate requirements by creating a working model of the system that can be tested and evaluated. Testing: Requirements are tested to ensure that they are complete, consistent, and feasible. Testing can be done manually or using automated tools. Traceability: Requirements are traced throughout the development process to ensure that they are implemented correctly. Acceptance criteria: Acceptance criteria are defined to ensure that the system meets the requirements and the needs of the stakeholders. Change management: The process for managing changes to requirements is established to ensure that changes are properly evaluated, approved, and documented. Sign-off: Stakeholders sign off on the requirements to indicate that they are complete, correct, and feasible. This ensures that all stakeholders have agreed to the requirements before development begins.

Question 31

Requirement change management

Answer 31

Requirement change management is the process of managing changes to the requirements throughout the software development life cycle. Here are some points that describe this process: Change identification: Changes to the requirements are identified by stakeholders, customers, or the development team. Change evaluation: The impact of the proposed change is evaluated to determine its feasibility, cost, and potential impact on the project schedule and other requirements. Change control: The process for managing changes to requirements is established to ensure that changes are properly evaluated, approved, and documented. Change communication: All stakeholders are informed of changes to the requirements, including the reason for the change, the impact of the change, and any changes to the project schedule or budget. Change implementation: Changes to the requirements are implemented in the system development process, and the impact of the change is evaluated. Requirements traceability: Changes to the requirements are tracked to ensure that they are implemented correctly and to maintain traceability throughout the development process. Configuration management: Changes to the requirements are managed as part of the overall configuration management process to ensure that changes are properly documented and controlled.

Question 32

Different types of requirement elicitation techniques

Answer 32

There are various techniques used for requirement elicitation in software engineering. Here are some of the most commonly used techniques: Interviews: One-on-one interviews with stakeholders to gather information about their needs and requirements. Workshops: Group sessions where stakeholders and developers work together to identify and refine requirements. Surveys and questionnaires: A series of questions sent to stakeholders to gather information about their needs and requirements. Observation: Observing users as they perform tasks in their work environment to identify requirements. Prototyping: Building early versions of the software to gather feedback and identify requirements. Focus groups: Group sessions where stakeholders discuss their needs and requirements with a facilitator. Document analysis: Reviewing existing documentation, such as reports, requirements specifications, and user manuals. Brainstorming: A group creativity technique that encourages participants to generate ideas and solutions. Use cases: Scenarios that describe how the software will be used in different situations. Storyboarding: A visual representation of how the software will work, which helps to identify and refine requirements. Contextual inquiry: A research method that involves observing users in their natural environment and asking questions to gain a deeper understanding of their needs and requirements.