Brainscape's Knowledge GenomeTM

Browse over 1 million classes created by top students, professors, publishers, and experts.


See full index

Software Engineering > 5 > Flashcards

5 Flashcards

1
Q

According to ______________________________, a requirement is defined as follows:

A

IEEE standard 729

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

A condition or capability needed by a user to solve a problem or achieve an
objective

A

requirement

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

A condition or capability that must be met or possessed by a system or system
component to satisfy a contract, standard, specification or other formally imposed
documents

A

requirement

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

A documented representation of a condition or capability, as in 1 and 2.

A

requirement

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

is a crucial phase in the software development life cycle
(SDLC) and project management.

A

Requirements Gathering

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

It is a process of determining user expectations for a new or modified product.

A

Requirements Gathering

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

It involves collecting, documenting, and managing the requirements that define the
features and functionalities of a system or application.

A

Requirements Gathering

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

The success of a project often depends on the accuracy and completeness of the
gathered requirements in software.

A

Requirements Gathering

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

5 Importance of Requirements Gathering

A
  1. Clarity of Project Objective
  2. Customer Satisfaction
  3. Scope Definition
  4. Reduced Misunderstandings
  5. Risk Mitigation
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
8
Q

6 Processes of Requirements Gathering

A

Step 1: Assigning Roles
Step 2: Define Project Scope
Step 3: Conduct Stakeholder Interviews
Step 4: Document Requirements
Step 5: Verify & Validate Requirements
Step 6: Prioritize Requirements

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

This focuses specifically on how data is collected during the requirement gathering
process.

A

Data Gathering Procedure

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

Steps in data gathering procedure:

A
  1. Planning
  2. Preparation
  3. Execution
  4. Recording
  5. Analysis
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
9
Q

Data Gathering Techniques

A

Interviews
Workshops
Prototyping
Document Analysis
Surveys & Questionnaires
Observation
Use Cases and Scenarios

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

are a crucial component of requirement gathering,

A

Interviews

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

serve as collaborative forums

A

Workshops

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

involves scrutinizing existing documentation to extract valuable insights

A

Document Analysis

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

brings a hands-on approach to requirement gathering

A

Observation

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

scenarios provide narrative context

A

Use Case & Scenarios

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

provide a scalable approach to gather diverse stakeholder insights

A

Surveys & Questionnaires

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

transforms abstract ideas into tangible models

A

Prototyping

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

Software Requirements are mainly classified into three types:

A

Functional requirements
Non-Functional requirements
Domain requirements

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

They define the functions or features that the system must have.

A

Functional requirements

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

These are specific to the domain or industry in which the software operates.
They include terminology, rules, and standards relevant to that particular domain.

A

Domain requirements

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

They define the quality attributes, performance criteria, and constraints.

A

Non-Functional requirements

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

They are the requirements stated by the user which one can see directly in the final
product, unlike the non-functional requirements.

A

Functional Requirements

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

Each high-level functional requirement may involve several interactions or dialogues
between the system and the outside world.

A

Functional Requirements

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

To accurately describe the functional requirements, all scenarios must be
enumerated.

A

Functional Requirements

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

There are many ways of expressing functional requirements e.g., natural language, a
structured or formatted language with no rigorous syntax, and formal specification
language with proper syntax.

A

Functional Requirements

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

Functional Requirements in Software Engineering are also called

A

Functional Specification

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

These are basically the quality constraints that the system must satisfy according to
the project contract.

A

Non-Functional Requirements

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

Nonfunctional requirements, not related to the system functionality, rather define
how the system should perform.

A

Non-Functional Requirements

23
Q

The priority or extent to which these factors are implemented varies from one
project to other.

A

Non-Functional Requirements

24
Q

They are also called non-behavioral requirements.

A

Non-Functional Requirements

25
Q

Non-Functional Requirements

A
  • Portability
  • Security
  • Maintainability
  • Reliability
  • Scalability
  • Performance
  • Reusability
  • Flexibilit
26
Q
  • They are divided into two main categories Non Functional Requirements
A

Execution qualities
evolution qualities

26
Q

These consist of things like testability, maintainability,
extensibility, and scalability that are embodied in the static structure of the
software system.

A

evolution qualities

27
Q

These consist of thing like security and usability, which are
observable at run time.

A

Execution qualities

27
Q

requirements can be functional or nonfunctional.

A

Domain Requirements

28
Q

are the requirements that are characteristic of a particular
category or domain of projects.

A

Domain Requirements

28
Q

engineering is a continuous process of proactively defining the
requirements for all foreseeable applications to be developed in the software product
line.

