Module2.pptx cyber module 1 hackers tools and techniques

1. Software Engineering and Project
Management
Course Code: BCS501
Module 2

2. Requirement Engineering
• Requirements Engineering is the process of identifying, eliciting, analyzing, specifying,
validating, and managing the needs and expectations of stakeholders for a software
system.
• A systematic and strict approach to the definition, creation, and verification of
requirements for a software system is known as requirements engineering.
• To guarantee the effective creation of a software product, the requirements engineering
process entails several tasks that help in understanding, recording, and managing the
demands of stakeholders.
• Requirements engineering provides the appropriate mechanism for understanding what
the customer wants, analyzing need, assessing feasibility, negotiating a reasonable
solution, specifying the solution unambiguously, validating the specification, and
managing the requirements as they are transformed into an operational system.
• It encompasses five distinct tasks: feasibility study, elicitation, specification,
verification & validation, and management. It is important to note that some of these
tasks occur in parallel and all are adapted to the needs of the project.

3. Requirement Engineering Process

4. Requirement Engineering Process
1. Feasibility Study: A Feasibility Study is an evaluation process that checks if a project is
practically and financially possible before development begins. It helps in deciding
whether to go ahead with the project or not.
Types of Feasibility Study:
• Technical Feasibility
- Checks if the current hardware, software, and technical skills are enough to complete the project.
- Also looks at whether the technology can be maintained or upgraded easily.
• Operational Feasibility
- Evaluates if the proposed system will work well in the real environment.
- Also checks if the product will be user-friendly and easy to maintain.
• Economic Feasibility
- Analyzes the cost vs. benefits of the project.
- Decides whether the investment is worth it and profitable in the long run.
• Legal Feasibility
- Ensures the project follows all laws, standards, and regulations.
- Also checks issues like contracts, copyrights, and licenses.

5. • Schedule Feasibility
- Determines if the project can be completed within the given time.
- Evaluates resource availability and sets realistic deadlines.
2. Requirements Elicitation:
• Requirements Elicitation is the process of gathering information from stakeholders to
understand their needs, goals, and expectations for a software system.
• It is the first step in the requirements engineering process and plays a key role in the
project's success.
• It helps the analyst gain domain knowledge and understand the problem to be solved.
• Information is collected from various sources like customers, users, existing systems,
business documents, and standards.

6. Several techniques can be used to elicit requirements, including:
• Interviews: These are one-on-one conversations with stakeholders to gather
information about their needs and expectations.
• Surveys: These are questionnaires that are distributed to stakeholders to gather
information about their needs and expectations.
• Focus Groups: These are small groups of stakeholders who are brought together to
discuss their needs and expectations for the software system.
• Observation: This technique involves observing the stakeholders in their work
environment to gather information about their needs and expectations.
• Prototyping: This technique involves creating a working model of the software system,
which can be used to gather feedback from stakeholders and to validate requirements.
It's important to document, organize, and prioritize the requirements obtained from all
these techniques to ensure that they are complete, consistent, and accurate.

7. 3. Requirements Specification:
• Requirements specification is the process of documenting the requirements identified in the
analysis step in a clear, consistent, and unambiguous manner.
• This step also involves prioritizing and grouping the requirements into manageable chunks.
• The goal of this step is to create a clear and comprehensive document that describes the
requirements for the software system.
• This document should be understandable by both the development team and the stakeholders.
Several types of requirements are commonly specified in this step, including:
• Functional Requirements: These describe what the software system should do. They specify
the functionality that the system must provide, such as input validation, data storage, and user
interface.
• Non-Functional Requirements: These describe how well the software system should do it.
They specify the quality attributes of the system, such as performance, reliability, usability,
and security.

8. • Constraints: These describe any limitations or restrictions that must be considered when
developing the software system.
• Acceptance Criteria: These describe the conditions that must be met for the software system
to be considered complete and ready for release.
- To make the requirements specification clear, the requirements should be written in a natural
language and use simple terms, avoiding technical jargon, and using a consistent format
throughout the document.
- It is also important to use diagrams, models, and other visual aids to help communicate the
requirements effectively.
- Once the requirements are specified, they must be reviewed and validated by the stakeholders
and development team to ensure that they are complete, consistent, and accurate.

9. 4. Requirements Verification and Validation:
 Verification:
• Verification is checking that the requirements are complete, consistent, and accurate.
• It involves reviewing the requirements to ensure that they are clear, testable, and free of errors
and inconsistencies.
• This can include reviewing the requirements document, models, and diagrams, and holding
meetings and walkthroughs with stakeholders.
 Validation:
• Validation is the process of checking that the requirements meet the needs and expectations of
the stakeholders.
• It involves testing the requirements to ensure that they are valid and that the software system
being developed will meet the needs of the stakeholders.
• This can include testing the software system through simulation, testing with prototypes, and
testing with the final version of the software.

10. 4. Requirements Verification and Validation:
 Verification and Validation :
• Verification and Validation is an iterative process that occurs throughout the software
development life cycle.
• It is important to involve stakeholders and the development team in the V&V process to ensure
that the requirements are thoroughly reviewed and tested.
 The main steps for this process include:
