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.
The document discusses key concepts in software design, including:
- Design involves modeling the system architecture, interfaces, and components before implementation. This allows assessment and improvement of quality.
- Important design concepts span abstraction, architecture, patterns, separation of concerns, modularity, information hiding, and functional independence. Architecture defines overall structure and interactions. Patterns help solve common problems.
- Separation of concerns and related concepts like modularity and information hiding help decompose problems into independently designed and optimized pieces to improve manageability. Functional independence means each module has a single, well-defined purpose with minimal interaction.
The document discusses several prescriptive software process models including:
1) The waterfall model which follows sequential phases from requirements to deployment but lacks iteration.
2) The incremental model which delivers functionality in increments with each phase repeated.
3) Prototyping which focuses on visible aspects to refine requirements through iterative prototypes and feedback.
4) The RAD (Rapid Application Development) model which emphasizes very short development cycles of 60-90 days using parallel teams and automated tools. The document provides descriptions and diagrams of each model.
This document discusses common myths held by software managers, developers, and customers. It describes myths such as believing formal standards and procedures are sufficient, thinking new hardware means high quality development, adding people to late projects will help catch up, and outsourcing means relaxing oversight. Realities discussed include standards not being used effectively, tools being more important than hardware, adding people making projects later, and needing management and control of outsourced projects. Developer myths like thinking the job is done once code runs and quality can't be assessed until code runs are addressed. The document emphasizes the importance of requirements, documentation, quality processes, and addressing change impacts.
The document discusses context models and their use in system modeling. Context models illustrate the operational context of a system by showing what lies outside its boundaries, including other systems in the environment. They help define a system's boundaries and show how IT applications fit into the context of people and organizations. Two examples are provided: (1) a Mental Health Care Patient Management System (MHC-PMS) and its connections to other clinical systems; (2) an Automated Teller Machine (ATM) and its links to banking systems. Context models on their own do not show relationships between external systems, so additional models are needed.
The document discusses various design concepts and elements of the design model in software engineering. It covers 12 key design concepts including abstraction, architecture, patterns, separation of concerns, modularity, and information hiding. It also discusses design classes, refinement, aspects, and refactoring. Additionally, it outlines elements of the design model including data design, architectural design, interface design, component-level design, and deployment-level design. The goal of design is to create a model of software that will correctly implement requirements and provide joy to users.
This document discusses software architecture from both a management and technical perspective. From a management perspective, it defines an architecture as the design concept, an architecture baseline as tangible artifacts that satisfy stakeholders, and an architecture description as a human-readable representation of the design. It also notes that mature processes, clear requirements, and a demonstrable architecture are important for predictable project planning. Technically, it describes Philippe Kruchten's model of software architecture, which includes use case, design, process, component, and deployment views that model different aspects of realizing a system's design.
This document discusses software process models. It defines a software process as a framework for activities required to build high-quality software. A process model describes the phases in a product's lifetime from initial idea to final use. The document then describes a generic process model with five framework activities - communication, planning, modeling, construction, and deployment. It provides an example of identifying task sets for different sized projects. Finally, it discusses the waterfall process model as the first published model, outlining its sequential phases and problems with being rarely linear and requiring all requirements up front.
The document discusses component-based software engineering and defines a software component. A component is a modular building block defined by interfaces that can be independently deployed. Components are standardized, independent, composable, deployable, and documented. They communicate through interfaces and are designed to achieve reusability. The document outlines characteristics of components and discusses different views of components, including object-oriented, conventional, and process-related views. It also covers topics like component-level design principles, packaging, cohesion, and coupling.
The document discusses key concepts in software design, including:
- Design involves modeling the system architecture, interfaces, and components before implementation. This allows assessment and improvement of quality.
- Important design concepts span abstraction, architecture, patterns, separation of concerns, modularity, information hiding, and functional independence. Architecture defines overall structure and interactions. Patterns help solve common problems.
- Separation of concerns and related concepts like modularity and information hiding help decompose problems into independently designed and optimized pieces to improve manageability. Functional independence means each module has a single, well-defined purpose with minimal interaction.
The document discusses several prescriptive software process models including:
1) The waterfall model which follows sequential phases from requirements to deployment but lacks iteration.
2) The incremental model which delivers functionality in increments with each phase repeated.
3) Prototyping which focuses on visible aspects to refine requirements through iterative prototypes and feedback.
4) The RAD (Rapid Application Development) model which emphasizes very short development cycles of 60-90 days using parallel teams and automated tools. The document provides descriptions and diagrams of each model.
This document discusses common myths held by software managers, developers, and customers. It describes myths such as believing formal standards and procedures are sufficient, thinking new hardware means high quality development, adding people to late projects will help catch up, and outsourcing means relaxing oversight. Realities discussed include standards not being used effectively, tools being more important than hardware, adding people making projects later, and needing management and control of outsourced projects. Developer myths like thinking the job is done once code runs and quality can't be assessed until code runs are addressed. The document emphasizes the importance of requirements, documentation, quality processes, and addressing change impacts.
The document discusses context models and their use in system modeling. Context models illustrate the operational context of a system by showing what lies outside its boundaries, including other systems in the environment. They help define a system's boundaries and show how IT applications fit into the context of people and organizations. Two examples are provided: (1) a Mental Health Care Patient Management System (MHC-PMS) and its connections to other clinical systems; (2) an Automated Teller Machine (ATM) and its links to banking systems. Context models on their own do not show relationships between external systems, so additional models are needed.
The document discusses various design concepts and elements of the design model in software engineering. It covers 12 key design concepts including abstraction, architecture, patterns, separation of concerns, modularity, and information hiding. It also discusses design classes, refinement, aspects, and refactoring. Additionally, it outlines elements of the design model including data design, architectural design, interface design, component-level design, and deployment-level design. The goal of design is to create a model of software that will correctly implement requirements and provide joy to users.
This document discusses software architecture from both a management and technical perspective. From a management perspective, it defines an architecture as the design concept, an architecture baseline as tangible artifacts that satisfy stakeholders, and an architecture description as a human-readable representation of the design. It also notes that mature processes, clear requirements, and a demonstrable architecture are important for predictable project planning. Technically, it describes Philippe Kruchten's model of software architecture, which includes use case, design, process, component, and deployment views that model different aspects of realizing a system's design.
This document discusses software process models. It defines a software process as a framework for activities required to build high-quality software. A process model describes the phases in a product's lifetime from initial idea to final use. The document then describes a generic process model with five framework activities - communication, planning, modeling, construction, and deployment. It provides an example of identifying task sets for different sized projects. Finally, it discusses the waterfall process model as the first published model, outlining its sequential phases and problems with being rarely linear and requiring all requirements up front.
The document discusses component-based software engineering and defines a software component. A component is a modular building block defined by interfaces that can be independently deployed. Components are standardized, independent, composable, deployable, and documented. They communicate through interfaces and are designed to achieve reusability. The document outlines characteristics of components and discusses different views of components, including object-oriented, conventional, and process-related views. It also covers topics like component-level design principles, packaging, cohesion, and coupling.
Architecture design in software engineeringPreeti Mishra
The document discusses software architectural design. It defines architecture as the structure of a system's components, their relationships, and properties. An architectural design model is transferable across different systems. The architecture enables analysis of design requirements and consideration of alternatives early in development. It represents the system in an intellectually graspable way. Common architectural styles structure systems and their components in different ways, such as data-centered, data flow, and call-and-return styles.
This document discusses different approaches to requirements modeling including scenario-based modeling using use cases and activity diagrams, data modeling using entity-relationship diagrams, and class-based modeling using class-responsibility-collaborator diagrams. Requirements modeling depicts requirements using text and diagrams to help validate requirements from different perspectives and uncover errors, inconsistencies, and omissions. The models focus on what the system needs to do at a high level rather than implementation details.
This document discusses requirements modeling in software engineering. It covers creating various models during requirements analysis, including scenario-based models, data models, class-oriented models, flow-oriented models, and behavioral models. These models form the requirements model, which is the first technical representation of a system. The document provides examples of writing use cases and constructing a preliminary use case diagram for a home security system called SafeHome. It emphasizes that requirements modeling lays the foundation for software specification and design.
The Unified Process (UP) is a popular iterative software development framework that uses use cases, architecture-centric design, and the Unified Modeling Language. It originated from Jacobson's Objectory process in the 1980s and was further developed by Rational Software into the Rational Unified Process. The UP consists of four phases - inception, elaboration, construction, and transition - and emphasizes iterative development, architectural drivers, and risk-managed delivery.
Unit 5- Architectural Design in software engineering arvind pandey
This document provides an overview of architectural design for software systems. It discusses topics like system organization, decomposition styles, and control styles. The key aspects covered are:
1. Architectural design identifies the subsystems, framework for control/communication, and is described in a software architecture.
2. Common decisions include system structure, distribution, styles, decomposition, and control strategy. Models are used to document the design.
3. Organization styles include repository (shared data), client-server (shared services), and layered (abstract machines). Decomposition can be through objects or pipelines. Control can be centralized or event-based.
The data design action translates data objects into data structures at the software component level.
Data Design is the first and most important design activity. Here the main issue is to select the appropriate data structure i.e. the data design focuses on the definition of data structures.
Data design is a process of gradual refinement, from the coarse "What data does your application require?" to the precise data structures and processes that provide it. With a good data design, your application's data access is fast, easily maintained, and can gracefully accept future data enhancements.
This Presentation contains all the topics in design concept of software engineering. This is much more helpful in designing new product. You have to consider some of the design concepts that are given in the ppt
This document discusses software project management artifacts. Artifacts are organized into management and engineering sets. The management set includes artifacts like the work breakdown structure, business case, and software development plan. The engineering set includes requirement, design, implementation, and deployment artifact sets. Each set captures information through various notations and tools to manage the software development lifecycle.
This document discusses various process models for software engineering. It begins by defining what a process model is and explaining why they are useful. It then covers traditional sequential models like waterfall and V-model. Iterative and incremental models like prototyping and spiral modeling are described which allow for software to evolve through iterations. Other topics covered include concurrent modeling, component-based development, formal methods, aspects, unified process and personal software process. The document provides details on different process patterns, assessment methods and considerations for evolutionary processes.
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.
This document discusses metrics that can be used to measure software processes and projects. It begins by defining software metrics and explaining that they provide quantitative measures that offer insight for improving processes and projects. It then distinguishes between metrics for the software process domain and project domain. Process metrics are collected across multiple projects for strategic decisions, while project metrics enable tactical project management. The document outlines various metric types, including size-based metrics using lines of code or function points, quality metrics, and metrics for defect removal efficiency. It emphasizes integrating metrics into the software process through establishing a baseline, collecting data, and providing feedback to facilitate continuous process improvement.
The document discusses requirements modeling and analysis modeling in software engineering. It provides information on:
1) The different types of models that can be created during requirements modeling, including requirements models, design models, scenario-based models, data models, class-based models, flow-oriented models, and behavioral models.
2) The purposes of requirements modeling, which include representing customer requirements, gaining a better understanding of the system, and providing information to help with system design and development.
3) Key principles of requirements modeling, such as representing the information, functional, and behavioral domains of the system and partitioning models in a layered/hierarchical way.
4) Specific modeling techniques like scenario-based modeling, data
This ppt covers the following
A strategic approach to testing
Test strategies for conventional software
Test strategies for object-oriented software
Validation testing
System testing
The art of debugging
Evolutionary models are iterative and incremental software development approaches that combine iterative and incremental processes. There are two main types: prototyping and spiral models. The prototyping model develops prototypes that are tested and refined based on customer feedback until requirements are met, while the spiral model proceeds through multiple loops or phases of planning, risk analysis, engineering, and evaluation. Both approaches allow requirements to evolve through development and support risk handling.
This document discusses several software cost estimation techniques:
1. Top-down and bottom-up approaches - Top-down estimates system-level costs while bottom-up estimates costs of each module and combines them.
2. Expert judgment - Widely used technique where experts estimate costs based on past similar projects. It utilizes experience but can be biased.
3. Delphi estimation - Estimators anonymously provide estimates in rounds to reach consensus without group dynamics influencing individuals.
4. Work breakdown structure - Hierarchical breakdown of either the product components or work activities to aid bottom-up estimation.
Software Engineering Important Short Question for ExamsMuhammadTalha436
The document discusses various topics related to software engineering including:
1. The software development life cycle (SDLC) and its phases like requirements, design, implementation, testing, etc.
2. The waterfall model and its phases from modeling to maintenance.
3. The purpose of feasibility studies, data flow diagrams, and entity relationship diagrams.
4. Different types of testing done during the testing phase like unit, integration, system, black box and white box testing.
Formal Specification in Software Engineering SE9koolkampus
This document discusses formal specification techniques for software. It describes algebraic techniques for specifying interfaces as abstract data types and model-based techniques for specifying system behavior. Algebraic specifications define operations and their relationships, while model-based specifications represent the system state using mathematical constructs like sets and sequences. Formal specification finds errors earlier and reduces rework, though it requires more upfront effort. The document also provides an example of formally specifying an air traffic control system and insulin pump.
User Interface Design in Software Engineering SE15koolkampus
The document discusses principles of user interface design including interaction styles, information presentation, user support, and evaluation. It covers topics such as direct manipulation, menu selection, command languages, using color and graphics effectively, designing helpful error messages and documentation, and evaluating interfaces against usability specifications. The goal is to provide user-centered interfaces that are logical, consistent, and help users recover from errors.
Flow-oriented modeling represents how data objects are transformed as they move through a system. A data flow diagram (DFD) is the diagrammatic form used to depict this approach. DFDs show the flow of data through processes and external entities of a system using symbols like circles and arrows. They provide a unique view of how a system works by modeling the input, output, storage and processing of data from level to level.
The document discusses formal approaches to software quality assurance (SQA). It states that SQA can be improved through software engineering practices like technical reviews, multi-tiered testing, controlling work products and changes, and following standards. It also argues that a more rigorous mathematical approach is needed for SQA since programs can be viewed as mathematical objects with rigorous syntax and semantics defined for languages, allowing proofs of correctness.
This document discusses understanding requirements in software engineering. It outlines the key tasks in requirements engineering as inception, elicitation, elaboration, negotiation, specification, validation and management. Elicitation involves drawing requirements from stakeholders but can be difficult due to problems with scope, volatility, understanding and communication. Elaboration develops a refined technical model using information from inception and elicitation. Negotiation aims to agree on a realistic deliverable through prioritization and negotiation. Specification can take various forms depending on the system. Validation reviews the specification for errors and omissions. Requirements management handles changing requirements throughout the project.
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.
Architecture design in software engineeringPreeti Mishra
The document discusses software architectural design. It defines architecture as the structure of a system's components, their relationships, and properties. An architectural design model is transferable across different systems. The architecture enables analysis of design requirements and consideration of alternatives early in development. It represents the system in an intellectually graspable way. Common architectural styles structure systems and their components in different ways, such as data-centered, data flow, and call-and-return styles.
This document discusses different approaches to requirements modeling including scenario-based modeling using use cases and activity diagrams, data modeling using entity-relationship diagrams, and class-based modeling using class-responsibility-collaborator diagrams. Requirements modeling depicts requirements using text and diagrams to help validate requirements from different perspectives and uncover errors, inconsistencies, and omissions. The models focus on what the system needs to do at a high level rather than implementation details.
This document discusses requirements modeling in software engineering. It covers creating various models during requirements analysis, including scenario-based models, data models, class-oriented models, flow-oriented models, and behavioral models. These models form the requirements model, which is the first technical representation of a system. The document provides examples of writing use cases and constructing a preliminary use case diagram for a home security system called SafeHome. It emphasizes that requirements modeling lays the foundation for software specification and design.
The Unified Process (UP) is a popular iterative software development framework that uses use cases, architecture-centric design, and the Unified Modeling Language. It originated from Jacobson's Objectory process in the 1980s and was further developed by Rational Software into the Rational Unified Process. The UP consists of four phases - inception, elaboration, construction, and transition - and emphasizes iterative development, architectural drivers, and risk-managed delivery.
Unit 5- Architectural Design in software engineering arvind pandey
This document provides an overview of architectural design for software systems. It discusses topics like system organization, decomposition styles, and control styles. The key aspects covered are:
1. Architectural design identifies the subsystems, framework for control/communication, and is described in a software architecture.
2. Common decisions include system structure, distribution, styles, decomposition, and control strategy. Models are used to document the design.
3. Organization styles include repository (shared data), client-server (shared services), and layered (abstract machines). Decomposition can be through objects or pipelines. Control can be centralized or event-based.
The data design action translates data objects into data structures at the software component level.
Data Design is the first and most important design activity. Here the main issue is to select the appropriate data structure i.e. the data design focuses on the definition of data structures.
Data design is a process of gradual refinement, from the coarse "What data does your application require?" to the precise data structures and processes that provide it. With a good data design, your application's data access is fast, easily maintained, and can gracefully accept future data enhancements.
This Presentation contains all the topics in design concept of software engineering. This is much more helpful in designing new product. You have to consider some of the design concepts that are given in the ppt
This document discusses software project management artifacts. Artifacts are organized into management and engineering sets. The management set includes artifacts like the work breakdown structure, business case, and software development plan. The engineering set includes requirement, design, implementation, and deployment artifact sets. Each set captures information through various notations and tools to manage the software development lifecycle.
This document discusses various process models for software engineering. It begins by defining what a process model is and explaining why they are useful. It then covers traditional sequential models like waterfall and V-model. Iterative and incremental models like prototyping and spiral modeling are described which allow for software to evolve through iterations. Other topics covered include concurrent modeling, component-based development, formal methods, aspects, unified process and personal software process. The document provides details on different process patterns, assessment methods and considerations for evolutionary processes.
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.
This document discusses metrics that can be used to measure software processes and projects. It begins by defining software metrics and explaining that they provide quantitative measures that offer insight for improving processes and projects. It then distinguishes between metrics for the software process domain and project domain. Process metrics are collected across multiple projects for strategic decisions, while project metrics enable tactical project management. The document outlines various metric types, including size-based metrics using lines of code or function points, quality metrics, and metrics for defect removal efficiency. It emphasizes integrating metrics into the software process through establishing a baseline, collecting data, and providing feedback to facilitate continuous process improvement.
The document discusses requirements modeling and analysis modeling in software engineering. It provides information on:
1) The different types of models that can be created during requirements modeling, including requirements models, design models, scenario-based models, data models, class-based models, flow-oriented models, and behavioral models.
2) The purposes of requirements modeling, which include representing customer requirements, gaining a better understanding of the system, and providing information to help with system design and development.
3) Key principles of requirements modeling, such as representing the information, functional, and behavioral domains of the system and partitioning models in a layered/hierarchical way.
4) Specific modeling techniques like scenario-based modeling, data
This ppt covers the following
A strategic approach to testing
Test strategies for conventional software
Test strategies for object-oriented software
Validation testing
System testing
The art of debugging
Evolutionary models are iterative and incremental software development approaches that combine iterative and incremental processes. There are two main types: prototyping and spiral models. The prototyping model develops prototypes that are tested and refined based on customer feedback until requirements are met, while the spiral model proceeds through multiple loops or phases of planning, risk analysis, engineering, and evaluation. Both approaches allow requirements to evolve through development and support risk handling.
This document discusses several software cost estimation techniques:
1. Top-down and bottom-up approaches - Top-down estimates system-level costs while bottom-up estimates costs of each module and combines them.
2. Expert judgment - Widely used technique where experts estimate costs based on past similar projects. It utilizes experience but can be biased.
3. Delphi estimation - Estimators anonymously provide estimates in rounds to reach consensus without group dynamics influencing individuals.
4. Work breakdown structure - Hierarchical breakdown of either the product components or work activities to aid bottom-up estimation.
Software Engineering Important Short Question for ExamsMuhammadTalha436
The document discusses various topics related to software engineering including:
1. The software development life cycle (SDLC) and its phases like requirements, design, implementation, testing, etc.
2. The waterfall model and its phases from modeling to maintenance.
3. The purpose of feasibility studies, data flow diagrams, and entity relationship diagrams.
4. Different types of testing done during the testing phase like unit, integration, system, black box and white box testing.
Formal Specification in Software Engineering SE9koolkampus
This document discusses formal specification techniques for software. It describes algebraic techniques for specifying interfaces as abstract data types and model-based techniques for specifying system behavior. Algebraic specifications define operations and their relationships, while model-based specifications represent the system state using mathematical constructs like sets and sequences. Formal specification finds errors earlier and reduces rework, though it requires more upfront effort. The document also provides an example of formally specifying an air traffic control system and insulin pump.
User Interface Design in Software Engineering SE15koolkampus
The document discusses principles of user interface design including interaction styles, information presentation, user support, and evaluation. It covers topics such as direct manipulation, menu selection, command languages, using color and graphics effectively, designing helpful error messages and documentation, and evaluating interfaces against usability specifications. The goal is to provide user-centered interfaces that are logical, consistent, and help users recover from errors.
Flow-oriented modeling represents how data objects are transformed as they move through a system. A data flow diagram (DFD) is the diagrammatic form used to depict this approach. DFDs show the flow of data through processes and external entities of a system using symbols like circles and arrows. They provide a unique view of how a system works by modeling the input, output, storage and processing of data from level to level.
The document discusses formal approaches to software quality assurance (SQA). It states that SQA can be improved through software engineering practices like technical reviews, multi-tiered testing, controlling work products and changes, and following standards. It also argues that a more rigorous mathematical approach is needed for SQA since programs can be viewed as mathematical objects with rigorous syntax and semantics defined for languages, allowing proofs of correctness.
This document discusses understanding requirements in software engineering. It outlines the key tasks in requirements engineering as inception, elicitation, elaboration, negotiation, specification, validation and management. Elicitation involves drawing requirements from stakeholders but can be difficult due to problems with scope, volatility, understanding and communication. Elaboration develops a refined technical model using information from inception and elicitation. Negotiation aims to agree on a realistic deliverable through prioritization and negotiation. Specification can take various forms depending on the system. Validation reviews the specification for errors and omissions. Requirements management handles changing requirements throughout the project.
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 and requirement elicitation processes. It describes the key steps in requirement engineering as inception, elicitation, elaboration, negotiation, specification, validation and management. It then explains elicitation techniques such as collaborative gathering, Quality Function Deployment to prioritize needs, and usage scenarios to understand how features will be used. Interviews with stakeholders and brainstorming sessions are also discussed as ways to elicit requirements.
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.
The document discusses core principles of software engineering and requirements engineering. It outlines seven principles proposed by David Hooker for software engineering which focus on adding value to users, keeping designs simple, maintaining vision, considering future maintainers and users, planning for reuse, and applying thorough thought. It then describes the key tasks in requirements engineering as inception, elicitation, elaboration, negotiation, specification, validation and management. Data modeling is also discussed including defining data objects, attributes, relationships, modality and cardinality.
Software Development Process - REQUIREMENTS ANALYSIS / ANALYSIS OF TECHNICAL...Mark John Lado, MIT
The document discusses requirements analysis, which is the first stage of the software development process. It involves eliciting requirements from stakeholders, analyzing the requirements for clarity and consistency, and documenting them. Common techniques for requirements analysis include stakeholder interviews, prototypes, use cases, and software requirements specifications. The goals are to determine what functionality and constraints the system needs to meet business needs.
Requirements engineering involves multiple tasks to ensure software engineers understand customer needs. It begins with inception to establish basic understanding, then elicitation gathers requirements from stakeholders. During elaboration, requirements are analyzed and modeled. Negotiation reconciles customer wants with feasibility. Requirements are then specified and validated before being managed throughout the project. The goals are to avoid building the wrong solution and establish a solid foundation for design.
The document discusses requirements gathering and analysis. It describes how requirements elicitation is difficult due to problems of scope, understanding, and volatility. It emphasizes the importance of requirement gathering and states that requirement analysis may be error-prone. Various techniques for requirements elicitation and analysis are discussed, including interviews, prototypes, quality function deployment, and system modeling. The goals of requirements specification and characteristics of a good SRS are also outlined.
The document provides an overview of system planning and requirements analysis. It discusses identifying a system development project through top-down or bottom-up planning. It also covers planning the system development project, which involves preliminary investigation and fact-finding techniques like interviews. Requirements analysis is then explained as determining user needs through communication with stakeholders. The requirements analysis process, modeling, and an example are described. System planning and requirements analysis are important initial phases in the system development life cycle.
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.
The document discusses the key tasks in requirements engineering: inception to initially understand user needs, elicitation to gather requirements, elaboration to further analyze and model requirements, negotiation to reconcile conflicts, specification to formally document requirements, validation to verify requirements quality, and management to track requirements throughout the project. The tasks involve collaborative activities like interviews and workshops to capture ambiguous and changing user needs and transform them into clear, consistent requirements that form the basis for subsequent software design and development.
Week8 Topic1 Translate Business Needs Into Technical Requirementshapy
The document discusses translating business needs into technical requirements. It explains that technical requirements specify how business needs will be met technically and should be measurable. It provides examples of how to identify stakeholders, clarify the business problem, determine technical requirements, and secure sign-off for the requirements and solutions.
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 the Software Development Life Cycle (SDLC), which is a process used to develop software in a logical, structured manner. It consists of six phases - system planning, system analysis, system design, system coding, system testing, and deployment and maintenance. The goal of the SDLC is to produce high-quality software that meets customer expectations with the highest quality, lowest cost, and shortest time. Each phase results in deliverables for the next phase and aims to gradually develop the system from inception of an idea through implementation and delivery.
The systematic use of proven principles, techniques ,languages and tools for the cost-effective analysis ,documentation and on-going evolution of user needs and the external behavior of a system to satisfy those user needs.
Requirement Elicitation
Facilitated Application Specification Technique(FAST)
Quality Function Deployment
USE-CASES
Perspective-based reading (PBR) focuses on reviewing requirements documents from different stakeholder perspectives. PBR identifies key perspectives like tester, developer, and user. Reviewers follow procedures tailored to each perspective to systematically identify defects. PBR benefits include being systematic, focused, goal-oriented, and the procedures can be transferred through training. Requirements engineering involves social and cultural issues as it requires interaction between clients, engineers, and other stakeholders who may have different backgrounds. Key social issues include managing relationships and communication between different teams and organizations involved in requirements development.
Here are two potential factors that could have influenced business decisions for the project:
1. Policy changes - A new privacy policy was introduced that placed stricter requirements around data security and access. This may have impacted technical architecture decisions and increased security requirements.
2. Legislative changes - New legislation was passed requiring additional reporting and auditing of financial transactions. This could have prompted the need for an upgraded accounting system with stronger audit trails and reporting capabilities.
The document provides an overview of business intelligence (BI) and business analytics (BA). It defines BI as a variety of software applications used to analyze organizational data to make strategic, tactical, and operational decisions. BA is described as using data, analytics, and business models to gain insights and make better decisions. The key components of BI are data warehousing, business analytics, business performance management, and user interfaces. Descriptive, predictive, and prescriptive analytics are also discussed as types of analyses used in BA.
The document provides an overview of the Python programming language. It discusses that Python is an interpreted, object-oriented, high-level programming language created by Guido van Rossum in 1989. It also lists many common uses of Python, such as for web development, data analysis, and game development. Additionally, it introduces several integrated development environments (IDEs) for Python programming including IDLE, Visual Studio Code, Notepad, and PyCharm.
The document provides an introduction to software engineering and process models. It defines key terms like software, software engineering, and characteristics of software. It then discusses software engineering as a layered technology with process, method, and tools layers. The document also explains the software process as consisting of five generic activities - communication, planning, modeling, construction, and deployment. It provides examples and definitions for each activity. Finally, it asks exam questions related to defining software engineering and explaining it as a layered technology.
This document discusses Boolean algebra and digital logic gates. It introduces Boolean algebra, which uses logical variables and operations like AND, OR, and NOT. These operations are represented with symbols and defined through truth tables. Different types of logic gates are also introduced, including AND, OR, NAND, NOR and XOR gates. The gates are the basic building blocks of digital circuits and are used to implement Boolean logic functions. Functionally complete sets of gates are identified that allow any Boolean function to be implemented.
Business analytics (BA) refers to the methods and techniques used to measure business performance. BA uses statistical analysis to transform raw data into meaningful insights. There are six major components of a BA solution: data mining, forecasting, predictive analytics, optimization, text mining, and visualization.
BA can be categorized into descriptive, predictive, and prescriptive analytics. Descriptive analytics answers "what happened" by analyzing past data. Predictive analytics predicts future outcomes and answers "what could happen." Prescriptive analytics determines optimal courses of action and answers "what should we do?" Together, these three categories of BA provide businesses with insights from data to improve decision-making.
The document provides an overview of business intelligence (BI), including definitions, objectives, components, history, needs/benefits, features, uses, and examples. Some key points:
- BI is an umbrella term for architectures, tools, databases, and methods to improve business decision-making through analysis of facts and data-driven systems.
- The goal of BI is to transform raw data into meaningful and useful information through analytics that provides insights and knowledge for impactful decisions.
- Major BI components include data warehousing, extraction/transformation/loading tools, data marts, metrics/key performance indicators, dashboards, and online analytical processing reporting.
- BI has evolved from static reporting systems in
Michael Phelps is an American swimmer who is considered the most successful and decorated Olympian of all time, having won 28 medals over five Olympic Games. He holds the record for most Olympic gold medals with 23 golds. Phelps is often compared to American swimmer Mark Spitz, who held the previous record of winning the most gold medals in a single Olympics with 7 golds in 1972.
The document discusses software engineering and process models. It defines software engineering as the application of systematic and quantifiable approaches to software development, operation and maintenance. It describes software as computer programs, data structures and documentation.
It then discusses characteristics of software such as it being engineered not manufactured, not wearing out over time, and continuing to be custom built in most cases. It also discusses the software engineering layers including the process, method and tools layers.
Finally, it discusses the software process as a framework involving key activities like communication, planning, modeling, construction and deployment. It explains the generic process model and how activities are populated by actions and tasks to produce work products.
1. Software project estimation involves decomposing a project into smaller problems like major functions and activities. Estimates can be based on similar past projects, decomposition techniques, or empirical models.
2. Accurate estimates depend on properly estimating the size of the software product using techniques like lines of code, function points, or standard components. Baseline metrics from past projects are then applied to the size estimates.
3. Decomposition techniques involve estimating the effort needed for each task or function and combining them. Process-based estimation decomposes the software process into tasks while problem-based estimation decomposes the problem.
This document outlines the key steps in the data preparation process:
1. Check questionnaires for completeness and logical responses
2. Edit data to ensure consistency, correct errors, and fill in missing values
3. Code data by assigning numerical values to question responses
4. Clean data by identifying outliers and inconsistencies to improve data quality
The document discusses various concepts related to measurement, scaling, instrument design, and sampling. It defines measurement as assigning numbers to objects or observations according to specific rules. There are four main types of measurement scales discussed - nominal, ordinal, interval, and ratio scales - which differ in the types of mathematical operations and statistical analyses that can be conducted. Good measurement is reliable, valid, and practical. Reliability refers to consistency over time, validity is the ability to measure what is intended, and practicality considers cost, convenience and interpretability.
The document discusses research design and provides details on different types of research designs. It begins by defining research design and outlines the key decisions that must be made, including what, where, when, how much, and how data will be collected and analyzed. It then discusses different types of research designs for exploratory, descriptive, diagnostic, and hypothesis-testing studies. Specific methods for qualitative and quantitative research designs are also outlined.
This document provides an overview of queuing theory and the key components of a queuing system. It discusses the calling population or customers arriving for service, including characteristics like size, behavior, and arrival patterns. The queuing process and queue discipline are also examined. Finally, the document outlines various performance measures used to evaluate queuing systems, such as average wait time, number of customers, probability of waiting, and operating costs.
CapTechTalks Webinar Slides June 2024 Donovan Wright.pptxCapitolTechU
Slides from a Capitol Technology University webinar held June 20, 2024. The webinar featured Dr. Donovan Wright, presenting on the Department of Defense Digital Transformation.
Information and Communication Technology in EducationMJDuyan
(𝐓𝐋𝐄 𝟏𝟎𝟎) (𝐋𝐞𝐬𝐬𝐨𝐧 2)-𝐏𝐫𝐞𝐥𝐢𝐦𝐬
𝐄𝐱𝐩𝐥𝐚𝐢𝐧 𝐭𝐡𝐞 𝐈𝐂𝐓 𝐢𝐧 𝐞𝐝𝐮𝐜𝐚𝐭𝐢𝐨𝐧:
Students will be able to explain the role and impact of Information and Communication Technology (ICT) in education. They will understand how ICT tools, such as computers, the internet, and educational software, enhance learning and teaching processes. By exploring various ICT applications, students will recognize how these technologies facilitate access to information, improve communication, support collaboration, and enable personalized learning experiences.
𝐃𝐢𝐬𝐜𝐮𝐬𝐬 𝐭𝐡𝐞 𝐫𝐞𝐥𝐢𝐚𝐛𝐥𝐞 𝐬𝐨𝐮𝐫𝐜𝐞𝐬 𝐨𝐧 𝐭𝐡𝐞 𝐢𝐧𝐭𝐞𝐫𝐧𝐞𝐭:
-Students will be able to discuss what constitutes reliable sources on the internet. They will learn to identify key characteristics of trustworthy information, such as credibility, accuracy, and authority. By examining different types of online sources, students will develop skills to evaluate the reliability of websites and content, ensuring they can distinguish between reputable information and misinformation.
(𝐓𝐋𝐄 𝟏𝟎𝟎) (𝐋𝐞𝐬𝐬𝐨𝐧 3)-𝐏𝐫𝐞𝐥𝐢𝐦𝐬
Lesson Outcomes:
- students will be able to identify and name various types of ornamental plants commonly used in landscaping and decoration, classifying them based on their characteristics such as foliage, flowering, and growth habits. They will understand the ecological, aesthetic, and economic benefits of ornamental plants, including their roles in improving air quality, providing habitats for wildlife, and enhancing the visual appeal of environments. Additionally, students will demonstrate knowledge of the basic requirements for growing ornamental plants, ensuring they can effectively cultivate and maintain these plants in various settings.
2. 2
Contents
Principles of Software Engineering and Requirements Modeling
• Requirements Engineering
• Groundwork for Understanding of Software Requirements
• Overview of Eliciting Requirements
• Developing Use Cases, Building the Requirements Model;
• Negotiating Requirements;
• Validating Requirements;
3. 3
Requirements Engineering
Introduction:
The broad spectrum (range, variety) of tasks and techniques that
lead to an understanding of requirements is called requirements engineering.
•In other words , Requirements engineering (RE) refers to the process of
defining, documenting and maintaining requirements
From a requirements engineering is a major software engineering action that
begins during the communication activity and continues into the modeling
activity. It must be adapted to the needs of the process, the project, the
product, and the people doing the work.
Requirements engineering builds a bridge to design and construction.
4. 4
“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 seven distinct tasks: (IEENSVM)
Inception (beginning)
Elicitation (bring out)
Elaboration (expansion , explanation)
Negotiation
Specification
Validation
Management
Elicitation (Practice of collecting the
requirements of a system from users,
customers and other stakeholders)
5. 5
1. Inception ( Beginning , Start)
At project inception, ask a set of question that establish a basic
understanding of the problem:
-the people who want a solution,
-the nature of the solution that is desired, and
-the effectiveness of preliminary communication and collaboration
between the other stakeholders and the software team.
2. Elicitation (bring out) requirements from all stakeholders.
Ask the customer, the users, and others what the objectives for the system
or product are, what is to be accomplished, how the system or product fits
into the needs of the business, and finally, how the system or product is to
be used on a day-to-day basis.
6. 6
2. Elicitation cont..
Number of problems are encountered as elicitation occurs.
Problems of scope :
The boundary of the system is ill-defined or the customers/users specify
unnecessary technical detail that may confuse, rather than clarify.
Problems of understanding :
The customers/users are not completely sure of what is needed, have a poor
understanding of the limitations, don’t have a full understanding of the
problem domain, omit information ,specify requirements that conflict with
the needs of other customers/users, or specify requirements that are
ambiguous.
Problems of volatility (unpredictability):
The requirements change over time. To help overcome these problems, you
must approach requirements gathering in an organized manner.
7. 7
3. Elaboration (expansion, explanation) :
create an analysis model that identifies data, function and behavioral
requirements.
Elaboration is driven by the creation and refinement of user scenarios
that describe how the end user (and other actors) will interact with
the system.
4. Negotiation - agree on a deliverable system that is realistic (Reasonable)
for developers and customers.
- Customers, users, and other stakeholders are asked to category
requirements and then discuss conflicts in priority.
- Using an iterative approach that prioritizes requirements, assesses their
cost and risk, and addresses internal conflicts, requirements are eliminated,
combined, and/or modified so that each party achieves some measure of
satisfaction
8. 8
5. Specification — Specification means different things to different
people. It can be any one(or more)of the following:
> A written document
> A set of models
> A formal mathematical
> A collection of user scenarios (use-cases)
> A prototype
9. 9
6. Validation :- a review mechanism that looks for errors in content or
interpretation areas where clarification may be required.
-missing information
-inconsistencies (a major problem when large products or systems
are engineered)
-conflicting or unrealistic (unachievable) requirements.
•Requirements validation examines the specification to ensure that all
software requirements have been stated unambiguously; that
inconsistencies, omissions, and errors have been detected and corrected;
7. Requirement Management
> Requirements for computer-based systems change, and the desire to
change requirements persists throughout the life of the system.
>Requirements management is a set of activities that help the project team
identify, control, and track requirements and changes to requirements at
any time as the project proceeds.
10. 10
Inception: The steps required to establish the groundwork(basic
work) for An understanding of software requirements…
Groundwork For Understanding of Software Requirements
Requirements engineering is simply a matter of conducting meaningful
conversations with colleagues who are well-known members of the team.
But reality is often quite different.
Customer(s) or end users may be located in a different city or country,
may have only a vague(unclear) idea of what is required, may have
conflicting opinions about the system to be built, may have limited
technical knowledge, and may have limited time to interact with the
requirements engineer
11. 11
Groundwork For Understanding of Software Requirements
Here are the steps required to establish the groundwork for an understanding
of software requirements—to get the project started in away that will keep it
moving forward toward a successful solution.
1. Identifying Stakeholders
2. Recognizing Multiple Viewpoints
3. Working toward Collaboration
4. Asking the First Questions
12. 12
1.Identifying Stakeholders
Sommer ville and Sawyer [Som97] define a stakeholder as “anyone who
benefits in a direct or indirect way from the system which is being
developed.”
Ex : 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, and is open to different risks if the development effort should
fail.
Groundwork For Understanding of Software Requirements
13. 13
2. Recognizing Multiple Viewpoints
Because many different stakeholders exist, the requirements of the system
will be explored from many different points of view.
Each of these constituencies (voters) will contribute information to the
requirements engineering process. As information from multiple
viewpoints is collected, emerging requirements may be inconsistent or
may conflict with one another.
You should categorize all stakeholder information (including inconsistent
and conflicting requirements) in a way that will allow decision makers to
choose an internally consistent set of requirements for the system. 14
Groundwork For Understanding of Software Requirements
14. 14
3. Working toward Collaboration
If five stakeholders are involved in a software project, you may have
----five (or more) different opinions about
- The proper set of requirements, after that
- Customers (and other stakeholders) must collaborate
among themselves and with software engineering
practitioners if a successful system is to result.
The job of a requirements engineer is to identify areas of
commonality and areas of conflict or inconsistency.
Groundwork For Understanding of Software Requirements
15. 15
4. Asking the First Questions
first set of context-free questions focuses on the customer and other
stakeholders, the overall project goals and benefits. For example,
you might ask:
• Who is behind the request for this work?
• Who will use the solution?
• What will be the economic benefit of a successful solution?
• Is there another source for the solution that you need?
These questions help to identify all stakeholders who will have interest
in the software to be built.
Groundwork For Understanding of Software Requirements
16. 16
Asking the First Questions cont..
In addition, the questions identify the measurable benefit of a successful
implementation and possible alternatives to custom software development.
The next set of questions enables you to gain a better understanding of the problem
and allows the customer to voice his or her perceptions about a solution:
• How would you characterize “good” output that would be generated by a successful
solution?
• What problem(s) will this solution address?
• Can you show me (or describe) the business environment in which the solution will
be used?
• Will special performance issues or constraints affect the way the solution is
approached?
Groundwork For Understanding of Software Requirements
17. 17
Asking the First Questions cont..
The final set of questions focuses on the effectiveness of the
communication activity itself. Gause and Weinberg [Gau89] call these
“meta-questions” and propose the following (abbreviated) list:
• Are you the right person to answer these questions? Are your answers
“official”?
• Are my questions relevant to the problem that you have?
• Am I asking too many questions?
• Can anyone else provide additional information?
• Should I be asking you anything else?
These questions (and others) will help to “break the ice” and initiate the
communication that is essential to successful elicitation
Groundwork For Understanding of Software Requirements
18. 18
Eliciting Requirements
In order to encourage a collaborative, team-oriented approach to
requirements gathering, stakeholders work together to identify the
problem, propose elements of the solution, negotiate different
approaches and specify a preliminary set of solution requirements
Collaborative Requirements Gathering
Quality Function Deployment
Usage Scenarios
Elicitation Work Products
19. 19
1.Collaborative Requirements Gathering
Many different approaches to collaborative requirements gathering have
been proposed. Each makes use of a slightly different scenario, but all
apply some variation on the following basic guidelines:
• Meetings are conducted and attended by both software engineers and
other stakeholders.
• Rules for preparation and participation are established.
• An agenda is suggested that is formal enough to cover all important
points but informal enough to encourage the free flow of ideas.
• A “facilitator” (can be a customer, a developer, or an outsider) controls
the meeting.
• A “definition mechanism” (can be work sheets, flip charts, or wall
stickers or an electronic bulletin board, chat room, or virtual forum) is
used.
20. 20
Collaborative Requirements Gathering cont..
During inception basic questions and answers establish the scope
of the problem and the overall perception of a solution. Out of these
initial meetings, the developer and customers write a one- or two-
page “product request.”
A meeting place, time, and date are selected; a facilitator is
chosen; and attendees from the software team and other
stakeholder organizations are invited to participate. The product
request is distributed to all attendees before the meeting date.
21. 21
Collaborative Requirements Gathering cont..
In reality, others would contribute to this narrative during the
requirements gathering meeting and considerably more information would
be available. But even with additional information, ambiguity would be
present, omissions would likely exist, and errors might occur. For now, the
preceding “functional description” will suffice.
Each attendee is asked to make another list of services (processes or
functions) that manipulate or interact with the objects. Finally, lists of
constraints (e.g., cost, size, business rules) and performance criteria (e.g.,
speed, accuracy) are also developed.
22. 22
Collaborative Requirements Gathering cont..
The lists of objects can be pinned to the walls of the room using large sheets
of paper, stuck to the walls using adhesive-backed sheets, or written on a
wall board.
After individual lists are presented in one topic area, the group creates a
combined list by eliminating redundant entries, adding any new ideas that
come up during the discussion, but not deleting anything. After you create
combined lists for all topic areas, discussion—coordinated by the facilitator
—ensues.
In many cases, an object or service described on a list will require further
explanation. To accomplish this, stakeholders develop mini-specifications for
entries on the lists
23. 23
2. Quality Function Deployment
Quality function deployment (QFD) is a quality management technique that
translates the needs of the customer into technical requirements for
software.
QFD “concentrates on maximizing customer satisfaction from the software
engineering process”.
QFD identifies three types of requirements
1. Normal requirements
2. Expected requirements
3. Exciting requirements
24. 24
Quality Function Deployment cont..
1.Normal requirements :
The objectives and goals that are stated for a product or system during
meetings with the customer.
If these requirements are present, the customer is satisfied.
Examples of normal requirements might be requested types of graphical
displays, specific system functions, and defined levels of performance.
2. Expected requirements :
These requirements are understood to the product or system and may be
so fundamental that the customer does not openly state them.
Their absence will be a cause for significant dissatisfaction.
Examples of expected requirements are: ease of human/machine
interaction, overall operational correctness and reliability, and ease of
software installation.
25. 25
Quality Function Deployment cont..
3. Exciting requirements :
- These features go beyond the customer’s expectations and prove to be very
satisfying when present.
- For example, software for a new mobile phone comes with standard features, but
is coupled with a set of unexpected capabilities (e.g., multi touch screen, visual
voice mail) that delight every user of the product.
26. 26
3. Usage Scenarios
As requirements are gathered, an overall vision of system functions and
features begins to materialize.
However, it is difficult to move into more technical software engineering
activities until you understand how these functions and features will be used
by different classes of end users.
To accomplish this, developers and users can create a set of scenarios that
identify a thread of usage for the system to be constructed. The scenarios,
often called use cases, provide a description of how the system will be used.
27. 27
4. Elicitation Work Products
The work products produced as a consequence of requirements elicitation
will vary depending on the size of the system or product to be built. For
most systems, the work products include :
• A statement of need and feasibility.
• A bounded statement of scope for the system or product.
• A list of customers, users, and other stakeholders who
participated in requirements elicitation.
• A description of the system’s technical environment.
• A list of requirements (preferably organized by function)
• A set of usage scenarios
Each of these work products is reviewed by all people who have
participated in requirements elicitation.
28. 28
Developing Use Cases
“ A use case captures a contract ... [that] describes the system’s behavior
under various conditions as the system responds to a request from one of its
stakeholders . . .”
In essence, a use case tells a stylized story about how an end user (playing
one of a number of possible roles) interacts with the system under a specific
set of circumstances. The story may be narrative text, an outline of tasks or
interactions, a template-based description, or a diagrammatic
representation.
Regardless of its form, a use case depicts the software or system from the
end user’s point of view.
29. 29
The first step in writing a use case is to define the set of “actors” that will be
involved in the story.
Actors are the different people (or devices) that use the system or product
within the context of the function and behavior that is to be described.
Actors represent the roles that people (or devices) play as the system
operates.
Defined somewhat more formally, an actor is anything that communicates
with the system or product and that is external to the system itself. Every
actor has one or more goals when using the system. 30
30. 30
Note that an actor and an end user are not necessarily the same thing. A
typical user may play a number of different roles when using a system,
whereas an actor represents a class of external entities that play just one
role in the context of the use case.
As an example, consider a machine operator (a user) who interacts with the
control computer for a manufacturing cell that contains a number of robots
and numerically controlled machines.
After careful review of requirements, the software for the control computer
requires four different modes (roles) for interaction: programming mode,
test mode, monitoring mode, and troubleshooting mode.
Therefore, four actors can be defined: programmer, tester, monitor, and
trouble shooter. In some cases, the machine operator can play all of these
roles.
31. 31
EACH SCANARIO (USE CASE) should be answered THE FOLLOWING
QUESTIONS:
• Who is the primary actor, the secondary actor(s)?
• What are the actor’s goals?
• What preconditions should exist before the story begins?
• What main tasks or functions are performed by the actor?
• What exceptions might be considered as the story is described?
• What variations in the actor’s interaction are possible?
• What system information will the actor obtain, produce, or change?
• Will the actor have to inform the system about changes in the external
environment?
• What information does the actor desire from the system?
• Does the actor wish to be informed about unexpected changes?
32. 32
Example :
we define four actors: homeowner (a user), setup manager (likely the
same person as homeowner, but playing a different role), sensors
(devices attached to the system), and the monitoring and response
subsystem (the central station that monitors the SafeHome home
security function).
33. 33
The homeowner actor interacts with the home security function in a
number of different ways using either the alarm control panel or a PC:
• Enters a password to allow all other interactions.
• Inquires about the status of a security zone.
• Inquires about the status of a sensor.
• Presses the panic button in an emergency.
• Activates/deactivates the security system.
34. 34
1.The homeowner observes the SafeHome control panel (Figure) to
determine if the system is ready for input. If the system is not ready, a not
ready message is displayed on the LCD display, and the homeowner must
physically close windows or doors so that the not ready message disappears
2. The homeowner uses the keypad to key in a four-digit password. The
password is compared with the valid password stored in the system. If the
password is incorrect, the control panel will beep once and reset itself for
additional input. If the password is correct, the control panel awaits further
action.
3. The homeowner selects and keys in stay or away (see Figure 5.1) to
activate the system. Stay activates only perimeter sensors (inside motion
detecting sensors are deactivated).Away activates all sensors.
4. When activation occurs, a red alarm light can be observed by the
homeowner.
35. 35
The basic use case presents a high-level story that describes the interaction
between the actor and the system.
The following template for detailed descriptions of use cases:
Use case: InitiateMonitoring
Primary actor: Homeowner
Goal in context : To set the system to monitor sensors when the
home owner leaves the house or remains inside.
Preconditions: System has been programmed for a password and to
recognize various sensors.
Trigger: The homeowner decides to “set” the system, i.e., to turn on
the alarm functions.
Scenario: 1. Homeowner: observes control panel
2. Homeowner: enters password
3. Homeowner: selects “stay” or “away”
4. Homeowner: observes read alarm light to indicate that
SafeHome has been armed
36. 36
Exceptions: 1. Control panel is not ready: homeowner checks all sensors
to determine which are open; closes them.
2. Password is incorrect (control panel beeps once):
homeowner re enters correct password.
3. Password not recognized: monitoring and response
subsystem must be contacted to reprogram password.
4. Stay is selected: control panel beeps twice and a stay light
is lit; perimeter sensors are activated.
5. Away is selected: control panel beeps three times and an
away light is lit; all sensors are activated.
Priority: Essential, must be implemented
When available: First increment
Frequency of use: Many times per day
Channel to actor: Via control panel interface
Secondary actors: Support technician, sensors
Channels to secondary actors: Support technician: phone line
Sensors: hardwired and radio frequency interfaces
37. 37
Open issues:
1.Should there be a way to activate the system without the use of a
password or with an abbreviated password?
2. Should the control panel display additional text messages?
3. How much time does the homeowner have to enter the password from
the time the first key is pressed?
4. Is there a way to deactivate the system before it actually activates?
39. 39
Building the Requirements Model
Introduction:
The intent of the analysis model is to provide a description of the required
informational, functional, and behavioral domains for a computer-based
system.
Elements of the Requirements Model :
•There are many different ways to look at the requirements for a computer-
based system. Some software people argue that it’s best to select one
mode of representation (e.g. the use case)
A set of generic elements is common to most requirements models.
1. Scenario-based elements.
2. Class-based elements
3. Behavioral elements
4. Flow-oriented elements
40. 40
Building the Requirements Model
1. Elements of the Requirements Model :
1. Scenario-based elements.
2. Class-based elements
3. Behavioral elements
4. Flow-oriented elements
2. Analysis Pattern
41. 41
# Elements of the Requirements Model cont..
1.Scenario-based elements.
The system is described from the user’s point of view using a scenario-based
approach.
Scenario-based elements of the requirements model are often the first part of the
model that is developed. As such, they serve as input for the creation of other
modeling elements.
Figure depicts a UML activity diagram for eliciting requirements and representing
them using use cases. Three levels of elaboration are shown, culminating in a
scenario-based representation.
43. 43
2. Class-based elements.
• Each usage scenario implies a set of
objects that are manipulated as an
actor interacts with the system. These
objects are categorized into classes—
a collection of things that have
similar attributes and common
behaviors. For example, a UML class
diagram canbe used to depict a
Sensor class for the SafeHome
security function (Figure). Note that
the diagram lists the attributes of
sensors (e.g., name, type) and the
operations (e.g., identify, enable)
that can be applied to modify these
attributes
Class diagram for
sensor
44. 44
3. Behavioral elements.
The behavior of a computer-based system can have a profound effect on
the design that is chosen and the implementation approach that is applied.
Therefore, the requirements model must provide modeling elements that
depict behavior.
The state diagram is one method for representing the behavior of a system
by depicting its states and the events that cause the system to change state.
A state is any externally observable mode of behavior. In addition, the state
diagram indicates actions (e.g., process activation) taken as a consequence
of a particular event.
In addition to behavioral representations of the system as a whole, the
behavior of individual classes can also be modeled.
46. 46
4. Flow – Oriented elements :
Information is transformed as it flows through a computer-based system.
The system accepts input in a variety of forms, applies functions to
transform it, and produces output in a variety of forms.
Input may be a control signal transmitted by a transducer, a series of
numbers typed by a human operator, a packet of information transmitted
on a network link, or a voluminous data file retrieved from secondary
storage.
47. 47
# Analysis Patterns
Anyone who has done requirements engineering on more than a few
software projects begins to notice that certain problems reoccur across all
projects within a specific application domain.
These analysis patterns suggest solutions (e.g., a class, a function, a behavior)
within the application domain that can be reused when modeling many
applications.
Two benefits that can be associated with the use of analysis patterns:
48. 48
First, analysis patterns speed up the development of abstract analysis models
that capture the main requirements by providing reusable analysis models with
examples as well as a description of advantages and limitations.
Second, analysis patterns facilitate the transformation of the analysis model into
a design model by suggesting design patterns and reliable solutions for common
problems.
49. 49
Negotiating Requirements
In reality, you may have to enter into a negotiation with one or more
stakeholders. In most cases, stakeholders are asked to balance
functionality, performance, and other product or system characteristics
against cost and time-to-market.
The intent of this negotiation is to develop a project plan that meets
stakeholder needs while at the same time reflecting the real-world
constraints (e.g., time, people, budget) that have been placed on the
software team.
The best negotiations strive for a “win-win” result. That is, stakeholders
win by getting the system or product that satisfies the majority of their
needs and you (as a member of the software team) win by working to
realistic and achievable budgets and deadlines.
50. 50
A set of negotiation activities at the beginning of each software process
iteration. Rather than a single customer communication activity, the
following activities are defined:
1. Identification of the system or subsystem’s key stakeholders.
2. Determination of the stakeholders’ “win conditions.”
3. Negotiation of the stakeholders’ win conditions to reconcile them into
a set of win-win conditions for all concerned (including the software
team).
Successful completion of these initial steps achieves a win-win result,
which becomes the key criterion for proceeding to subsequent software
engineering activities.
51. 51
Validating Requirements
Introduction: As each element of the requirements model is created, it is
examined for inconsistency, omissions, and ambiguity. The requirements
represented by the model are prioritized by the stakeholders and grouped
within requirements packages that will be implemented as software
increments.
A review of the requirements model addresses the following questions:
• Is each requirement consistent with the overall objectives for the
system/product?
• Have all requirements been specified at the proper level of abstraction?
• Is the requirement really necessary or does it represent an add-on
feature that may not be essential to the objective of the system?
52. 52
• Is each requirement bounded and unambiguous?
• Does each requirement have attribution? That is, is a source (generally,
a specific individual) noted for each requirement?
• Do any requirements conflict with other requirements?
• Is each requirement achievable in the technical environment that will
house the system or product?
• Is each requirement testable, once implemented?
• Does the requirements model properly reflect the information,
function, and behavior of the system to be built?
53. 53
• Has the requirements model been “partitioned” in a way that exposes
progressively more detailed information about the system?
• Have requirements patterns been used to simplify the requirements
model? Have all patterns been properly validated? Are all patterns
consistent with customer requirements?
These and other questions should be asked and answered to ensure that
the requirements model is an accurate reflection of stakeholder needs
and that it provides a solid foundation for design.
54. 54
What is requirement engineering ? Describe the seven distinct tasks
encompassed in requirement engineering. Also, explain Quality Function
Deployment. [07]
What is requirement engineering? Describe the seven distinct tasks
encompassed in requirement engineering.[07]
Explain seven Requirement Engineering tasks in detail. [07]
What do you mean by Eliciting requirements? What is its role in building
analysis model? How quality of requirements can be helpful in model
building ?
Describe the seven distinct tasks encompassed in requirement engineering.
[07]
Explain the requirement engineering task in detail. [07]
GTU Final Exam Questions :
56. 56
Requirement Modeling Strategies
Flow-Oriented Modeling
Behavioral Modeling
Topics to be covered
57. 57
Requirements Modeling Strategies
One view of requirements modeling, called structured analysis,
considers data and the processes that transform the data as separate
entities.
>Data objects are modeled in a way that defines their attributes
and relationships.
> Processes that manipulate data objects are modeled in a
manner that shows how they transform data as data objects flow
through the system.
A second approach to analysis modeled, called object-oriented analysis,
focuses on the definition of classes and the manner in which they
collaborate with one another to effect customer requirements.
58. 58
Flow oriented Modeling
It represents how data objects are transformed at they move through the
system.
Data Flow Diagram (DFD) is the diagrammatic form that is used .
The DFD takes an input-process-output view of a system.
That is, data objects flow into the software, are transformed by
processing elements, and resultant data objects flow out of the software.
Data objects are represented by labeled arrows and transformations are
represented by circles (bubbles).
The DFD is presented in hierarchical fashion. That is the first data flow
model (zero level DFD or context diagram) represents the system as a whole.
Subsequent data flow diagrams refine the context diagram, providing
increasing detail with each subsequent level.
73. 73
Flow Oriented Modeling
The Control Specification cont..
The CSPEC contains a state diagram that is a sequential specification of
behavior. It can also contain a program activation table—a combinatorial
specification of behavior.
A somewhat different mode of behavioral representation is the process
activation table. The PAT represents information contained in the state
diagram in the context of processes, not states. That is, the table
indicates which processes (bubbles) in the flow model will be invoked
when an event occurs. The PAT can be used as a guide for a designer who
must build an executive that controls the processes represented at this
level.
The CSPEC describes the behavior of the system, but it gives us no
information about the inner working of the processes that are activated
as a result of this behavior.
74. 74
4. The Process Specification :
The process specification (PSPEC) is used to describe all flow model
processes that appear at the final level of refinement.
The content of the process specification can include narrative text, a
program design language (PDL) description of the process algorithm,
mathematical equations, tables, or UML activity diagrams. By
providing a PSPEC to accompany each bubble in the flow model, you
can create a “mini-spec” that serves as a guide for design of the
software component that will implement the bubble.
76. 76
Behavioral Modeling
The behavioral model indicates how software will respond to external
events or stimuli.
To create the model, you should perform the following steps:
1. Evaluate all use cases to fully understand the sequence of
interaction within the system.
2. Identify events that drive the interaction sequence and
understand how these events relate to specific objects.
3. Create a sequence for each use case.
4. Build a state diagram for the system.
5. Review the behavioral model to verify accuracy and
consistency.
80. 80
# State Representations cont..
Two different behavioral representations are there.
The first indicates how an individual class changes state based on external
events and
The second shows the behavior of the software as a function of time.
1.State diagrams for analysis classes
One component of a behavioral model is a UML state diagram that represents
active states for each class and the events (triggers) that cause changes between
these active states.
Behavioral Modeling
82. 82
# State Representations cont..
State diagrams for analysis classes cont..
Each arrow represents a transition from one active state of an object to
another. The labels shown for each arrow represent the event that triggers the
transition.
Although the active state model provides useful insight into the “life history”
of an object, it is possible to specify additional information to provide more
depth in understanding the behavior of an object.
In addition to specifying the event that causes the transition to occur, you
can specify a guard and an action.
A guard is a Boolean condition that must be satisfied in order for the
transition to occur. For example, the guard for the transition from the “reading”
state to the “comparing” state can be determined by examining the use case
83. 83
# State Representations cont..
State diagrams for analysis classes cont..
If (password input = 4 digits) then compare to stored password
In general, the guard for a transition usually depends upon the value of
one or more attributes of an object. In other words, the guard depends on
the passive state of the object.
An action occurs concurrently with the state transition or as a
consequence of it and generally involves one or more operations
(responsibilities) of the object.
For example, the action connected to the password entered event is an
operation named validatePassword() that accesses a password object
and performs a digit-by-digit comparison to validate the entered
password.