A

Domain Requirements

29
Q

Other Notable Classifications

A
  • User Requirements
  • System Requirements
  • Business Requirements
  • Regulatory Requirements
  • Interface Requirements
  • Design Requirements
29
Q

7 Common Obstacles in Software Requirements Gathering

A

Unclear Objectives
Ambiguous Requirements
Poor Stakeholder Involvement
Changing Requirements
Communication Barriers
Overreliance on Documentation
Lack of User Involvement

29
Q

When stakeholders are unsure about what they want to achieve, it becomes
challenging to define and prioritize requirements effectively.

This can lead to confusion, scope creep, and difficulties in meeting project goals.

A

Unclear Objectives

30
Q

Insufficient involvement or engagement of key stakeholders can impede the
requirements gathering process.

When essential stakeholders are not actively participating or providing input, there is a
risk of missing critical requirements or making decisions that do not align with the
needs of the end-users.

A

Poor Stakeholder Involvement

30
Q

Ambiguities in requirements, such as vague language or conflicting statements, can
create misunderstandings among stakeholders and the development team.

A

Ambiguous Requirements

31
Q

may result in deliverables that do not meet expectations and
may require extensive rework.

A

Ambiguous Requirements

32
Q

Requirements that undergo frequent changes during the development process, often
referred to as “scope creep,

” can lead to project delays, increased costs, and

challenges in maintaining project focus.

It is essential to manage and control changes to prevent unnecessary disruptions.

A

Changing Requirements

32
Q

Communication challenges, such as language barriers, misinterpretations, or
inadequate channels for information exchange, can hinder effective requirements
gathering.

It is crucial to establish clear communication channels and ensure that all stakeholders
have a shared understanding of the terminology used in the project.

A

Communication barriers

33
Q

Depending solely on documentation without active collaboration and communication
can lead to misunderstandings.

Written requirements may not capture the complete context or evolving needs, making
it essential to complement documentation with interactive processes like workshops
and interviews.

A

Overreliance on Documentation

34
Q

Users are often the ultimate beneficiaries of the system, and their input is critical.

Lack of user involvement or representation can result in systems that do not effectively
meet their needs.

It is important to actively involve end-users in the requirements gathering process to
ensure the system’s usability and acceptance.

A

lack of user involvement

34
Q

This feedback loop includes discussions about the effectiveness of the requirements
gathering process, allowing the team to adapt and refine their approach for future
sprints.

A

Retrospectives

34
Q

Requirements Gathering in Agile Development

A

User Stories
Backlog Refinement
Iterative Development
Continuous Stakeholder Collaboration
Prototyping and Visual Aids
Daily Stand-ups
Acceptance Criteria
Retrospectives

35
Q

define the conditions that must be met for a user story to be
considered complete.

They serve as a shared understanding between the development team and
stakeholders regarding the expectations for the functionality being delivered.

A

Acceptance Criteria

36
Q

These brief, focused meetings provide team members with the opportunity to share
progress, discuss impediments, and ensure that everyone is aligned on the project’s
goals.

While not specifically for requirements gathering, daily stand-ups facilitate ongoing
communication, allowing the team to quickly address any emerging requirements or
changes.

A

Daily Stand-ups

36
Q

Prototypes, wireframes, and other visual representations help stakeholders visualize
the proposed features and provide early feedback.

This iterative approach ensures that the final product closely aligns with stakeholder
expectations.

A

Prototyping and Visual Aids

37
Q

Agile encourages ongoing collaboration with stakeholders, including product owners,
end-users, and business representatives.

Regular meetings, such as sprint reviews and sprint planning, provide opportunities for
stakeholders to provide feedback on completed work, discuss changes to priorities, and
refine requirements for upcoming sprints.

A

Continuous Stakeholder Collaboration

38
Q

Agile development is iterative, with work organized into time-boxed cycles called
sprints.

During each sprint, a cross-functional team works on a set of prioritized user stories.

The requirements for each user story are refined and clarified as the team progresses,
allowing for flexibility and adaptability to changing priorities or emerging insights.

A

Iterative Development

38
Q

The product backlog is a prioritized list of features, enhancements, and fixes.

Backlog refinement sessions, often known as backlog grooming, occur regularly to
review, clarify, and prioritize the items in the backlog.

This process ensures that the most valuable and highest-priority items are at the top of
the list and ready for development in upcoming sprints.

A

Backlog Refinement

39
Q

is a concise, informal description of a feature told from the end-user’s
perspective.

