5 Flashcards
(75 cards)
1
Q
According to ______________________________, a requirement is defined as follows:
A
IEEE standard 729
2
Q
A condition or capability needed by a user to solve a problem or achieve an
objective
A
requirement
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
4
Q
A documented representation of a condition or capability, as in 1 and 2.
A
requirement
5
Q
is a crucial phase in the software development life cycle
(SDLC) and project management.
A
Requirements Gathering
5
Q
It is a process of determining user expectations for a new or modified product.
A
Requirements Gathering
6
Q
It involves collecting, documenting, and managing the requirements that define the
features and functionalities of a system or application.
A
Requirements Gathering
6
Q
The success of a project often depends on the accuracy and completeness of the
gathered requirements in software.
A
Requirements Gathering
7
Q
5 Importance of Requirements Gathering
A
- Clarity of Project Objective
- Customer Satisfaction
- Scope Definition
- Reduced Misunderstandings
- Risk Mitigation
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
8
Q
This focuses specifically on how data is collected during the requirement gathering
process.
A
Data Gathering Procedure
8
Q
Steps in data gathering procedure:
A
- Planning
- Preparation
- Execution
- Recording
- Analysis
9
Q
Data Gathering Techniques
A
Interviews
Workshops
Prototyping
Document Analysis
Surveys & Questionnaires
Observation
Use Cases and Scenarios
10
Q
are a crucial component of requirement gathering,
A
Interviews
11
Q
serve as collaborative forums
A
Workshops
12
Q
involves scrutinizing existing documentation to extract valuable insights
A
Document Analysis
12
Q
brings a hands-on approach to requirement gathering
A
Observation
12
Q
scenarios provide narrative context
A
Use Case & Scenarios
12
Q
provide a scalable approach to gather diverse stakeholder insights
A
Surveys & Questionnaires
13
Q
transforms abstract ideas into tangible models
A
Prototyping
14
Q
Software Requirements are mainly classified into three types:
A
Functional requirements
Non-Functional requirements
Domain requirements
15
Q
They define the functions or features that the system must have.
A
Functional requirements
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
16
Q
They define the quality attributes, performance criteria, and constraints.
A
Non-Functional requirements
17
They are the requirements stated by the user which one can see directly in the final
product, unlike the non-functional requirements.
Functional Requirements
18
Each high-level functional requirement may involve several interactions or dialogues
between the system and the outside world.
Functional Requirements
19
To accurately describe the functional requirements, all scenarios must be
enumerated.
Functional Requirements
19
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.
Functional Requirements
20
Functional Requirements in Software Engineering are also called
Functional Specification
21
These are basically the quality constraints that the system must satisfy according to
the project contract.
Non-Functional Requirements
22
Nonfunctional requirements, not related to the system functionality, rather define
how the system should perform.
Non-Functional Requirements
23
The priority or extent to which these factors are implemented varies from one
project to other.
Non-Functional Requirements
24
They are also called non-behavioral requirements.
Non-Functional Requirements
25
Non-Functional Requirements
* Portability
* Security
* Maintainability
* Reliability
* Scalability
* Performance
* Reusability
* Flexibilit
26
* They are divided into two main categories Non Functional Requirements
Execution qualities
evolution qualities
26
These consist of things like testability, maintainability,
extensibility, and scalability that are embodied in the static structure of the
software system.
evolution qualities
27
These consist of thing like security and usability, which are
observable at run time.
Execution qualities
27
requirements can be functional or nonfunctional.
Domain Requirements
28
are the requirements that are characteristic of a particular
category or domain of projects.
Domain Requirements
28
engineering is a continuous process of proactively defining the
requirements for all foreseeable applications to be developed in the software product
line.
Domain Requirements
29
Other Notable Classifications
* User Requirements
* System Requirements
* Business Requirements
* Regulatory Requirements
* Interface Requirements
* Design Requirements
29
7 Common Obstacles in Software Requirements Gathering
Unclear Objectives
Ambiguous Requirements
Poor Stakeholder Involvement
Changing Requirements
Communication Barriers
Overreliance on Documentation
Lack of User Involvement
29
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.
Unclear Objectives
30
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.
Poor Stakeholder Involvement
30
Ambiguities in requirements, such as vague language or conflicting statements, can
create misunderstandings among stakeholders and the development team.
Ambiguous Requirements
31
may result in deliverables that do not meet expectations and
may require extensive rework.
Ambiguous Requirements
32
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.
Changing Requirements
32
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.
Communication barriers
33
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.
Overreliance on Documentation
34
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.
lack of user involvement
34
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.
Retrospectives
34
Requirements Gathering in Agile Development
User Stories
Backlog Refinement
Iterative Development
Continuous Stakeholder Collaboration
Prototyping and Visual Aids
Daily Stand-ups
Acceptance Criteria
Retrospectives
35
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.
Acceptance Criteria
36
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.
Daily Stand-ups
36
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.
Prototyping and Visual Aids
37
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.
Continuous Stakeholder Collaboration
38
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.
Iterative Development
38
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.
Backlog Refinement
39
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.
User Stories
40
Challenges and Considerations in Agile Requirements Gathering
Changing Priorities
Balancing Detail and Flexibility
Effective Communication
Overemphasis on Documentation
Ensuring Continuous Feedback
41
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.
Ensuring Continuous Feedback
42
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
Overemphasis on Documentation
43
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.
Effective Communication
43
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.
Balancing Detail and Flexibility
44
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.
Changing Priorities
45
Tools for Requirements Gathering in Software Development
Collaboration Tools
Document Management Tools
Survey and Form Builders
Prototyping Tools
Mind Mapping Tools
Version Control Systems
Requirements Management Software
Visual Collaboration Tools
46
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.
Requirements gathering tools
47
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.
Collaboration Tools
48
(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.
Document Management Tools
Survey and Form Builders
49
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.
Survey and Form Builders
50
(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.
Prototyping Tools
51
(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.
Mind Mapping Tools
52
(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.
Version Control Systems
53
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.
Requirements Management Software
54
(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.
Visual Collaboration Tools
