Module2.pptx cyber module 1 hackers tools and techniques

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 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. 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: Who requested this software? (Find the sponsor or client.) Who will use the solution? (End-users of the system.) What are the benefits of building it? (Check if it will save time, money, or improve service.) 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: Use case Flow oriented Modeling 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 –