It typically follows the format: “As a [type of user], I want [an action] so that
[benefit/value].
focus on the user and their goals, helping to capture the essence of the
required functionality.

A

User Stories

40
Q

Challenges and Considerations in Agile Requirements Gathering

A

Changing Priorities
Balancing Detail and Flexibility
Effective Communication
Overemphasis on Documentation
Ensuring Continuous Feedback

41
Q

Agile places a strong emphasis on continuous feedback, but ensuring active
stakeholder involvement can be challenging.

Efforts should be made to encourage regular feedback through sprint reviews, demos,
and other collaborative sessions to avoid potential misunderstandings and to keep the
development aligned with stakeholder expectations.

A

Ensuring Continuous Feedback

42
Q

While Agile values working software over comprehensive documentation, it’s important
to strike a balance.

Minimal but effective documentation, such as user stories and acceptance criteria,
should be maintained to

A

Overemphasis on Documentation

43
Q

Agile heavily relies on communication and collaboration.

Ensuring that all team members, including stakeholders, have open channels for
communication is essential to prevent misunderstandings and align everyone with the
project’s goals.

A

Effective Communication

43
Q

Agile requires enough detail to guide development, but also the flexibility to adapt as
requirements evolve.

Striking the right balance ensures that the team can respond to changes while
maintaining a clear understanding of the project’s direction.

A

Balancing Detail and Flexibility

44
Q

Agile embraces changes in requirements, but frequent changes can pose challenges.

It’s crucial to strike a balance between flexibility and stability, ensuring that changes
are well-understood, prioritized, and communicated effectively to the development
team.

A

Changing Priorities

45
Q

Tools for Requirements Gathering in Software Development

A

Collaboration Tools
Document Management Tools
Survey and Form Builders
Prototyping Tools
Mind Mapping Tools
Version Control Systems
Requirements Management Software
Visual Collaboration Tools

46
Q

play a crucial role in streamlining the process of collecting, documenting, and managing project requirements.

These tools are designed to enhance collaboration, improve communication, and
facilitate the organization of complex information.

A

Requirements gathering tools

47
Q

uch as project management platforms (e.g., Jira, Trello, Asana),
facilitate teamwork and communication among project stakeholders.

These platforms often include features like task assignment, progress tracking, and
discussion forums, enabling teams to collaboratively gather, discuss, and manage
requirements in real-time.

A

Collaboration Tools

48
Q

(e.g., Confluence, SharePoint) help organize and store
project documentation.

These tools provide a centralized repository for requirements, ensuring easy access,
version control, and collaboration.

Document management tools are particularly valuable for maintaining a structured
record of evolving project requirements.

A

Document Management Tools
Survey and Form Builders

49
Q

Tools like Google Forms, Typeform, or SurveyMonkey enable the creation of online
surveys and forms.

These are useful for gathering structured data from a large audience, such as feedback,
preferences, or specific information required for project requirements.

The collected data can be easily analyzed and integrated into the requirements
gathering process.

A

Survey and Form Builders

50
Q

(e.g., Sketch, Balsamiq, Figma) allow the creation of visual or
interactive prototypes.

These tools are valuable for translating requirements into tangible representations that
stakeholders can interact with, providing a clearer understanding of the proposed
features and functionalities.

A

Prototyping Tools

51
Q

(e.g., MindMeister, XMind) help visualize and organize complex
ideas and relationships.

During requirements gathering, these tools can be used to create visual
representations of interconnected requirements, helping stakeholders and the project
team understand the relationships between different features and functionalities.

A

Mind Mapping Tools

52
Q

(e.g., Git, SVN) are essential for managing changes to project
documentation.

These tools track revisions, allowing teams to review, revert, or merge changes
seamlessly.

This is particularly valuable in dynamic projects where requirements may undergo
frequent updates or refinements.

A

Version Control Systems

53
Q

Specialized requirements management tools (e.g., IBM Engineering Requirements
Management DOORS, Jama Connect) are designed specifically for capturing, tracking,
and managing requirements throughout the project lifecycle.

These tools often offer features such as traceability, impact analysis, and integration
with other project management tools.

A

Requirements Management Software

54
Q

(e.g., Miro, Lucidchart) facilitate collaborative diagramming and
visual representation of ideas.

These tools can be used for creating flowcharts, diagrams, or visual models that help
communicate complex requirements in a more intuitive and accessible way.

A

Visual Collaboration Tools

Software Engineering (8 decks)

Brainscape helps you reach your goals faster, through stronger study habits.
© 2024 Bold Learning Solutions. Terms and Conditions