The document provides an overview of Software Requirement Specification (SRS) and Software Quality Assurance (SQA). It discusses the importance of well-written requirements documents, as without them developers do not know what to build and customers do not know what to expect. The document also outlines different types of requirements like functional, non-functional, user and system requirements. It describes various requirements elicitation techniques like interviews, brainstorming sessions, use case approach etc. Finally, it discusses modeling requirements using tools like data flow diagrams, data dictionaries and entity relationship diagrams.
1. Requirement engineering is the process of defining what a system should do and its constraints. It includes requirements elicitation, analysis, documentation, review and management. The output is a Software Requirements Specification (SRS) document.
2. There are many challenges in requirements engineering including changing requirements, tight schedules, and communication barriers. Requirements can be functional, non-functional, known, unknown, or undreamed. Stakeholders provide input through interviews, brainstorming sessions, and use case modeling.
3. The key steps in requirements elicitation are selecting stakeholders, conducting interviews and brainstorming sessions, documenting use cases, and prioritizing requirements. Techniques include interviews, brainstorm
The document discusses requirements analysis and specifications. It provides examples of different types of requirements like functional, non-functional, user, and system requirements. It also describes various requirement elicitation techniques like interviews, brainstorming sessions, FAST, quality function deployment, and use case approach. Context and data flow diagrams are discussed as models for representing requirements. Data dictionaries are described as repositories for defining data items. Finally, entity-relationship modeling is introduced as a way to visually represent entities, attributes, and relationships in a database.
The document summarizes key aspects of system engineering and requirements engineering processes. It discusses how system engineering occurs as a consequence of defining computer-based systems and their elements. It also explains the different levels of abstraction in requirements engineering from inception to specification and management. Example techniques for eliciting requirements like use cases and collaborative meetings are also outlined.
This document discusses requirements engineering for software projects. It begins by defining what requirements are, noting that they can range from abstract statements to detailed specifications. There are three types of requirements documents: requirements definition for customers, requirements specification for contracts, and software specifications for developers. The document outlines the sources of requirements, key tasks in requirements engineering like elicitation and validation, and challenges in getting requirements right. It also discusses techniques for gathering requirements like inception, collaborative meetings, use cases, and elaboration of requirements into an analysis model.
The document discusses software engineering concepts related to eliciting requirements and developing use cases. It defines eliciting requirements as collecting requirements through collaborative meetings between developers and customers. Key steps in eliciting requirements include quality function deployment to translate customer needs to technical requirements. Usage scenarios help understand how end users will utilize features. Developing use cases describes them as sequences of user-system interactions to achieve a goal from the user's perspective. Actors represent roles that interact with the system, and user stories provide abbreviated use case descriptions in a problem/solution format.
The document discusses systems analysis activities including requirements modeling. It describes key objectives of the systems analysis phase such as understanding business needs and building a foundation for development. Common techniques used in systems analysis are then outlined, including joint application development (JAD), rapid application development (RAD), and agile methods. Modeling tools that can be used in analysis like functional decomposition diagrams, business process models, data flow diagrams, and unified modeling language diagrams are also introduced.
This lecture provide a review of requirement engineering process. The slides have been prepared after reading Ian Summerville and Roger Pressman work. This lecture is helpful to understand user, and user requirements.
The document discusses requirement engineering, which refers to the process of defining, documenting, and maintaining requirements in the engineering design process. It involves understanding customer needs, assessing feasibility, specifying solutions clearly, and managing requirements as the system is developed. The requirement engineering process involves 5 steps: feasibility study, requirement elicitation and analysis, software requirement specification, validation, and management. It provides details on each step, including the goals, models used, and techniques. It also discusses types of requirements like functional, non-functional, and domain requirements. Finally, it defines software quality assurance as activities that ensure processes, procedures, and standards are suitable and implemented correctly to assure software quality.
1. Requirement engineering is the process of defining what a system should do and its constraints. It includes requirements elicitation, analysis, documentation, review and management. The output is a Software Requirements Specification (SRS) document.
2. There are many challenges in requirements engineering including changing requirements, tight schedules, and communication barriers. Requirements can be functional, non-functional, known, unknown, or undreamed. Stakeholders provide input through interviews, brainstorming sessions, and use case modeling.
3. The key steps in requirements elicitation are selecting stakeholders, conducting interviews and brainstorming sessions, documenting use cases, and prioritizing requirements. Techniques include interviews, brainstorm
The document discusses requirements analysis and specifications. It provides examples of different types of requirements like functional, non-functional, user, and system requirements. It also describes various requirement elicitation techniques like interviews, brainstorming sessions, FAST, quality function deployment, and use case approach. Context and data flow diagrams are discussed as models for representing requirements. Data dictionaries are described as repositories for defining data items. Finally, entity-relationship modeling is introduced as a way to visually represent entities, attributes, and relationships in a database.
The document summarizes key aspects of system engineering and requirements engineering processes. It discusses how system engineering occurs as a consequence of defining computer-based systems and their elements. It also explains the different levels of abstraction in requirements engineering from inception to specification and management. Example techniques for eliciting requirements like use cases and collaborative meetings are also outlined.
This document discusses requirements engineering for software projects. It begins by defining what requirements are, noting that they can range from abstract statements to detailed specifications. There are three types of requirements documents: requirements definition for customers, requirements specification for contracts, and software specifications for developers. The document outlines the sources of requirements, key tasks in requirements engineering like elicitation and validation, and challenges in getting requirements right. It also discusses techniques for gathering requirements like inception, collaborative meetings, use cases, and elaboration of requirements into an analysis model.
The document discusses software engineering concepts related to eliciting requirements and developing use cases. It defines eliciting requirements as collecting requirements through collaborative meetings between developers and customers. Key steps in eliciting requirements include quality function deployment to translate customer needs to technical requirements. Usage scenarios help understand how end users will utilize features. Developing use cases describes them as sequences of user-system interactions to achieve a goal from the user's perspective. Actors represent roles that interact with the system, and user stories provide abbreviated use case descriptions in a problem/solution format.
The document discusses systems analysis activities including requirements modeling. It describes key objectives of the systems analysis phase such as understanding business needs and building a foundation for development. Common techniques used in systems analysis are then outlined, including joint application development (JAD), rapid application development (RAD), and agile methods. Modeling tools that can be used in analysis like functional decomposition diagrams, business process models, data flow diagrams, and unified modeling language diagrams are also introduced.
This lecture provide a review of requirement engineering process. The slides have been prepared after reading Ian Summerville and Roger Pressman work. This lecture is helpful to understand user, and user requirements.
The document discusses requirement engineering, which refers to the process of defining, documenting, and maintaining requirements in the engineering design process. It involves understanding customer needs, assessing feasibility, specifying solutions clearly, and managing requirements as the system is developed. The requirement engineering process involves 5 steps: feasibility study, requirement elicitation and analysis, software requirement specification, validation, and management. It provides details on each step, including the goals, models used, and techniques. It also discusses types of requirements like functional, non-functional, and domain requirements. Finally, it defines software quality assurance as activities that ensure processes, procedures, and standards are suitable and implemented correctly to assure software quality.
The document discusses principles of software requirements analysis. It covers topics like requirements engineering, types of requirements, software requirements specification, problems in requirements specification, requirements gathering tools, modeling system architecture using techniques like data flow diagrams and entity relationship diagrams, software prototyping and metrics. The objectives of requirements analysis are to understand significance, develop software requirements specification document, and know various analysis tools and techniques.
The document discusses requirements elicitation, which involves determining what a system or product needs to do from users and stakeholders. It notes that requirements elicitation is difficult because stakeholders may not know their needs, have conflicting needs, or changing needs. The document then describes different types of requirements like functional requirements, which define what a system does, and non-functional requirements, also called quality attributes, which define how the system achieves its functions. Examples of different types of requirements are also provided.
The document summarizes key concepts from a lecture on requirement engineering. It defines requirements as descriptions of the services and constraints needed for a system. Requirement engineering is the process of discovering, analyzing, documenting, and validating system requirements through tasks like stakeholder interviews, document analysis, and specification. It explains that requirements come from users and stakeholders, and are documented in various forms like user requirements, system requirements, and software design specifications to communicate needs to different audiences like clients, engineers, and developers.
Software is a set of instructions and data structures that enable computer programs to provide desired functions and manipulate information. Software engineering is the systematic development and maintenance of software. It differs from software programming in that engineering involves teams developing complex, long-lasting systems through roles like architect and manager, while programming involves single developers building small, short-term applications. A software development life cycle like waterfall or spiral model provides structure to a project through phases from requirements to maintenance. Rapid application development emphasizes short cycles through business, data, and process modeling to create reusable components and reduce testing time.
Requirements engineering is the process of establishing customer requirements and constraints for a system. It involves tasks such as inception, elicitation, elaboration, negotiation, specification, validation, and requirements management. The goal is to define what the customer wants in a structured, organized manner through techniques like collaborative gathering, use case development, and quality function deployment. This establishes a solid foundation for design and construction of the software system.
This document provides an overview of systems analysis, including the differences between systems analysis and design, common phases and tasks of systems analysis like requirements discovery, and different approaches to systems analysis like structured analysis and accelerated systems analysis using prototypes. It describes tasks involved in scope definition, problem analysis, requirements analysis, logical design, and decision analysis phases.
SE2023 0201 Software Analysis and Design.pptxBharat Chawda
This document provides an overview of software analysis and design. It discusses requirements gathering and analysis, the software requirements specification document, the design process, concepts of cohesion and coupling, data modeling, data flow diagrams, scenario based modeling, and architectural design decisions. The document is intended as a curriculum for diploma students in computer/IT engineering based on textbooks on software engineering. It covers topics such as the system analyst role, requirements elicitation techniques, requirements analysis to identify anomalies, characteristics of a good requirements specification, classification of customer requirements, the design process, design methodologies, and classifications of cohesion and coupling.
Requirements engineering is the process of establishing the services a system should provide and the constraints under which it should operate. It involves several key tasks: inception to understand the problem domain; elicitation to gather requirements; elaboration to refine and model requirements; negotiation to prioritize requirements; specification to document requirements; validation to verify requirements; and management to track requirements throughout the project. The goal is to clearly define what the customer wants in order to establish a solid foundation for software development.
The document provides an overview of requirements analysis and specification. It discusses the importance of thoroughly understanding requirements before building a system. Requirements analysis involves gathering requirements through techniques like interviews and analyzing them to resolve inconsistencies. The key outputs are the software requirements specification document, which describes the system functions, non-functional requirements, and constraints in a black-box manner. Complex logic is represented using decision trees and tables. The overall goals are to fully understand user needs and document them properly to form the basis for development.
The document discusses key concepts in software requirements engineering including requirements, requirements engineering activities, and types of requirements. It defines a requirement as a statement that captures stakeholder needs and must be met for a system to solve a problem. Requirements engineering involves eliciting, analyzing, specifying, and managing requirements throughout the system development lifecycle. There are functional requirements that define what a system should do and non-functional requirements relating to qualities like performance, security, and usability. The document outlines common requirements engineering processes such as elicitation, analysis, specification, and management.
The document discusses various types of software requirements including functional requirements, non-functional requirements, interface requirements, and design and constraints requirements. It provides details on each type of requirement such as how functional requirements define the basic facilities the system should offer and how non-functional requirements relate to quality constraints. The document also covers requirement engineering processes like elicitation, analysis, specification, verification and validation, and management. Overall, the document provides an overview of different classifications of software requirements and the requirement engineering lifecycle.
This document provides an overview and requirements for a marketplace application called Mingle Box. The application allows buyers to find and hire freelance coders for custom software projects. Coders can access work from buyers around the world. The document outlines functional requirements like registration, bidding, and payments. It also discusses technical requirements, feasibility, and includes a high-level data flow diagram. The goal is to connect buyers and coders in a safe, cost-effective manner through an online bidding system.
The document discusses the system development life cycle (SDLC), which includes preliminary investigation, requirements analysis, system design, software development, system testing, and implementation and maintenance. It describes the purpose and history of SDLC as emerging in the 1960s to address the "software crisis". It also outlines the main steps and activities in each phase of the SDLC process.
The document discusses the system development life cycle (SDLC), which involves 6 main steps: 1) preliminary investigation, 2) requirements analysis, 3) system design, 4) system acquisition and development, 5) system testing, and 6) implementation and maintenance. It describes each step in detail, including gathering user requirements, designing and selecting a software model, testing the system, training users, and evaluating the results. The SDLC aims to efficiently develop high-quality software through a structured process of analysis, design, implementation, and maintenance activities.
The document discusses requirements analysis for software engineering projects. It describes requirements analysis as bridging system requirements and software design by providing models of system information, functions, and behavior. The objectives of analysis are identified as identifying customer needs, evaluating feasibility, allocating functions, and establishing schedules and constraints. Common analysis techniques discussed include interviews, use cases, prototyping, and specification documentation.
The document discusses the process of requirements engineering. It begins by defining requirements engineering as the process of defining, documenting, and maintaining requirements. It then outlines the key tasks in requirements engineering: inception, elicitation, elaboration, negotiation, specification, validation, and management. For each task, it provides details on the goals and steps involved. Overall, the document provides a comprehensive overview of requirements engineering and the various activities that comprise the process.
Requirement engineering is the key phase in software development that determines what to build and outlines the quality of the final product. It involves discovering, modeling, documenting, and managing requirements through elicitation, analysis, specification, validation, and management processes. The goal is to develop a system requirements specification document that describes required system functionalities at varying levels of detail, from abstract statements to precise mathematical specifications.
software requirement and architecture.pdfwajoce8790
The document discusses requirements analysis and specification. It provides background on how requirements analysis is more difficult for large problems compared to small problems. The input is user needs and the output is a precise statement of what the future system will do. Requirements analysis necessarily involves interacting with people and ends with a software requirements specification document that specifies what the proposed system should do. A good requirements analysis and specification is essential for developing high quality software.
The document discusses principles of software requirements analysis. It covers topics like requirements engineering, types of requirements, software requirements specification, problems in requirements specification, requirements gathering tools, modeling system architecture using techniques like data flow diagrams and entity relationship diagrams, software prototyping and metrics. The objectives of requirements analysis are to understand significance, develop software requirements specification document, and know various analysis tools and techniques.
The document discusses requirements elicitation, which involves determining what a system or product needs to do from users and stakeholders. It notes that requirements elicitation is difficult because stakeholders may not know their needs, have conflicting needs, or changing needs. The document then describes different types of requirements like functional requirements, which define what a system does, and non-functional requirements, also called quality attributes, which define how the system achieves its functions. Examples of different types of requirements are also provided.
The document summarizes key concepts from a lecture on requirement engineering. It defines requirements as descriptions of the services and constraints needed for a system. Requirement engineering is the process of discovering, analyzing, documenting, and validating system requirements through tasks like stakeholder interviews, document analysis, and specification. It explains that requirements come from users and stakeholders, and are documented in various forms like user requirements, system requirements, and software design specifications to communicate needs to different audiences like clients, engineers, and developers.
Software is a set of instructions and data structures that enable computer programs to provide desired functions and manipulate information. Software engineering is the systematic development and maintenance of software. It differs from software programming in that engineering involves teams developing complex, long-lasting systems through roles like architect and manager, while programming involves single developers building small, short-term applications. A software development life cycle like waterfall or spiral model provides structure to a project through phases from requirements to maintenance. Rapid application development emphasizes short cycles through business, data, and process modeling to create reusable components and reduce testing time.
Requirements engineering is the process of establishing customer requirements and constraints for a system. It involves tasks such as inception, elicitation, elaboration, negotiation, specification, validation, and requirements management. The goal is to define what the customer wants in a structured, organized manner through techniques like collaborative gathering, use case development, and quality function deployment. This establishes a solid foundation for design and construction of the software system.
This document provides an overview of systems analysis, including the differences between systems analysis and design, common phases and tasks of systems analysis like requirements discovery, and different approaches to systems analysis like structured analysis and accelerated systems analysis using prototypes. It describes tasks involved in scope definition, problem analysis, requirements analysis, logical design, and decision analysis phases.
SE2023 0201 Software Analysis and Design.pptxBharat Chawda
This document provides an overview of software analysis and design. It discusses requirements gathering and analysis, the software requirements specification document, the design process, concepts of cohesion and coupling, data modeling, data flow diagrams, scenario based modeling, and architectural design decisions. The document is intended as a curriculum for diploma students in computer/IT engineering based on textbooks on software engineering. It covers topics such as the system analyst role, requirements elicitation techniques, requirements analysis to identify anomalies, characteristics of a good requirements specification, classification of customer requirements, the design process, design methodologies, and classifications of cohesion and coupling.
Requirements engineering is the process of establishing the services a system should provide and the constraints under which it should operate. It involves several key tasks: inception to understand the problem domain; elicitation to gather requirements; elaboration to refine and model requirements; negotiation to prioritize requirements; specification to document requirements; validation to verify requirements; and management to track requirements throughout the project. The goal is to clearly define what the customer wants in order to establish a solid foundation for software development.
The document provides an overview of requirements analysis and specification. It discusses the importance of thoroughly understanding requirements before building a system. Requirements analysis involves gathering requirements through techniques like interviews and analyzing them to resolve inconsistencies. The key outputs are the software requirements specification document, which describes the system functions, non-functional requirements, and constraints in a black-box manner. Complex logic is represented using decision trees and tables. The overall goals are to fully understand user needs and document them properly to form the basis for development.
The document discusses key concepts in software requirements engineering including requirements, requirements engineering activities, and types of requirements. It defines a requirement as a statement that captures stakeholder needs and must be met for a system to solve a problem. Requirements engineering involves eliciting, analyzing, specifying, and managing requirements throughout the system development lifecycle. There are functional requirements that define what a system should do and non-functional requirements relating to qualities like performance, security, and usability. The document outlines common requirements engineering processes such as elicitation, analysis, specification, and management.
The document discusses various types of software requirements including functional requirements, non-functional requirements, interface requirements, and design and constraints requirements. It provides details on each type of requirement such as how functional requirements define the basic facilities the system should offer and how non-functional requirements relate to quality constraints. The document also covers requirement engineering processes like elicitation, analysis, specification, verification and validation, and management. Overall, the document provides an overview of different classifications of software requirements and the requirement engineering lifecycle.
This document provides an overview and requirements for a marketplace application called Mingle Box. The application allows buyers to find and hire freelance coders for custom software projects. Coders can access work from buyers around the world. The document outlines functional requirements like registration, bidding, and payments. It also discusses technical requirements, feasibility, and includes a high-level data flow diagram. The goal is to connect buyers and coders in a safe, cost-effective manner through an online bidding system.
The document discusses the system development life cycle (SDLC), which includes preliminary investigation, requirements analysis, system design, software development, system testing, and implementation and maintenance. It describes the purpose and history of SDLC as emerging in the 1960s to address the "software crisis". It also outlines the main steps and activities in each phase of the SDLC process.
The document discusses the system development life cycle (SDLC), which involves 6 main steps: 1) preliminary investigation, 2) requirements analysis, 3) system design, 4) system acquisition and development, 5) system testing, and 6) implementation and maintenance. It describes each step in detail, including gathering user requirements, designing and selecting a software model, testing the system, training users, and evaluating the results. The SDLC aims to efficiently develop high-quality software through a structured process of analysis, design, implementation, and maintenance activities.
The document discusses requirements analysis for software engineering projects. It describes requirements analysis as bridging system requirements and software design by providing models of system information, functions, and behavior. The objectives of analysis are identified as identifying customer needs, evaluating feasibility, allocating functions, and establishing schedules and constraints. Common analysis techniques discussed include interviews, use cases, prototyping, and specification documentation.
The document discusses the process of requirements engineering. It begins by defining requirements engineering as the process of defining, documenting, and maintaining requirements. It then outlines the key tasks in requirements engineering: inception, elicitation, elaboration, negotiation, specification, validation, and management. For each task, it provides details on the goals and steps involved. Overall, the document provides a comprehensive overview of requirements engineering and the various activities that comprise the process.
Requirement engineering is the key phase in software development that determines what to build and outlines the quality of the final product. It involves discovering, modeling, documenting, and managing requirements through elicitation, analysis, specification, validation, and management processes. The goal is to develop a system requirements specification document that describes required system functionalities at varying levels of detail, from abstract statements to precise mathematical specifications.
software requirement and architecture.pdfwajoce8790
The document discusses requirements analysis and specification. It provides background on how requirements analysis is more difficult for large problems compared to small problems. The input is user needs and the output is a precise statement of what the future system will do. Requirements analysis necessarily involves interacting with people and ends with a software requirements specification document that specifies what the proposed system should do. A good requirements analysis and specification is essential for developing high quality software.
KIT-601-L-UNIT-1 (Revised) Introduction to Data Analytcs.pdfDr. Radhey Shyam
The document provides an overview of data analytics and big data concepts. It discusses the characteristics of big data, including the four V's of volume, velocity, variety and veracity. It describes different types of data like structured, semi-structured and unstructured data. The document also introduces popular big data platforms like Hadoop, Spark and Cassandra. Finally, it outlines key reasons for the need of data analytics, such as enabling better decision making and improving organizational efficiency.
SE-UNIT-3-II-Software metrics, numerical and their solutions.pdfDr. Radhey Shyam
1) The document discusses software metrics and Halstead's software science measures including program length, vocabulary, volume, difficulty, and effort. It provides the formulas to calculate these measures and an example calculation for a C function.
2) Guidelines are provided for identifying operands and operators when applying Halstead's measures to source code. Various program elements like variables, functions, and statements are classified.
3) References on software engineering and metrics are listed at the end.
Introduction to Data Analytics and data analytics life cycleDr. Radhey Shyam
The document provides an overview of data analytics and big data concepts. It discusses the characteristics of big data, including the four V's of volume, velocity, variety and veracity. It also describes different types of data like structured, semi-structured and unstructured data. The document then introduces big data platforms and tools like Hadoop, Spark and Cassandra. Finally, it discusses the need for data analytics in business, including enabling better decision making and improving efficiency.
This document provides an overview of database normalization concepts. It begins by defining normalization as the process of organizing data in a database to eliminate redundant data and ensure data dependencies are properly represented by constraints. It then discusses first normal form (1NF), which requires each cell to contain a single value. Candidate keys and super keys are also defined. The document concludes by briefly mentioning higher normal forms up to fifth normal form (5NF) and some alternative database design approaches such as NoSQL and graph databases.
The document provides information about the syllabus for the Data Analytics (KIT-601) course. It includes 5 units that will be covered: Introduction to Data Analytics, Data Analysis techniques including regression modeling and multivariate analysis, Mining Data Streams, Frequent Itemsets and Clustering, and Frameworks and Visualization. It lists the course outcomes and Bloom's taxonomy levels. It also provides details on the topics to be covered in each unit, including proposed lecture hours, textbooks, and an evaluation scheme. The syllabus aims to discuss concepts of data analytics and apply techniques such as classification, regression, clustering, and frequent pattern mining on data.
This document provides an introduction to the concepts of data analytics and the data analytics lifecycle. It discusses big data in terms of the 4Vs - volume, velocity, variety and veracity. It also discusses other characteristics of big data like volatility, validity, variability and value. The document then discusses various concepts in data analytics like traditional business intelligence, data mining, statistical applications, predictive analysis, and data modeling. It explains how these concepts are used to analyze large datasets and derive value from big data. The goal of data analytics is to gain insights and a competitive advantage through analyzing large and diverse datasets.
This document is a slide presentation by Dr. Radhey Shyam on the topics of reinforcement learning and genetic algorithms. It discusses various types of applications that genetic algorithms can be used for, including control systems, design optimization, scheduling, robotics, machine learning, signal processing, game playing, and solving combinatorial optimization problems. Examples provided include gas pipeline control, missile evasion, aircraft design, manufacturing scheduling, neural network design, filter design, and solving the traveling salesman problem.
This document provides an overview of self-organizing maps (SOMs), a type of artificial neural network. It discusses the biological motivation for SOMs, which are inspired by self-organizing systems in the brain. The document outlines the basic architecture and learning algorithm of SOMs, including initialization, training procedures, and classification. It also reviews various properties of SOMs, such as their ability to approximate input spaces and perform topological ordering and density matching. Finally, applications of SOMs are briefly mentioned, such as for speech recognition, image analysis, and data visualization.
The document describes Convolutional Neural Networks (CNNs). It explains that CNNs are a type of neural network that uses convolutional layers, which apply filters to input data to extract features. This helps reduce the number of parameters needed compared to fully connected networks. The document provides examples of how CNNs can be used for image recognition, speech recognition, and text classification by applying filters that move across spatial or temporal dimensions of the input data.
1) The document discusses software metrics and Halstead's software science measures including program length, vocabulary, volume, difficulty, and effort. It provides the formulas to calculate these measures and an example calculation for a C function.
2) Guidelines are provided for identifying operands and operators when applying Halstead's measures to source code. Various program elements like variables, functions, and statements are classified.
3) The document also discusses other software metrics like lines of code (LOC) and function points which can be used to measure size and complexity. It provides a sample calculation of LOC and function points for a simple program.
This document provides a 3 paragraph summary of a software engineering course titled "Software Engineering (KCS-601)" taught by Dr. Radhey Shyam at SRMCEM Lucknow. The course contents were compiled by Dr. Shyam and are available for students' academic use. Students can contact Dr. Shyam via email for any queries regarding the course material.
This document provides an overview of the unit 3 course material for Software Design taught by Dr. Radhey Shyam at SRMCEM Lucknow. The document discusses key concepts in software design including the importance of design, characteristics of good and bad design, coupling and cohesion, modularization, design models, high level design and architectural design. Specific topics covered include software design documentation, conceptual vs technical design, types of coupling and cohesion, advantages of modular systems, design frameworks, and strategies for design such as top-down, bottom-up, and hybrid approaches.
This document discusses image representation and description techniques. It begins by explaining that image segmentation results in a set of regions that need to be represented, often by their boundaries or internal characteristics, and described using features. Several boundary and regional representation and description methods are then outlined, including chain codes, shape numbers, Fourier descriptors, statistical moments, topology, and textures.
This document discusses image segmentation using morphological watersheds. It begins by explaining the concepts of regional minima, catchment basins, and watershed lines in a topographic representation of an image. It then describes the watershed algorithm which involves flooding the image from regional minima and building dams when flood waters would merge. The resulting dams represent the watershed lines and segmented boundaries. The document provides examples to illustrate the flooding process and discusses how markers can be used to limit oversegmentation from noise.
This document discusses image restoration and contains summaries of several lecture slides on image degradation and restoration models, noise models, and frequency domain filtering techniques for periodic noise reduction. It was compiled by Dr. Radhey Shyam with contributions from Dr. Philippe Cattin, and is intended for academic use by students to help explain basic concepts of image restoration.
The document is a unit on image enhancement from an image processing course. It was written by Dr. Radhey Shyam of the computer science department at BIET Lucknow, India. The unit introduces basic concepts of image enhancement in the spatial and frequency domains. Students will learn about arithmetic and logical operations on pixels to enhance images.
Advanced control scheme of doubly fed induction generator for wind turbine us...IJECEIAES
This paper describes a speed control device for generating electrical energy on an electricity network based on the doubly fed induction generator (DFIG) used for wind power conversion systems. At first, a double-fed induction generator model was constructed. A control law is formulated to govern the flow of energy between the stator of a DFIG and the energy network using three types of controllers: proportional integral (PI), sliding mode controller (SMC) and second order sliding mode controller (SOSMC). Their different results in terms of power reference tracking, reaction to unexpected speed fluctuations, sensitivity to perturbations, and resilience against machine parameter alterations are compared. MATLAB/Simulink was used to conduct the simulations for the preceding study. Multiple simulations have shown very satisfying results, and the investigations demonstrate the efficacy and power-enhancing capabilities of the suggested control system.
International Conference on NLP, Artificial Intelligence, Machine Learning an...gerogepatton
International Conference on NLP, Artificial Intelligence, Machine Learning and Applications (NLAIM 2024) offers a premier global platform for exchanging insights and findings in the theory, methodology, and applications of NLP, Artificial Intelligence, Machine Learning, and their applications. The conference seeks substantial contributions across all key domains of NLP, Artificial Intelligence, Machine Learning, and their practical applications, aiming to foster both theoretical advancements and real-world implementations. With a focus on facilitating collaboration between researchers and practitioners from academia and industry, the conference serves as a nexus for sharing the latest developments in the field.
Null Bangalore | Pentesters Approach to AWS IAMDivyanshu
#Abstract:
- Learn more about the real-world methods for auditing AWS IAM (Identity and Access Management) as a pentester. So let us proceed with a brief discussion of IAM as well as some typical misconfigurations and their potential exploits in order to reinforce the understanding of IAM security best practices.
- Gain actionable insights into AWS IAM policies and roles, using hands on approach.
#Prerequisites:
- Basic understanding of AWS services and architecture
- Familiarity with cloud security concepts
- Experience using the AWS Management Console or AWS CLI.
- For hands on lab create account on [killercoda.com](https://killercoda.com/cloudsecurity-scenario/)
# Scenario Covered:
- Basics of IAM in AWS
- Implementing IAM Policies with Least Privilege to Manage S3 Bucket
- Objective: Create an S3 bucket with least privilege IAM policy and validate access.
- Steps:
- Create S3 bucket.
- Attach least privilege policy to IAM user.
- Validate access.
- Exploiting IAM PassRole Misconfiguration
-Allows a user to pass a specific IAM role to an AWS service (ec2), typically used for service access delegation. Then exploit PassRole Misconfiguration granting unauthorized access to sensitive resources.
- Objective: Demonstrate how a PassRole misconfiguration can grant unauthorized access.
- Steps:
- Allow user to pass IAM role to EC2.
- Exploit misconfiguration for unauthorized access.
- Access sensitive resources.
- Exploiting IAM AssumeRole Misconfiguration with Overly Permissive Role
- An overly permissive IAM role configuration can lead to privilege escalation by creating a role with administrative privileges and allow a user to assume this role.
- Objective: Show how overly permissive IAM roles can lead to privilege escalation.
- Steps:
- Create role with administrative privileges.
- Allow user to assume the role.
- Perform administrative actions.
- Differentiation between PassRole vs AssumeRole
Try at [killercoda.com](https://killercoda.com/cloudsecurity-scenario/)
The CBC machine is a common diagnostic tool used by doctors to measure a patient's red blood cell count, white blood cell count and platelet count. The machine uses a small sample of the patient's blood, which is then placed into special tubes and analyzed. The results of the analysis are then displayed on a screen for the doctor to review. The CBC machine is an important tool for diagnosing various conditions, such as anemia, infection and leukemia. It can also help to monitor a patient's response to treatment.
Redefining brain tumor segmentation: a cutting-edge convolutional neural netw...IJECEIAES
Medical image analysis has witnessed significant advancements with deep learning techniques. In the domain of brain tumor segmentation, the ability to
precisely delineate tumor boundaries from magnetic resonance imaging (MRI)
scans holds profound implications for diagnosis. This study presents an ensemble convolutional neural network (CNN) with transfer learning, integrating
the state-of-the-art Deeplabv3+ architecture with the ResNet18 backbone. The
model is rigorously trained and evaluated, exhibiting remarkable performance
metrics, including an impressive global accuracy of 99.286%, a high-class accuracy of 82.191%, a mean intersection over union (IoU) of 79.900%, a weighted
IoU of 98.620%, and a Boundary F1 (BF) score of 83.303%. Notably, a detailed comparative analysis with existing methods showcases the superiority of
our proposed model. These findings underscore the model’s competence in precise brain tumor localization, underscoring its potential to revolutionize medical
image analysis and enhance healthcare outcomes. This research paves the way
for future exploration and optimization of advanced CNN models in medical
imaging, emphasizing addressing false positives and resource efficiency.
Software Engineering and Project Management - Introduction, Modeling Concepts...Prakhyath Rai
Introduction, Modeling Concepts and Class Modeling: What is Object orientation? What is OO development? OO Themes; Evidence for usefulness of OO development; OO modeling history. Modeling
as Design technique: Modeling, abstraction, The Three models. Class Modeling: Object and Class Concept, Link and associations concepts, Generalization and Inheritance, A sample class model, Navigation of class models, and UML diagrams
Building the Analysis Models: Requirement Analysis, Analysis Model Approaches, Data modeling Concepts, Object Oriented Analysis, Scenario-Based Modeling, Flow-Oriented Modeling, class Based Modeling, Creating a Behavioral Model.
Generative AI leverages algorithms to create various forms of content
SE UNIT-2.pdf
1. Software Engineering (KCS-601)
Unit-2: Software Requirement Specification (SRS) and
Software Quality Assurance (SQA)
Dr. Radhey Shyam
Professor
Department of Computer Science and Engineering
SRMCEM Lucknow
(Affiliated to Dr. A.P.J. Abdul Kalam Technical University, Lucknow)
Unit-2 have been compiled/prepared by Dr. Radhey Shyam, with grateful acknowledgment who made their
course contents freely available or (Contributed directly or indirectly). Feel free to use this study material
for your own academic purposes. For any query, the communication can be made through my mail
shyam0058@gmail.com.
March 8, 2022
2. RequirementEngineering
Crucial process steps
Quality of product
Without well written document
2
-- Developers do not know what to build
-- Customers do not know what to expect
-- What to validate
Requirements describe
What not How
Produces one large document written in natural
language contains a description of what the system will
do without describing how it will do it.
Process that creates it
3. RequirementEngineering
SRS may act as a contract between developer and customer.
4
-- State of practice
• Requirements are difficult to uncover
• Requirements change
• Tight project Schedule
• Communication barriers
• Market driven software development
• Lack of resources
Requirement Engineering is the disciplined application of
proven principles, methods, tools, and notations to describe a
proposed system’s intended behavior and its associated
constraints.
RequirementEngineering
EXAMPLE:
A University wish to develop a software system for the student result
management of its M.Tech. Programme. A problem statement is to be
prepared for the software development company. The problem
statement may give an overview of the existing system and broad
expectations from the new software system.
5
4. RequirementEngineering
EXAMPLE:
A university wishes to develop a software system for library management
activities. Design the problem statement for the software company.
SOLUTION:
1. Issue of books
2. Return of books
3. Query processing
6
Types of Requirements
Types of Requirements
Known Unknown Undreamed
Requirements Requirements Requirements
Stakeholder: Anyone who should have some direct or indirect
influence on the system requirements.
Requirements
Functional Non-Functional
7
5. Types of Requirements
Functional requirements describe what the software has to
do. They are often called product features.
Non Functional requirements are mostly quality
requirements. That stipulate how well the software does,
what it has to do.
Availability
Reliability
Usability
Flexibility
Maintainability
Portability
Testability
For Users
For Developers
Types of Requirements
User and system requirements
• User requirement are written for the users and include
functional and non functional requirement.
• System requirement are derived from user requirement.
• The user and system requirements are the parts of software
requirement and specification (SRS) document.
9
6. Types of Requirements
Interface Specification
• Important for the customers.
TYPES OF INTERFACES
• Procedural interfaces (also called
Programming Interfaces (APIs)).
• Data structures
• Representation of data.
Application
10
Feasibility Study
A Feasibility Study is a study made before committing to a
project. It leads to a decision:
• go ahead
• do not go ahead
• think again
The main purpose of the feasibility study is to answer one
main question:
“Should we proceed with this project idea?”
11
7. Feasibility Study
The purpose of feasibility study is not to solve the problem, but
to determine whether the problem is worth solving.
It concentrates on the following area :-
1. Operation Feasibility
2. Technical Feasibility
3. Economic Feasibility
12
Elements of a good Feasibility Study
There are total six parts of any feasibility study :
• The Project Scope
• The Current Analysis
• Requirements
• Approach
• Evaluation
• Review
13
8. Perhaps
• Most difficult
• Most critical
• Most error prone
• Most communication intensive
Succeed
effective customer developer partnership
Selection of any method
1. It is the only method that we know
2. It is our favorite method for all situations
3. We understand intuitively that the method is effective in the
present circumstances.
Normally we rely on first two reasons.
Requirements Elicitation
14
There are number of requirement elicitation methods:-
1.Interviews
2.Brainstorming Sessions
3.FAST
4.Quality function deployment
5.Use Case Approach
Requirements Elicitation
15
9. 1. Interviews
Both parties have a common goal
Selection of stakeholder: Groups to be considered
for interviews:-
1. Entry level personnel
2. Middle level stakeholder
3. Managers
4. Users of the software (Most important)
Success of the
project
16
Types of questions.
1. Any problems with existing system
2. Any Calculation errors
3. Possible reasons for malfunctioning
4. No. of Student Enrolled
5. Possible benefits
6. Satisfied with current policies
7. How are you maintaining the records of previous students?
8. Any requirement of data from other system
9. Any specific problems
10. Any additional functionality
11. Most important goal of the proposed development
At the end, we may have wide variety of expectations from the 17
1. Interviews
10. It is a group technique
Creative Thinking
New ideas Quickly
2. Brainstorming Sessions
18
1. Users 2. Middle Level managers 3. Total Stakeholders
group discussions
Groups
A Facilitator may handle group bias, conflicts carefully.
-- Facilitator may follow a published agenda
-- Every idea will be documented in a way that everyone
can see it.
--A detailed report is prepared.
19
2. Brainstorming Sessions
11. Steps
1. Identify stakeholders
2. List out requirements
3. Degree of importance to each
requirement.
20
Requirements Elicitation
Requirement Engineer may categorize like:
(i)
(ii)
(iii)
It is possible to achieve
It should be deferred & Why
It is impossible and should be dropped
from consideration
First Category requirements will be implemented as
per priority assigned with every requirement.
Requirements Elicitation
21
5 Points : V. Important
4 Points : Important
3 Points : Not Important but nice to have
2 Points : Not important
1 Points : Unrealistic, required
further exploration
12. • Ivar Jacobson & others introduced Use Case
approach for elicitation & modeling.
• Use Case – give functional view
• The terms
Use Case
Use Case Scenario
Use Case Diagram
Use Cases are structured outline or template for
the description of user requirements modeled in a
structured language like English. 22
Often Interchanged
But they are different
5. The Use Case Approach
Use case Scenarios are unstructured descriptions of user
requirements.
Use case diagrams are graphical representations
that may be decomposed into further levels of
abstraction.
Components of Use Case approach
Actor:
An actor or external agent, lies outside the system model,
but interacts with it in some way.
Actor Person, machine, information
System
23
13. • Cockburn distinguishes
secondary actors.
between Primary and
• A Primary actor is one having a goal requiring the
assistance of the system.
• A Secondary actor is one from which System
needs assistance.
Use Cases
A use case is initiated by a user with a particular goal
in mind, and completes successfully when that goal
is satisfied.
24
* It describes the sequence of interactions between
actors and the system necessary to deliver the
services that satisfies the goal.
* Alternate sequence
* System is treated as black box.
Thus
Use Case captures who (actor) does what
(interaction) with the system, for what purpose (goal),
without dealing with system internals.
25
14. 26
REQUIREMENT ANALYSIS
27
Draw the Context Diagram
• This is also called as Fundamental System Model or Level-0 DFD.
• It represents the entire system element as a Single Bubble with input
and output data indicated by incoming and outgoing arrows.
• For example, if bubble A has two inputs x1 and x2, and one output y that
represents A should have exactly two external inputs and one external
output.
15. 28
Context Diagram of Result Mgmt System
This process usually consists of various graphical representations of the
functions, data entities, external entities and the relationships between
them.
This graphical view may help to find incorrect, inconsistent, and missing
requirements.
Such model include –
• Data flow Diagrams
• Data Dictionaries
• ER Diagrams
29
Model the Requirements
16. DFD show the flow of data through the system.
--All names should be unique
-- It is not a flow chart
-- Suppress logical decisions
-- Defer error conditions & error handling until the end of
the analysis
30
Data Flow Diagrams
Symbol Name Function
31
Standard Symbols for DFD’s
Source or sink
A source of system inputs or sink of
System outputs
Data Store
A repository of data, the arrowheads
Indicate net inputs and net outputs
to store.
Process
Performs some transformation of
input data to yield output data
Data flow Used to connect processes to each
other
17. 32
DFD for QUIZ SOFTWARE
33
DFD for UNIVERSITY COURSE REGISTRATION SYSTEM
18. Data Dictionaries are simply repositories to store information
about all data items defines in DFD.
At the requirement stage, the data dictionary should at least
define customer data items, to ensure that the customer and
developer use, the same definitions and terminologies.
Typical information stored include –
• Name of the data item
• Aliases
• Description/Purpose
• Related data items
• Range of Values
• Data Structure Definition
34
Data Dictionaries
The data dictionary has two different kinds of
items: composite data and elemental data.
• Higher-level (composite) elements may be defined in terms of
lower-level items.
• Elemental data are items that cannot be reduced any further
and are defined in terms of the values that it can assume or
some other unambiguous base type.
The general format of a data dictionary is similar to a standard
dictionary; it contains an alphabetically ordered list of entries.
Each entry consists of a formal definition and verbal description
35
Data Dictionaries
19. Entity – Relationship
Model
(ER model)
36
• An Entity – Relationship model (ER model) is an abstract
way to describe a database.
• It is a visual representation of different data using
conventions that describe how these data are related to
each other.
37
Introduction
20. There are three basic elements in ER models:
Entities are the “things” about which we seek
information.
Attributes are the data we collect about the entities.
Relationships provide the structure needed to draw
information from multiple entities.
38
Basic elements in ER model
Entity – rectangle
Attribute -oval
Relationship – diamond
Link - line
39
Symbols used in E-R Diagram
21. Entity
Entities are represented by means of rectangles. Rectangles are named with the
entity set they represent.
[Image: Entities in a school database]
Attributes
Attributes are properties of entities. Attributes are represented by means of
eclipses. Every eclipse represents one attribute and is directly connected to its
entity (rectangle).
40
ER Model
Relationship
A relationship describes how entities interact. For example, the entity
“carpenter” may be related to the entity “table” by the relationship “builds” or
“makes”. Relationships are represented by diamond shapes.
41
ER Model
22. 42
TYPES OF ATTRIBUTES
There are total six types of attributes :-
1. Simple attribute
2. Composite attribute
3. Derived attribute
4. Stored attribute
5. Single valued attribute
6. Multi valued attribute
43
TYPES OF ATTRIBUTES
•Simple attribute: Cannot be split in to further attributes(indivisible). Also
known as Atomic attribute. Ex: Ssn(Social Security Number) or Roll No
23. 44
TYPES OF ATTRIBUTES
•Composite attribute:
Can be divided in to smaller subparts which represent more basic attributes
with independent meaning
Even form hierarchy
Ex: Address, Name
45
TYPES OF ATTRIBUTES
•Derived attribute:
Attribute values are derived from another attribute.
Denoted by dotted oval
Ex - Age
24. 46
TYPES OF ATTRIBUTES
Stored attribute:
Attributes from which the values of other attributes are derived.
For example ‘Date of birth’ of a person is a stored attribute.
47
TYPES OF ATTRIBUTES
Single-valued attribute:
A single valued attribute can have only a single value.
For example a person can have only one ‘date of birth’, ‘age’ ,
Social_Security_Number.etc.
That is a single valued attributes can have only single value. But
it can be simple or composite attribute.
That is ‘date of birth’ is a composite attribute , ‘age’ is a simple
attribute. But both are single valued attributes.
25. 48
TYPES OF ATTRIBUTES
Multi-value attribute:
Attribute may contain more than one values. Denoted by double circled oval
line connecting to the entity in the ER diagram.
Ex: Phone-number, College-degree, email addresses etc
49
KEYS
Keys are of following types:-
1. Candidate Key
2. Composite Key
3. Primary key
4. Foreign Key
The name of each primary key attribute is
underlined.
26. 50
CANDIDATE KEY
• a simple or composite key that is unique and minimal
•unique – no two rows in a table may have the same value at
any time
•minimal – every column must be necessary for uniqueness
•For example, for the entity
Employee(EID, First Name, Last Name, SIN, Address, Phone,
BirthDate, Salary, DepartmentID)
•Possible candidate keys are EID, SIN
51
COMPOSITE KEY
•Composed of more than one attribute
•For example, First Name and Last Name – assuming there is
no one else in the company with the same name, Last Name
and Department ID – assuming two people with the same last
name don’t work in the same department.
•A composite key can have two or more attributes, but it must
be minimal.
27. 52
PRIMARY KEY
•A candidate key is selected by the designer to uniquely
identify tuples in a table. It must not be null.
•A key is chosen by the database designer to be used as an
identifying mechanism for the whole entity set. This is
referred to as the primary key. This key is indicated by
underlining the attribute in the ER model.
•For example Employee(EID, First Name, Last Name, SIN,
Address, Phone, BirthDate, Salary, DepartmentID) – EID is
the Primary key.
53
FOREIGN KEY
•An attribute in one table that references the primary key of
another table OR it can be null.
•Both foreign and primary keys must be of the same data type
•For example: Employee(EID, First Name, Last Name, SIN,
Address, Phone, BirthDate, Salary, DepartmentID) –
DepartmentID is the Foreign key.
28. 54
Graphical Representation in E-R diagram
If there are two entity types involved it is a binary relationship type
If there are three entity types involved it is a ternary relationship type
It is possible to have a n-array relationship (quaternary)
55
DEGREE OF A RELATIONSHIP
It is the number of entity types that participate in a relationship
SALESASSIST PRODUCT
SELLS
CUSTOMER
29. If we have two entity types A and B, the cardinality constraint
specifies the number of instances of entity B that can (or must) be
associated with entity A.
Four possible categories are
One to one (1:1) relationship
One to many (1:m) relationship
Many to one (m:1) relationship
Many to many (m:n) relationship
56
CARDINALITY CONSTRAINTS
The number of instances of one entity that can or must be
associated with each instance of another entity.
57
CARDINALITY CONSTRAINTS
one-to-one
EMPLOYEE DEPARTMENT
MANAGES
1 1
30. 58
CARDINALITY CONSTRAINTS
one to many
EMPLOYEE DEPARTMENT
WORKS-
FOR
M
1
59
CARDINALITY CONSTRAINTS
many-to-one
EMPLOYEE DEPARTMENT
WORKS-
FOR
31. 60
CARDINALITY CONSTRAINTS
many-to-many
EMPLOYEE PROJECT
WORKS-
ON
M N
PARITICIPATION CONSTRAINTS
(OPTIONALITY)
• Specifies minimum number of relationship instances each entity
can participate in .
• This is called minimum cardinality constraint.
• Two type of the participation are : Total And Partial
Specifies if existence of an entity depends on it being related to another entity
via relationship.
PARTICIPATION
TOTAL
PARTIAL
32. • Ex: if company policy says that every employee must work for the
department then participation of employee in work-for is total.
• Total participation is also called existence dependencies.
• Every entity in total set of employee must be related to a department via
WORKS-FOR
• But we can’t say that every employee must MANAGE a department
• Hence relationship is partial.
• Total participation is indicated by double line and partial participation by
single line.
EMPLOYEE DEPARTMENT
WORKS-
FOR
1
N
GENERALIZATION
The process of generalizing entities, where the generalized entities contain the
properties of all the generalized entities is called Generalization. In
generalization, a number of entities are brought together into one generalized
entity based on their similar characteristics. For an example, pigeon, house
sparrow, crow and dove all can be generalized as Birds.
33. SPECIALIZATION
Specialization is a process, which is opposite to generalization, as mentioned above. In
specialization, a group of entities is divided into sub-groups based on their
characteristics. Take a group Person for example. A person has name, date of birth,
gender etc. These properties are common in all persons, human beings. But in a
company, a person can be identified as employee, employer, customer or vendor
based on what role do they play in company
INHERITANCE
One of the important features of Generalization and Specialization, is inheritance, that
is, the attributes of higher-level entities are inherited by the lower level entities.
For example, attributes of a person like name, age, and gender can
be inherited by lower level entities like student and teacher etc.
34. Benefits of ER diagrams
ER diagrams constitute a very useful framework for creating and
manipulating databases.
First, ER diagrams are easy to understand and do not require a person to
undergo extensive training to be able to work with it efficiently and
accurately. This means that designers can use ER diagrams to easily
communicate with developers, customers, and end users, regardless of their
IT proficiency.
Second, ER diagrams are readily translatable into relational tables which can
be used to quickly build databases. In addition, ER diagrams can directly be
used by database developers as the blueprint for implementing data in
specific software applications.
Lastly, ER diagrams may be applied in other contexts such as describing the
different relationships and operations within an organization.
CONSTRUCTING AN ER MODEL
• Before beginning to draw the ER model, read the requirements
specification carefully.
• Document any assumptions you need to make.
1.Identify entities
• list all potential entity types. These are the object
of interest in the system. It is better to put too
many entities in at this stage and them discard
them later if necessary.
35. 2.Remove duplicate entities
• Ensure that they really separate entity types or just
two names for the same thing
• Also do not include the system as an entity type
• e.g. if modelling a library, the entity types might be
books, borrowers, etc.
• The library is the system, thus should not be an entity
type.
3.List the attributes of each entity
• Ensure that the entity types are really needed.
• Are any of them just attributes of another entity
type?
• If so keep them as attributes a nd cross them off
the entity list.
• Do not have attributes of one entity as attributes
of another entity!
36. 4.Mark the primary keys
• Which attributes uniquely identify instances of
that entity type?
5.Define the relationships
• Examine each entity type to see its relationship to
the others.
6.Describe the cardinality and optionality
of the relationships
• Examine the constraints betwee n participating
entities.
7.Remove redundant relationships
• Examine the ER model for redundant
relationships.
• ER modelling is an iterative process, so draw several versions,
refining each one until you are happy with it. Note that there
is no one right answer to the problem, but some solutions
are better than others!
37.
38. EXAMPLE
• “A Country Bus Company owns a number of busses. Each
bus is allocated to a particular route, although some routes may
have several busses. Each route passes through a number of
towns. One or more drivers are allocated to each stage of a
route, which corresponds to a journey through some or all of the
towns on a route. Some of the towns have a garage where
busses are kept and each of the busses are identified by the
registration number and can carry different numbers of
passengers, since the vehicles vary in size and can be single or
double-decked. Each route is identified by a route number and
information is available on the average number of passengers
carried per day for each route. Drivers have an employee number,
name , address, and sometimes a telephone number.”
ENTITIES
• Bus - Company owns busses and will hold information about them.
• Route - Buses travel on routes and will need described.
• Town - Buses pass through towns and need to know about them
• Driver - Company employs drivers, personnel will hold their data.
• Stage - Routes are made up of stages
• Garage - Garage houses buses, and need to know where they are.
39. RELATIONSHIPS
• A bus is allocated to a route and a route may have several buses.
Bus-route (m:1) - is serviced by
• A route comprises of one or more stages.
route-stage (1:m) comprises/has
• One or more drivers are allocated to each stage.
driver-stage (m:1) is allocated
• A stage passes through some or all of the towns on a route.
stage-town (m:n) passes-through
• A route passes through some or all of the towns
route-town (m:n) passes-through
• Some of the towns have a garage
garage-town (1:1) is situated
• A garage keeps buses and each bus has one `home' garage
garage-bus (m:1) is garaged
ER DIAGRAM
40. ATTRIBUTES
• Bus (reg- no,make,size,deck,no-pass)
• Route (route-no,avg-pass)
• Driver (emp - no,name,address,tel-no)
• Town (name)
• Stage (stage - no)
• Garage (name,address)
MORE TECHNIQUES
41. More techniques for data analysis
There are two main techniques available to
analyze and represent complex processing
logic:
1. Decision trees and
2. Decision tables.
DECISION TREES
A decision tree gives a graphic view of the
processing logic involved in decision
making and the corresponding actions
taken.
The edges of a decision tree represent
conditions and the leaf nodes represent
the actions to be performed depending on
the outcome of testing the condition.
42. EXAMPLE
Consider Library Membership Automation Software (LMS) where it should
support the following three options:
1. New member
2. Renewal
3. Cancel membership
New member option
Decision: When the 'new member' option is selected, the software asks
details about the member like member's name, address, phone number etc.
Action: If proper information is entered, then a membership record for the
member is created and a bill is printed for the annual membership charge
plus the security deposit payable.
Example Contd..
Renewal option
Decision: If the 'renewal' option is chosen, the LMS asks for the member's
name and his membership number to check whether he is a valid member or
not.
Action: If the membership is valid then membership expiry date is updated
and the annual membership bill is printed, otherwise an error message is
displayed.
Cancel membership option
Decision: If the 'cancel membership' option is selected, then the software
asks for member's name and his membership number.
Action: The membership is cancelled, a cheque for the balance amount due
to the member is printed and finally the membership record is deleted from
the database.
43. Decision Tree Representation
DECISION TABLES
Decision tables are used mainly because of their visibility,
clearness, coverage capabilities, low maintenance and
automation fitness.
STRUCTURE
The four quadrants
Conditions Condition alternatives
Actions Action entries
44. Decision Table for LMS
EXAMPLE
Suppose a technical support company
writes a decision table to diagnose printer
problems based upon symptoms
described to them over the phone from
their clients.
45. Decision Table
BENEFITS
Decision tables, especially when coupled with the use of
a domain-specific language, allow developers and policy experts
to work from the same information, the decision tables
themselves.
Tools to render nested if statements from traditional
programming languages into decision tables can also be used as
a debugging tool.
Decision tables have proven to be easier to understand and
review than code, and have been used extensively and
successfully to produce specifications for complex systems.
46. REQUIREMENTS
DOCUMENTATION
REQUIREMENTS DOCUMENTATION
This is the way of representing requirements in a consistent
format.
It is called Software Requirement Specification(SRS).
SRS serves many purpose depending upon who is writing it.
written by customer
written by developer
Serves as contract between customer & developer.
47. Nature of the SRS
The basic issues that the SRS writer(s) shall address are the
following:
a) Functionality
b) External Interfaces
c) Performance
d) Attributes
e) Design Constraints imposed on an implementation.
SRS Should
-- Correctly define all requirements
-- not describe any design details
-- not impose any additional constraints
Characteristics of a good SRS
SRS should be
1. Correct
2. Unambiguous
3. Complete
4. Consistent
5. Ranked for importance and/or stability
6. Verifiable
7. Modifiable
8. Traceable
48. Advantages of a SRS
Software SRS establishes the basic for agreement between the
client and the supplier on what the software product will do.
1. A SRS provides a reference for validation of the final product.
2. A high-quality SRS is a prerequisite to high-quality software.
3. A high-quality SRS reduces the development cost.
Problems without a SRS Document
The important problems that an organization would face if it does not
develop an SRS document are as follows:
• Without developing the SRS document, the system would not be
implemented according to customer needs.
• Software developers would not know whether what they are
developing is what exactly is required by the customer.
• Without SRS document, it will be very difficult for the maintenance
engineers to understand the functionality of the system.
• It will be very difficult for user document writers to write the users’
manuals properly without understanding the SRS document.
49. Organization of the SRS
IEEE has published guidelines and standards to organize an SRS.
1. Introduction
1.1
1.2
1.3
1.4
1.5
Purpose
Scope
Definition, Acronyms and abbreviations
References
Overview
2. The Overall Description
2.1 Product Perspective
2.1.1 System Interfaces
2.1.2 Interfaces
2.1.3 Hardware Interfaces
2.1.4 Software Interfaces
2.1.5 Communication Interfaces
2.1.6 Memory Constraints
2.1.7 Operations
2.1.8 Site Adaptation Requirements
Organization of the SRS
2.2
2.3
2.4
2.5
2.6
Product Functions
User Characteristics
Constraints
Assumptions for dependencies
Apportioning of requirements
3. Specific Requirements
3.1External Interfaces
3.2Functions
3.3Performance requirements
3.4Logical database requirements
3.5Design Constraints
3.6Software System attributes
3.7Organization of specific requirements
3.8Additional Comments.
4. Change Management Process
5. Document Approvals
6. Supporting Information
50. REQUIREMENTS
VALIDATION
REQUIREMENTS VALIDATION
After the completion of SRS document, we would like to check the
document for:
Completeness & consistency
Conformance to standards
Requirements conflicts
Technical errors
Ambiguous requirements
The objective of requirements validation is to certify that the SRS
document is an acceptable document of the system to be
implemented.
52. REQUIREMENTS REVIEWS
REQUIREMENTS VALIDATION
Problem actions
• Requirements clarification
• Missing information (find this information from stakeholders)
• Requirements conflicts (Stakeholders must negotiate to resolve
this conflict)
• Unrealistic requirements
• Security issues
53. REVIEW CHECKLISTS
Understandability
Redundancy
Completeness
Ambiguity
Consistency
Organization
Conformance to standards
Traceability
Requirement Management
Process of understanding and controlling changes to system
requirements.
ENDURING & VOLATILE REQUIREMENTS
o Enduring requirements: They are core requirements & are
related to main activity of the organization.
Example: issue/return of a book, cataloging etc.
o Volatile requirements: likely to change during software
development life cycle or after delivery of the product
54. Requirement Management Planning
• Very critical.
• Important for the success of any
project.
Requirement Change Management
Requirements change process should include the following activities to be
carried out when a change is needed in the requirements:-
•Assignment of responsibilities
• Management of changes
• Documentation
•Requirements traceability
• Communication of change
• Establishment of baseline
55. SOFTWARE QUALITY
ASSURANCE
SoftwareQuality
1
0
9
Our objective of software engineering is to produce good quality
maintainable software in time and within budget.
Here, quality is very important.
Different people understand different meaning of quality like:
•Conformance to requirements
•Fitness for the purpose
•Level of satisfaction
When user uses the product, and finds the product fit for its
purpose, he/she feels that product is of good quality.
56. SoftwareQualityAssurance
1
1
0
Software quality assurance (SQA) consists of a means of
monitoring the software engineering processes and methods
used to ensure quality.
Every software developers will agree that high-quality software is
an important goal. Once said, "Every program does something
right, it just may not be the thing that we want it to do."
SoftwareQualityAssurance
1
1
1
The definition serves to emphasize three important points:
1. Software requirements are the foundation from which quality
is measured. Lack of conformance to requirements is lack of
quality.
2. Specified standards define a set of development criteria that
guide the manner in which software is engineered. If the criteria
are not followed, lack of quality will almost surely result.
3. A set of implicit requirements often goes unmentioned (e.g.,
the desire for ease of use and good maintainability). If software
conforms to its explicit requirements but fails to meet implicit
requirements, software quality is suspect.
57. VerificationandValidation
1
1
2
It is the name given to the checking and analysis process.
The purpose is to ensure that the software conforms to its
specifications and meets the need of the customer.
Verification represents the set of activities that are carried
out to confirm that the software correctly implements the
specific functionality.
Validation represents set of activities that ensure that the
software that has built is satisfying the customer
requirements.
VerificationandValidation
1
1
3
Verification Validation
Are we building the product right? Are we building the right product?
Ensure that the software system
meets all the functionality
Ensure that the functionalities meet
the intended behavior.
Verifications take place first and
include the checking for
documentation, code etc
Validation occurs after verification and
mainly involves the checking of the
overall product.
Done by developers Done by testers
Have static activities as it includes the
reviews, walk-throughs and
inspections to verify that software is
correct or not
Have dynamic activities as it includes
executing the software against the
requirements.
58. VerificationandValidation
1
1
4
In the verification and validation, two techniques of system
checking and analysis may be used:-
1. Software Inspection
2. System testing
The testing can be carried out using following tests:-
i. Unit testing
ii. Module testing
iii. System testing
iv. Acceptance testing
SQAPlans
1
1
5
The SQA Plan provides a road map for instituting software quality
assurance. Developed by the SQA group, the plan serves as a
template for SQA activities that are instituted for each software
project.
The documentation section describes (by reference) each of the
work products produced as part of the software process. These
include –
• project documents (e.g., project plan)
• models (e.g., ERDs, class hierarchies)
• technical documents (e.g., specifications, test plans)
• user documents (e.g., help files)
59. MethodsforSQA
1
1
6
The methods by which quality assurance
is accomplished are many and varied,
out of which, two are mentioned as
follows:
1. ISO 9000
2. Capability Maturity Model
ISO 9000
• “ISO” in greek means “equal”, so the association
wanted to convey the idea of equality.
• It is an attempt to improve software quality
based on ISO 9000 series standards.
• It has been adopted by over 130 countries
including India and Japan.
• One of the problem with ISO-9000 series
standard is that it is not industry specific.
• It can be interpreted by the developers to diverse
projects such as hair dryers, automobiles,
televisions as well as software.
60. Notes
• ISO-9000 applies to all types of organizations.
• After adopting the standards, a country typically
permits only ISO registered companies to supply
goods and services to government agencies and
public utilities.
• ISO-9000 series is not just software standard, but
are applicable to a wide variety of industrial
activities including design/development,
production, installation and servicing.
ISO 9000 Certification
This process consists of following stages:-
1. Application
2. Pre-assessment
3. Document review and adequacy of audit
4. Compliance audit
5. Registration
6. Continued surveillance
61. ISO 9000 Series
The types of software industries to which the different ISO
standards apply are as follows:
ISO 9001 : This standard applies to the organization engaged
in design, development, production & servicing of goods.
This is the standard that is applicable to most software
development organization.
ISO 9002 : This standard applies to the organization which do
not design products but only involved in production. E.g,
Car manufacturing industries.
ISO 9003 : This standard applies to the organization involved
only in installation and testing of the products.
Benefits of ISO 9000 Certification
1. Continuous Improvement
2. Improved Customer Satisfaction
3. Eliminate Variations
4. Better product and Services
5. Improved Profit levels
6. Improved Communication
7. Reduced Cost
62. Capability Maturity Model
• It was developed by Software Engineering
Institute (SEI) of Carnegie-Mellon University in
1986.
• It specifies an increasing series of levels of a
software development organization. The higher
the level, the better the software development
process.
• It can be used in two ways: Capability evaluation
and Software process assessment.
CMM Levels
63. CMM Levels
• Level One :Initial - The software process is characterized as inconsistent, and
occasionally even chaotic. Defined processes and standard practices that
exist are abandoned during a crisis. Success of the organization majorly
depends on an individual effort, talent, and heroics. The heroes eventually
move on to other organizations taking their wealth of knowledge or lessons
learnt with them.
• Level Two: Repeatable - This level of Software Development Organization has
a basic and consistent project management processes to track cost, schedule,
and functionality. The process is in place to repeat the earlier successes on
projects with similar applications. Program management is a key
characteristic of a level two organization.
• Level Three: Defined - The software process for both management and
engineering activities are documented, standardized, and integrated into a
standard software process for the entire organization and all projects across
the organization use an approved, tailored version of the organization's
standard software process for developing, testing and maintaining the
application.
CMM Levels
• Level Four: Managed - Management can effectively control the software
development effort using precise measurements. At this level, organization
set a quantitative quality goal for both software process and software
maintenance. At this maturity level, the performance of processes is
controlled using statistical and other quantitative techniques, and is
quantitatively predictable.
• Level Five: Optimizing - The Key characteristic of this level is focusing on
continually improving process performance through both incremental and
innovative technological improvements. At this level, changes to the process
are to improve the process performance and at the same time maintaining
statistical probability to achieve the established quantitative process-
improvement objectives.
64. Key ProcessAreas of each Level
CMM Level Focus Key Process Areas
Initial Competent people -
Repeatable Project Management Software Project Planning
Software Configuration Management
Defined Definition of Processes Process Definition
Training Program
Peer Reviews
Managed Product and process quality Quantitative Process Metrics
Software Quality Management
Optimizing Continuous Process
Improvement
Defect Prevention
Process Change Management
Technology Change Management
ComparisonofISO-9000Certification&SEI-CMM
1
2
7
ISO focus on the “customer-supplier relationship”, whereas CMM focus on software
supplier to improve its processes to achieve a higher quality product for the benefit
of the customer.
ISO 9000 standard is written for a wide range of industries whereas CMM
framework is specifies for the software industry.
CMM is a five level framework for measuring software engineering practices, and
ISO 9000 defines a minimum level of attributes for a quality management program.
The ISO 9000’s concept is to follow a set of standards to make success repeatable.
The CMM emphasizes a process of continuous improvement.
Once an organization has met the criteria to be ISO certified by an independent
audit, the next step is only to maintain that level of certification. CMM is an on-
going process of evaluation and improvement, moving from one level of
achievement to the next. Even at the highest level of maturity, the focus is on
continuous improvement.
65. References
1. Roger S. Pressman, Software Engineering a Practitioner Approach, 3rd
Edition, TMH, 2005.
2. Rajib Mall, Fundamantal of Software Engineering, 3rd
Edition,PHI Publication, 2007.
3. Deepak Jain, Software Engineering for Practitioners, Ist
Edition, Oxford, 2012.
4. K K Agarwal and Yogesh Singh, Software Engineering, 3rd
Edition,Oxford, 2012.
65