- The requirements should be consistent with all the other requirements i.e. no two requirements
should conflict with each other.
- The requirements should be complete in every sense.
- The requirements should be practically achievable.
It's important to note that V&V is not a one-time process, but it should be integrated and
continue throughout the software development process and even in the maintenance stage.

11. 5. Requirements Management:
• Requirement management is the process of analyzing, documenting, tracking, prioritizing, and
agreeing on the requirement and controlling the communication with relevant stakeholders.
• The goal of requirements management is to ensure that the software system being developed
meets the needs and expectations of the stakeholders and that it is developed on time, within
budget, and to the required quality.
• Several key activities are involved in requirements management, including:
1. Tracking and controlling changes: This involves monitoring and controlling changes to the
requirements throughout the development process, including identifying the source of the change,
assessing the impact of the change, and approving or rejecting the change.
2. Version control: This involves keeping track of different versions of the requirements document and
other related artifacts.
3. Traceability: This involves linking the requirements to other elements of the development process,
such as design, testing, and validation.

12. 4. Communication: This involves ensuring that the requirements are communicated effectively
to all stakeholders and that any changes or issues are addressed promptly.
5. Monitoring and reporting: This involves monitoring the progress of the development
process and reporting on the status of the requirements.
• Requirements management is a critical step in the software development life cycle as it helps
to ensure that the software system being developed meets the needs and expectations of
stakeholders and that it is developed on time, within budget, and to the required quality.
• It also helps to prevent scope creep and to ensure that the requirements are aligned with the
project goals.

13. Establishing the Groundwork
• This step is about preparing to gather requirements by understanding who is involved, what
the real problem is, and what the solution should achieve.
1. Identifying the Stakeholders:
• Identified the usual suspects: business operations managers, product managers, marketing
people, internal and external customers, end users, consultants, product engineers, software
engineers, support and maintenance engineers, and others.
• Each stakeholder has a different view of the system, achieves different benefits when the
system is successfully developed, and is open to different risks if the development effort
should fail.
• Questions to ask:
i. Who requested this software? (Find the sponsor or client.)
ii. Who will use the solution? (End-users of the system.)
iii. What are the benefits of building it? (Check if it will save time, money, or improve service.)
iv. Is there an existing solution already? (Maybe software already exists that can be reused.)

14. 2. Recognizing Multiple Viewpoints:
• Different people have different expectations from the software. You must listen to all key
users, customers, and other stakeholders to get a complete picture.
3. Working Toward Collaboration:
• You aim to create a good relationship between the development team and the stakeholders.
This helps in clear communication and smoother development.
4. Asking the First Questions (About the Problem & Solution):
• These questions help you understand the problem and what the user wants:
• What does good output look like to you?
Understand what results the user expects.
• What problems should the system solve?
Know the real issues the software must fix.
• Where will this software be used?
Understand the business or work environment.
• Are there any performance constraints?
Ask about speed, memory, or special conditions the system must meet.

15. Quality Function Deployment
• QFD is a method used to translate customer needs into technical requirements during
product or software development. It helps ensure that the final product meets or exceeds
customer expectations.
• Three Types of Requirements in QFD:
i. Normal Requirements:
These are clearly stated by the customer during meetings.
If present, the customer is satisfied.
Example: Display formats, performance level, basic functions.
ii. Expected Requirements:
These are not always stated but are assumed to be present.
If missing, customers become very dissatisfied.
Example: Ease of use, reliability, proper working of the system.
iii. Exciting Requirements:
These are extra features that delight the customer when included.
They are not expected, but make the product stand out.
Example: Touchscreen gestures, smart suggestions, voice assistant.

16. Unified Modelling Languages(UML)
• Unified Modeling Language (UML) is a standardized modeling language used in software
engineering for visualizing, specifying, constructing, and documenting the artifacts of software
systems.
• It provides a common and standardized way to visualize the design of a system, facilitating
communication among stakeholders, capturing system requirements, and guiding the software
development process.
• Types of UML diagrams:
i. Use case
ii. Flow oriented Modeling
iii. Behavioral Modeling

17. Use Case Diagram
• A Use Case Diagram is a type of Unified Modeling Language (UML) diagram that represents
the interaction between actors (users or external systems) and a system under consideration to
accomplish specific goals.
• It provides a high-level view of the system's functionality by illustrating the various ways
users can interact with it.
• Notations of Use Case Diagrams:

18. Flow-oriented modeling
Flow-oriented modeling represents how data moves through a system. It shows the flow of
information, how it is transformed, and how it interacts with different functions or processes.
Key Components:
• Data Flow Diagram (DFD) – shows the flow of data between processes, data stores, and external
entities.
• Notations of DFD –

19. Behavioral Modeling
Behavioral modeling focuses on how the system behaves in response to events or inputs over
time. It helps to understand the dynamic aspects of the system.
Key Components:
• Sequence Diagram – shows the interaction between different system components in sequence.
• Activity Diagram – shows the flow of control from activity to activity.
• Notations of Activity diagram –