Software architecture 2
•Download as PPT, PDF•
1 like•624 views
This document discusses types of software requirements including functional, non-functional, domain, and inverse requirements. It focuses on non-functional requirements, which relate to system-wide constraints like performance, reliability, security rather than individual functions. Non-functional requirements are critical and failure to meet them can make a system unusable. They arise from user needs, budgets, policies, need for interoperability, or external factors like regulations. The document provides examples of different categories of non-functional requirements and emphasizes the importance of properly addressing non-functional requirements in system design and architecture.
Report
Share
Report
Share
Recommended
Website's functional and non functional requirements
The document outlines the functional and non-functional requirements for designing a website. Functional requirements include following business rules, allowing transactions and corrections, having an external interface for users, complying with legal and regulatory standards, and providing authorization levels for users. Non-functional requirements include performance parameters like response time and throughput, recoverability so the system can recover from crashes, security measures to protect data, maintainability so the system can be maintained, and environmental compliance. The system should also have interoperability to work across different operating systems.
Requirement and Specification
The presentation discusses software requirements and specifications. It defines user requirements as more abstract statements of what services the system should provide, while system requirements provide more detailed descriptions of the system's functions and constraints. Functional requirements describe what the system will do, including inputs, outputs, and business rules. Non-functional requirements describe emergent system properties like performance, availability, and security. Finally, a software requirements document formally specifies both the user and system requirements and serves as an agreement between developers and customers.
Un it 2-se-mod-staff
The document discusses software requirements engineering. It describes what requirements are, different types of requirements including functional and non-functional requirements. It explains the requirements engineering process which includes activities like elicitation, analysis, validation and management. It also discusses modeling techniques used for requirements like prototyping and functional modeling using data flow diagrams. The requirements specification document is the key output which defines what the system needs to do at a high level without describing how it will be implemented.
Non functional requirements. do we really care…?
Non Functional requirements are an essential part of a project’s success, sometimes it becomes less focused area as everyone tries to make project successful in terms of functionality. This recorded webinar uncovers what can happen if Non Functional requirements are not addressed properly. What are the after impacts? You also learn the importance of Non Functional requirement, their identification, implementation and verification.
Non-Functional Requirements Are Important (with Explanatory Notes)
This version of the presentation includes extra slides with the text of the speaker's notes as I discovered that Slideshare does not make the notes visible to users.
LetsGrow Non-functional requirements
This document discusses non-functional requirements and their importance. It describes a workshop held to determine the top 3 non-functional requirements for Project X. The groups presented their results and rationale. Recent projects that lacked focus on non-functionals are discussed, and standards like ISO 9126 and QUINT that provide guidance. The conclusion questions whether more focus should be placed on non-functional requirements.
Validating Non Functional Requirements
The document discusses the importance of non-functional requirements (NFRs) in software development. It notes that NFRs such as performance, reliability, and usability must be defined, tested, and validated throughout the development lifecycle. Ignoring NFRs can negatively impact the cost, timeline, and ultimate success of a project. The document provides examples of different types of NFRs and urges considering stakeholders' perspectives to prioritize the most important NFRs to test.
Adressing nonfunctional requirements with agile practices
A recurring challenge with agile practices is how to address non-functional requirements. A non-functional requirement specifies "how well" the "what" must behave. They focus on characteristics such as security, maintainability, availability and performance that typically cut across functional requirements. Improperly dealing with nonfunctional requirements leads to the source code difficult to evolve or software with an unpleasant execution quality. During this session, you will learn how to specify these recurring concerns using self-contained constraints that can be satisfied iteration after iteration, in a finite period of time. Overall, you will acquire a different perspective on how to connect requirements and architecture using agile practices.
Recommended
Website's functional and non functional requirements
The document outlines the functional and non-functional requirements for designing a website. Functional requirements include following business rules, allowing transactions and corrections, having an external interface for users, complying with legal and regulatory standards, and providing authorization levels for users. Non-functional requirements include performance parameters like response time and throughput, recoverability so the system can recover from crashes, security measures to protect data, maintainability so the system can be maintained, and environmental compliance. The system should also have interoperability to work across different operating systems.
Requirement and Specification
The presentation discusses software requirements and specifications. It defines user requirements as more abstract statements of what services the system should provide, while system requirements provide more detailed descriptions of the system's functions and constraints. Functional requirements describe what the system will do, including inputs, outputs, and business rules. Non-functional requirements describe emergent system properties like performance, availability, and security. Finally, a software requirements document formally specifies both the user and system requirements and serves as an agreement between developers and customers.
Un it 2-se-mod-staff
The document discusses software requirements engineering. It describes what requirements are, different types of requirements including functional and non-functional requirements. It explains the requirements engineering process which includes activities like elicitation, analysis, validation and management. It also discusses modeling techniques used for requirements like prototyping and functional modeling using data flow diagrams. The requirements specification document is the key output which defines what the system needs to do at a high level without describing how it will be implemented.
Non functional requirements. do we really care…?
Non Functional requirements are an essential part of a project’s success, sometimes it becomes less focused area as everyone tries to make project successful in terms of functionality. This recorded webinar uncovers what can happen if Non Functional requirements are not addressed properly. What are the after impacts? You also learn the importance of Non Functional requirement, their identification, implementation and verification.
Non-Functional Requirements Are Important (with Explanatory Notes)
This version of the presentation includes extra slides with the text of the speaker's notes as I discovered that Slideshare does not make the notes visible to users.
LetsGrow Non-functional requirements
This document discusses non-functional requirements and their importance. It describes a workshop held to determine the top 3 non-functional requirements for Project X. The groups presented their results and rationale. Recent projects that lacked focus on non-functionals are discussed, and standards like ISO 9126 and QUINT that provide guidance. The conclusion questions whether more focus should be placed on non-functional requirements.
Validating Non Functional Requirements
The document discusses the importance of non-functional requirements (NFRs) in software development. It notes that NFRs such as performance, reliability, and usability must be defined, tested, and validated throughout the development lifecycle. Ignoring NFRs can negatively impact the cost, timeline, and ultimate success of a project. The document provides examples of different types of NFRs and urges considering stakeholders' perspectives to prioritize the most important NFRs to test.
Adressing nonfunctional requirements with agile practices
A recurring challenge with agile practices is how to address non-functional requirements. A non-functional requirement specifies "how well" the "what" must behave. They focus on characteristics such as security, maintainability, availability and performance that typically cut across functional requirements. Improperly dealing with nonfunctional requirements leads to the source code difficult to evolve or software with an unpleasant execution quality. During this session, you will learn how to specify these recurring concerns using self-contained constraints that can be satisfied iteration after iteration, in a finite period of time. Overall, you will acquire a different perspective on how to connect requirements and architecture using agile practices.
Functional and non functional
This document discusses functional and non-functional requirements. Functional requirements describe the behavior of a system and support user goals, while non-functional requirements describe how the system works and make it more usable. Functional requirements should include data descriptions, screen operations, workflows, and access controls. Non-functional requirements should cover usability, reliability, performance, and supportability. Non-functional requirements are further classified into categories like process, delivery, implementation, and external constraints.
Requirements engineering
The document discusses key aspects of requirements engineering including types of requirements, the requirements engineering process, and techniques used in requirements elicitation and analysis. It describes user requirements, system requirements, functional requirements, non-functional requirements, and domain requirements. The requirements engineering process involves activities like feasibility studies, requirements elicitation and analysis, requirements specification, validation, and management. Requirements elicitation and analysis techniques include requirements discovery, classification, prioritization, documentation, and dealing with issues that can arise.
Introduction to Software Engineering Course
This document provides an overview and introduction to the CSE 2205 Software Engineering course. It discusses the educational objectives of learning that building large software systems requires more than just programming. It introduces the instructor and describes how the course will be taught based on real-world experience rather than just textbooks. It also outlines the major course components, including a large multi-person project with milestones, lectures, presentations, and exams. Finally, it briefly defines software engineering and discusses why studying it is important given the size and critical nature of software today.
Requirements engineering scenario based software requirement specification
Requirements Engineering – Writing the Software Requirements Specification (SRS). A CRI Group Workshop. The requirements engineering approach employed successfully in the EHR4CR process is shown and discussed in order to extract lessons learned and to use it for new projects.
Requirements engineering is the process of eliciting stakeholder needs and desires and develope them into an agreed set of detailed requirements. It serves as basis for all subsequent software development activities.
In general, a project begins with the requirement acquisition phase and ends with the specification of requirements in form of the Software Requirement Specification (SRS). Requirements specification may even be used to manage the consistency of the entire system.
Learning from the Requirements Engineering process in the the EU project EHR4CR. Especially the topics of Requirements Scenarios in the process of requirement gathering and the iterative writing and validation of software requirements specification (SRS) document can be applied to new projects. The Requirements Process consists of 4 steps: Requirements Elicitation – the art to receive meaningful requirements. Requirements Analysis – iterative improvement of quality of requirements. Writing the Requirements Specification document (Software Requirement Specification) and Requirements Validation - this is also done iteratively with several workshops.
Novel is the introduction of an iterative process for requirements engineering. Start with only a subset of software requirements, iterate the collection and validation until the full system is implemented. In each iteration, design modifications are made and new functional capabilities are added. Following tools for requirements gathering were used: Use Cases, Descriptions of current situation and workflow, Context diagram, Stakeholder interviews, Scenarios and Use Case workshops.
A novel scenario based approach for requirements engineering is being introduced: The domain scenario is used to estimate probable effects (situation analysis and long-range planning). The domain scenario is broken down into high-level "Usage Scenarios". Usage Scenarios describe critical business interactions and their anticipated operations; they serve as context for the use cases and the generation of requirements; they make sure requirements are complete.
Development of the SRS with involvement of scenarios: 1. Begin with Domain Scenarios; 2. Development of Usage Scenarios; 3. Software Requirements Specification document. Several round of change management were employed during writing the SRS. This possibility for correction and improvement ensured that the requirements are of high quality and applicability.
Software Requirements engineering
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.
Requirements engineering processes
The document discusses different perspectives on requirements engineering (RE) processes:
(1) RE can be viewed as part of the larger systems engineering process involving system requirements, architectural design, integration, and validation;
(2) RE involves eliciting, analyzing, documenting, and validating requirements as part of the system acquisition and design processes in an iterative spiral manner;
(3) The inputs to RE include stakeholder needs, existing systems information, and standards, and the outputs include the system specification and models.
System requirements specification (srs)
The document defines a System Requirements Specification (SRS) as a written document that captures all functional and non-functional requirements for software deliverables. An SRS provides a complete and structured description of a system's requirements, behavior, and interfaces. It is a contract that translates business needs into a technical format. The SRS includes sections that cover requirements, design constraints, interfaces, and performance criteria. It provides direction for subsequent design and implementation phases.
Functional vs Non-functional Requirements - Which comes first?
What is the actual value of non functional requirements? How to identify them? What is the best practice of managing NFR?
Ppt
An SRS (software requirements specification) describes the functionality and performance of a software system being developed, including user requirements and system specifications. It precisely defines the product and is used to understand all development requirements. The SRS decomposes problems, provides feedback to customers, and serves as input for design and validation. It aims to establish agreement between customers and suppliers, reduce effort, and provide a cost and schedule baseline. The SRS should be complete, consistent, changeable and traceable.
Non functional requirements
Knowing of non-functional requirements helps you to avoid of customers say „You should thing better!“.
SRS(software requirement specification)
The document defines an SRS as the official statement of what system developers should implement, providing a complete description of the system behavior. An SRS precisely defines the software product and is used to understand requirements to design the software. It includes the purpose, product scope, features, interfaces, and other functional and non-functional requirements. The SRS benefits include establishing agreement between customers and suppliers, reducing development effort, and providing a baseline for validation.
Capturing Measurable Non Functional Requirements
Non-Functional Requirements are as important as Functional Requirements. Requirement that cannot be measured is not a requirement. NFR's are critical for successful software architecture development
When Requirements Change
This document discusses the importance of requirements traceability for managing changing requirements during software development. Requirements traceability links requirements to related artifacts like test cases, code, and defects to ensure changes propagate in all directions. When requirements change, the traceability matrix helps identify what other artifacts need updating by showing connections between requirements and development items. Maintaining bidirectional traceability from requirements to final tests and vice versa allows projects to stay on track as needs evolve.
Requirements Engineering
Requirements engineering is the discipline that involves establishing and documenting requirements. The various activities associated with requirements engineering are elicitation, specification, analysis, verification and validation, and management.
Visualizing non-functional requirements
This document discusses visualizing non-functional requirements (NFRs) such as usability, security, and performance in system analysis. It proposes using visual variables like color to represent goals related to NFRs and how they may cascade and impact each other. The document evaluates representing four sample NFRs - certainty, feasibility, trustability, and performance - and explores two approaches of operationalizing or orthogonalizing NFRs in visualizations. Future work discussed includes developing an algebra for abstracting NFR relationships and more empirical usability testing of conceptual model visualizations.
Non Functional Requirement.
Non-functional requirements describe how a system will operate rather than what it will do. They include qualities like usability, reliability, performance, and supportability. Usability measures how easy a system is to use, learn, and adapt to user needs. Reliability refers to the likelihood of failures and is measured by metrics like mean time between failures. Performance requirements specify the system's efficiency and response times. Supportability involves how easily a system can be maintained, internationalized, and adapted to changes.
Using Doors® And Taug2® To Support A Simplified
In order to become a market leader, it is imperative that all stakeholders (customers, financial sponsors, developers and testers) be aware of the customer’s needs as captured in the requirements of the products and/or services that are to be produced. This is especially so within both large and small globally distributed companies since the product development organizations often are separated by geography, time and communications. An efficient way to eliminate these potential issues is to develop a common and intuitive requirements management process, which can be deployed across the product development lifecycle. The object of developing a Common Simplified Requirements Management Process is to improve customer satisfaction, eliminate escaping defects and reduce the cost of the development lifecycle. This paper describes the problems of using localised procedures and how these problems can be eliminated by implementing a common requirements management process that is intuitive, scalable and deployed across the System Development Lifecycle. This process has been supported by the industry leading DOORS tool and more recently by the TauG2 tool. An auxiliary benefit of deploying this process is that the process was developed in compliance with standardized methods of documenting and tracing requirements as expected by TL9000 and CMM/CMMI. The net benefits of this simplified requirements process include: increased customer satisfaction due to systems being developed in accordance with the customer’s needs as captured in the requirements, compliance with industry acknowledged process standards and improved cost of quality by eliminating duplication of process maintenance since a common process has been deployed across the development organization.
SOFTWARE MAINTENANCE -4
This document discusses various aspects of software maintenance including roles, skill sets, organization structures, estimation of resources, and people issues. It covers factors to consider for estimating maintenance resources such as product complexity, experience levels, training needs, and customer expectations. Various organization models are described including functional, product-based, and distributed structures. Best practices include job rotation, internal deputations, and preventative maintenance while pitfalls involve overlooking communication costs and discrimination across locations.
Ch4-Software Engineering 9
The document discusses requirements engineering for software systems. It covers topics like functional and non-functional requirements, the software requirements document, requirements specification processes, and requirements elicitation, analysis, and management. Requirements engineering is the process of establishing customer needs for a system and constraints for its development and operation. Requirements can range from abstract to highly detailed and serve different purposes depending on their intended use.
SOFTWARE MAINTENANCE -2
The document discusses the key activities involved in software maintenance problem resolution and fix distribution. For problem resolution, it describes categorizing, prioritizing, reproducing, fixing, and scheduling problems. It also discusses identifying the right developer, documentation, and measurements. For fix distribution, it outlines choosing a distribution method like individual fixes or patch bundles, composing fixes, testing, and scheduling releases. It concludes with challenges, best practices, and effectiveness measures for both problem resolution and fix distribution.
Walk by faith_guillermo_maldonado_org
This document discusses the concept of faith from a Christian perspective. It defines faith as not being optimism, hope, knowledge or presumption, but rather as accessing the supernatural dimension given by God. It says we have a choice to walk by faith or by sight, and walking by faith pleases God. It provides signs that someone is walking by faith, such as resting in God rather than worrying, and having conviction about realities not yet seen. It encourages readers to exercise faith now by disconnecting the mind and having an appetite for the impossible. It concludes by inviting readers to accept Jesus Christ if they have not already done so.
Pip
Dokumen ini membahas tentang aliran-aliran pendidikan di Indonesia sejak dahulu yang terbagi menjadi beberapa aliran dengan tokoh dan sistem masing-masing. Aliran klasik memperoleh gagasan tentang pendidikan nasional dan lembaga-lembaga pendidikan, sedangkan aliran lainnya memperoleh ruang pendidikan dan sejumlah alumni. Dokumen ini menekankan pentingnya pendidikan yang lebih maju dan tepat untuk membawa Indonesia ke jen
More Related Content
What's hot
Functional and non functional
This document discusses functional and non-functional requirements. Functional requirements describe the behavior of a system and support user goals, while non-functional requirements describe how the system works and make it more usable. Functional requirements should include data descriptions, screen operations, workflows, and access controls. Non-functional requirements should cover usability, reliability, performance, and supportability. Non-functional requirements are further classified into categories like process, delivery, implementation, and external constraints.
Requirements engineering
The document discusses key aspects of requirements engineering including types of requirements, the requirements engineering process, and techniques used in requirements elicitation and analysis. It describes user requirements, system requirements, functional requirements, non-functional requirements, and domain requirements. The requirements engineering process involves activities like feasibility studies, requirements elicitation and analysis, requirements specification, validation, and management. Requirements elicitation and analysis techniques include requirements discovery, classification, prioritization, documentation, and dealing with issues that can arise.
Introduction to Software Engineering Course
This document provides an overview and introduction to the CSE 2205 Software Engineering course. It discusses the educational objectives of learning that building large software systems requires more than just programming. It introduces the instructor and describes how the course will be taught based on real-world experience rather than just textbooks. It also outlines the major course components, including a large multi-person project with milestones, lectures, presentations, and exams. Finally, it briefly defines software engineering and discusses why studying it is important given the size and critical nature of software today.
Requirements engineering scenario based software requirement specification
Requirements Engineering – Writing the Software Requirements Specification (SRS). A CRI Group Workshop. The requirements engineering approach employed successfully in the EHR4CR process is shown and discussed in order to extract lessons learned and to use it for new projects.
Requirements engineering is the process of eliciting stakeholder needs and desires and develope them into an agreed set of detailed requirements. It serves as basis for all subsequent software development activities.
In general, a project begins with the requirement acquisition phase and ends with the specification of requirements in form of the Software Requirement Specification (SRS). Requirements specification may even be used to manage the consistency of the entire system.
Learning from the Requirements Engineering process in the the EU project EHR4CR. Especially the topics of Requirements Scenarios in the process of requirement gathering and the iterative writing and validation of software requirements specification (SRS) document can be applied to new projects. The Requirements Process consists of 4 steps: Requirements Elicitation – the art to receive meaningful requirements. Requirements Analysis – iterative improvement of quality of requirements. Writing the Requirements Specification document (Software Requirement Specification) and Requirements Validation - this is also done iteratively with several workshops.
Novel is the introduction of an iterative process for requirements engineering. Start with only a subset of software requirements, iterate the collection and validation until the full system is implemented. In each iteration, design modifications are made and new functional capabilities are added. Following tools for requirements gathering were used: Use Cases, Descriptions of current situation and workflow, Context diagram, Stakeholder interviews, Scenarios and Use Case workshops.
A novel scenario based approach for requirements engineering is being introduced: The domain scenario is used to estimate probable effects (situation analysis and long-range planning). The domain scenario is broken down into high-level "Usage Scenarios". Usage Scenarios describe critical business interactions and their anticipated operations; they serve as context for the use cases and the generation of requirements; they make sure requirements are complete.
Development of the SRS with involvement of scenarios: 1. Begin with Domain Scenarios; 2. Development of Usage Scenarios; 3. Software Requirements Specification document. Several round of change management were employed during writing the SRS. This possibility for correction and improvement ensured that the requirements are of high quality and applicability.
Software Requirements engineering
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.
Requirements engineering processes
The document discusses different perspectives on requirements engineering (RE) processes:
(1) RE can be viewed as part of the larger systems engineering process involving system requirements, architectural design, integration, and validation;
(2) RE involves eliciting, analyzing, documenting, and validating requirements as part of the system acquisition and design processes in an iterative spiral manner;
(3) The inputs to RE include stakeholder needs, existing systems information, and standards, and the outputs include the system specification and models.
System requirements specification (srs)
The document defines a System Requirements Specification (SRS) as a written document that captures all functional and non-functional requirements for software deliverables. An SRS provides a complete and structured description of a system's requirements, behavior, and interfaces. It is a contract that translates business needs into a technical format. The SRS includes sections that cover requirements, design constraints, interfaces, and performance criteria. It provides direction for subsequent design and implementation phases.
Functional vs Non-functional Requirements - Which comes first?
What is the actual value of non functional requirements? How to identify them? What is the best practice of managing NFR?
Ppt
An SRS (software requirements specification) describes the functionality and performance of a software system being developed, including user requirements and system specifications. It precisely defines the product and is used to understand all development requirements. The SRS decomposes problems, provides feedback to customers, and serves as input for design and validation. It aims to establish agreement between customers and suppliers, reduce effort, and provide a cost and schedule baseline. The SRS should be complete, consistent, changeable and traceable.
Non functional requirements
Knowing of non-functional requirements helps you to avoid of customers say „You should thing better!“.
SRS(software requirement specification)
The document defines an SRS as the official statement of what system developers should implement, providing a complete description of the system behavior. An SRS precisely defines the software product and is used to understand requirements to design the software. It includes the purpose, product scope, features, interfaces, and other functional and non-functional requirements. The SRS benefits include establishing agreement between customers and suppliers, reducing development effort, and providing a baseline for validation.
Capturing Measurable Non Functional Requirements
Non-Functional Requirements are as important as Functional Requirements. Requirement that cannot be measured is not a requirement. NFR's are critical for successful software architecture development
When Requirements Change
This document discusses the importance of requirements traceability for managing changing requirements during software development. Requirements traceability links requirements to related artifacts like test cases, code, and defects to ensure changes propagate in all directions. When requirements change, the traceability matrix helps identify what other artifacts need updating by showing connections between requirements and development items. Maintaining bidirectional traceability from requirements to final tests and vice versa allows projects to stay on track as needs evolve.
Requirements Engineering
Requirements engineering is the discipline that involves establishing and documenting requirements. The various activities associated with requirements engineering are elicitation, specification, analysis, verification and validation, and management.
Visualizing non-functional requirements
This document discusses visualizing non-functional requirements (NFRs) such as usability, security, and performance in system analysis. It proposes using visual variables like color to represent goals related to NFRs and how they may cascade and impact each other. The document evaluates representing four sample NFRs - certainty, feasibility, trustability, and performance - and explores two approaches of operationalizing or orthogonalizing NFRs in visualizations. Future work discussed includes developing an algebra for abstracting NFR relationships and more empirical usability testing of conceptual model visualizations.
Non Functional Requirement.
Non-functional requirements describe how a system will operate rather than what it will do. They include qualities like usability, reliability, performance, and supportability. Usability measures how easy a system is to use, learn, and adapt to user needs. Reliability refers to the likelihood of failures and is measured by metrics like mean time between failures. Performance requirements specify the system's efficiency and response times. Supportability involves how easily a system can be maintained, internationalized, and adapted to changes.
Using Doors® And Taug2® To Support A Simplified
In order to become a market leader, it is imperative that all stakeholders (customers, financial sponsors, developers and testers) be aware of the customer’s needs as captured in the requirements of the products and/or services that are to be produced. This is especially so within both large and small globally distributed companies since the product development organizations often are separated by geography, time and communications. An efficient way to eliminate these potential issues is to develop a common and intuitive requirements management process, which can be deployed across the product development lifecycle. The object of developing a Common Simplified Requirements Management Process is to improve customer satisfaction, eliminate escaping defects and reduce the cost of the development lifecycle. This paper describes the problems of using localised procedures and how these problems can be eliminated by implementing a common requirements management process that is intuitive, scalable and deployed across the System Development Lifecycle. This process has been supported by the industry leading DOORS tool and more recently by the TauG2 tool. An auxiliary benefit of deploying this process is that the process was developed in compliance with standardized methods of documenting and tracing requirements as expected by TL9000 and CMM/CMMI. The net benefits of this simplified requirements process include: increased customer satisfaction due to systems being developed in accordance with the customer’s needs as captured in the requirements, compliance with industry acknowledged process standards and improved cost of quality by eliminating duplication of process maintenance since a common process has been deployed across the development organization.
SOFTWARE MAINTENANCE -4
This document discusses various aspects of software maintenance including roles, skill sets, organization structures, estimation of resources, and people issues. It covers factors to consider for estimating maintenance resources such as product complexity, experience levels, training needs, and customer expectations. Various organization models are described including functional, product-based, and distributed structures. Best practices include job rotation, internal deputations, and preventative maintenance while pitfalls involve overlooking communication costs and discrimination across locations.
Ch4-Software Engineering 9
The document discusses requirements engineering for software systems. It covers topics like functional and non-functional requirements, the software requirements document, requirements specification processes, and requirements elicitation, analysis, and management. Requirements engineering is the process of establishing customer needs for a system and constraints for its development and operation. Requirements can range from abstract to highly detailed and serve different purposes depending on their intended use.
SOFTWARE MAINTENANCE -2
The document discusses the key activities involved in software maintenance problem resolution and fix distribution. For problem resolution, it describes categorizing, prioritizing, reproducing, fixing, and scheduling problems. It also discusses identifying the right developer, documentation, and measurements. For fix distribution, it outlines choosing a distribution method like individual fixes or patch bundles, composing fixes, testing, and scheduling releases. It concludes with challenges, best practices, and effectiveness measures for both problem resolution and fix distribution.
What's hot (20)
Requirements engineering scenario based software requirement specification
Requirements engineering scenario based software requirement specification
Functional vs Non-functional Requirements - Which comes first?
Functional vs Non-functional Requirements - Which comes first?
Viewers also liked
Walk by faith_guillermo_maldonado_org
This document discusses the concept of faith from a Christian perspective. It defines faith as not being optimism, hope, knowledge or presumption, but rather as accessing the supernatural dimension given by God. It says we have a choice to walk by faith or by sight, and walking by faith pleases God. It provides signs that someone is walking by faith, such as resting in God rather than worrying, and having conviction about realities not yet seen. It encourages readers to exercise faith now by disconnecting the mind and having an appetite for the impossible. It concludes by inviting readers to accept Jesus Christ if they have not already done so.
Pip
Dokumen ini membahas tentang aliran-aliran pendidikan di Indonesia sejak dahulu yang terbagi menjadi beberapa aliran dengan tokoh dan sistem masing-masing. Aliran klasik memperoleh gagasan tentang pendidikan nasional dan lembaga-lembaga pendidikan, sedangkan aliran lainnya memperoleh ruang pendidikan dan sejumlah alumni. Dokumen ini menekankan pentingnya pendidikan yang lebih maju dan tepat untuk membawa Indonesia ke jen
The wanted then and now
The document profiles the members of the boy band The Wanted, providing their names, dates of birth, and some random facts about each member. It then summarizes the band's career accomplishments including reaching number one on music charts in the UK and Ireland with songs like "Glad You Came" and selling over 3 million copies of that single in the US. It concludes by stating that the band plans to continue taking over the world with their music and have already gained fans around the globe.
Continuous Delivery Applied (Agile Richmond)
Writing code is fun, but deploying to production is not. Production releases are scary events that last all weekend, and you find yourself worrying about how it will go. Did we miss a configuration file? Is the database schema the same as the one in the test environment? Does the last minute hot fix we just applied break any other features? Did I forget to include an installation instruction for the system administrators?
Continuous Delivery is a collection of principles and practices aimed at addressing the problems teams typically face when releasing changes to production. By applying rigorous automation, testing and configuration management, teams are able to confidently and consistently deploy changes from version control to production without fear.
In this talk, Mike McGarr will provide listeners with an introduction into the world of Continuous Delivery. After an introduction into the concepts and principles of Continuous Delivery, he will discuss many of the techniques for implementing Continuous Delivery and recommend some tools that can be used on your development project.
Software architecture First Lecture
The document discusses software architecture and engineering. It defines software architecture as the fundamental organization of a system, including its components, relationships, and governing principles. Software engineering is described as the application of engineering principles to software development, including all aspects of software production. The document emphasizes that software architecture must balance potentially conflicting requirements related to cost, efficiency, reliability, and user experience.
Synthese barometre metiers_communication_2015
Nous vous proposons de retrouver la présentation de Mr Amaury Laurentin, ayant intervenu à l'occasion de notre Master Class #2 : Le baromètre des métiers de la communication, répondant à l'une de nos interrogations : la nouvelle donne agences/annonceurs.
Nous avons eu le plaisir de partager ce moment accompagnés des adhérents du Club Média Méditerranée ce qui a permis d'ouvrir un échange constructif sur des problématiques communes.
State of the web
This document discusses the evolution of web design from 1997 to present day. It notes that in the early days of web design in the late 1990s, the domain was dominated by technicians and "home page designers" focused more on functionality than aesthetics. By around 2002, web design matured as a discipline as hardware, software, and standards improved. However, limitations remained in areas like typography and bandwidth. The document argues that new technologies like HTML5, CSS3, and web fonts have enabled true freedom and maturity in web design by allowing for freedom in typography, design, animation, and integration of content, design, and interface. It stresses the importance of high quality, well-designed content and maintaining control over content
Software architecture3
The document discusses the importance of requirements in software engineering projects and defines different types of requirements like functional and non-functional requirements. It provides examples of functional requirements for different domains and notes that requirements should be clear, unambiguous and at an appropriate level of detail to avoid issues in development. Functional requirements capture the key behaviors and functions of the intended system.
Software architecture6
The document discusses various software architecture styles and models including data-centered architecture, repository model, client/server architectures, thin client model, fat client model, and zero client install. It provides details on client/server characteristics and advantages and disadvantages of thin client, fat client, and zero client install models. The document ends with references on requirements engineering and software engineering.
Continuous Delivery Applied (AgileDC)
Writing code is fun, but deploying to production is not. Production releases are scary events that last all weekend, and you find yourself worrying about how it will go. Did we miss a configuration file? Is the database schema the same as the one in the test environment? Does the last minute hot fix we just applied break any other features? Did I forget to include an installation instruction for the system administrators?
Continuous Delivery is a collection of principles and practices aimed at addressing the problems teams typically face when releasing changes to production. By applying rigorous automation, testing and configuration management, teams are able to confidently and consistently deploy changes from version control to production without fear.
In this talk, Mike McGarr will provide listeners with an introduction into the world of Continuous Delivery. After an introduction into the concepts and principles of Continuous Delivery, he will discuss many of the techniques for implementing Continuous Delivery and recommend some tools that can be used on your development project.
Continuous delivery applied (DC CI User Group)
These are slides I used to present to the DC Continuous Integration, Delivery and Deployment User Group on
Writing code is fun, but deploying to production is not. Production releases are scary events that last all weekend, and you find yourself worrying about how it will go. Did we miss a configuration file? Is the database schema the same as the one in the test environment? Does the last minute hot fix we just applied break any other features? Did I forget to include an installation instruction for the system administrators?
Continuous Delivery is a collection of principles and practices aimed at addressing the problems teams typically face when releasing changes to production. By applying rigorous automation, testing and configuration management, teams are able to confidently and consistently deploy changes from version control to production without fear.
In this talk, Mike McGarr will provide listeners with an introduction into the world of Continuous Delivery. After an introduction into the concepts and principles of Continuous Delivery, he will discuss many of the techniques for implementing Continuous Delivery and recommend some tools that can be used on your development project.
Jose victor patiño duran - curriculum
The document discusses the benefits of exercise for mental health. Regular physical activity can help reduce anxiety and depression and improve mood and cognitive function. Exercise causes chemical changes in the brain that may help protect against mental illness and improve symptoms.
Developing for Multiple Platforms
This presentation will investigate how to take advantage of Web technologies (including HTML5, CSS3, and JavaScript) to build a cross-platform mobile app. The presentation will cover important steps towards optimizing a Web app for a mobile device as well as using PhoneGap to expose core device features, like the accelerometer or the camera, to an app.
Viewers also liked (20)
Similar to Software architecture 2
Se lect9 btech
The document discusses different types of requirements for software systems including user requirements, system requirements, domain requirements, functional requirements, and non-functional requirements. It provides details on each type, including that user requirements are written for customers in natural language, system requirements serve as a contract between client and developer, and domain requirements reflect characteristics of the application domain. Functional requirements describe system services while non-functional requirements constrain system functions and development processes. The document also discusses challenges with specifying non-functional requirements and provides examples of performance, reliability, security, usability, and safety requirements for critical systems.
6. FUNDAMENTALS OF SE AND REQUIREMENT ENGINEERING.ppt
This document discusses requirement engineering fundamentals including requirement elicitation, analysis, and system models. It defines what requirements are, describes different types of requirements like user requirements, system requirements, functional requirements, and non-functional requirements. It also discusses requirements engineering processes like requirements elicitation and analysis, specification, validation, and the use of system models. Key activities in requirements engineering include establishing customer needs, specifying services and constraints, and generating requirements descriptions.
Lecture 5 Types of Requirements I.pptx
This document discusses types of software requirements, with a focus on non-functional requirements (NFRs). It describes NFRs as important to capture a system's emergent behavior. NFRs can be divided into three categories: performance, design constraints, and commercial constraints. The document emphasizes that NFRs should be expressed quantitatively using measurable metrics to make them verifiable. It provides examples of metrics that can be used to measure properties like speed, size, ease of use, reliability, portability, and more. Quantitatively verifying NFRs can help ensure systems meet requirements, though the cost may be high.
SE Unit 2(1).pptx
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.
SRE_Lecture_1,2,3,4.pptx
This document provides an overview of a course on software requirements engineering. It discusses how following requirements engineering practices can improve project quality, meet schedules by controlling scope and changes, and increase customer satisfaction. The course covers topics like what requirements are, how to develop them, requirements for different project types, requirements management, and implementing requirements engineering. It also lists recommended books on requirements and provides an excerpt from part of the course which defines different types of requirements and discusses requirements development and management.
04 fse understandingrequirements
This document discusses requirements engineering (RE) and requirements elicitation. It defines requirements as conditions or capabilities needed by users. Requirements can be functional (specifying system functions) or non-functional (specifying quality attributes). The RE process involves eliciting, analyzing, specifying, verifying, and managing requirements. Requirements elicitation is the first critical task, which discovers requirements from stakeholders through understanding their needs, domain, and problems. Elicitation works to produce requirements documents and other artifacts. Challenges to elicitation include scope issues, volatility of requirements over time, and difficulties in stakeholders communicating their needs clearly.
Requirements engineering
The document discusses the requirements engineering process, which includes establishing the services required of a system and the constraints on its operation. It involves tasks like requirements elicitation, analysis, specification, validation and management. These help understand what users want from the software and its business impact. The document outlines the various stages of requirements engineering like feasibility studies, elicitation, analysis, specification and validation. It also describes different types of requirements like functional, non-functional and their characteristics.
Software Engineering Lec 4-requirments
Requirements engineering involves analyzing user needs and constraints to define the services and limitations of a software system. It has several key steps:
1. Requirements analysis identifies stakeholders and understands requirements through client interviews to define both functional requirements about system services and non-functional constraints.
2. Requirements are documented in a requirements specification that defines what the system should do without describing how.
3. The document is validated through reviews and prototyping to ensure requirements accurately capture user needs before development begins.
3. 1 req elicitation
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.
Greate Introduction to Software Engineering @ Track IT Academy
The document provides an overview of software engineering concepts including software processes, rapid software development, practices, and a case study on the V-Model process. It defines software and software engineering. It describes common software process models like waterfall, iterative development, and component-based development. It also covers rapid software development approaches like incremental delivery and agile methods. Key practices discussed include pair programming, prototyping, and activities in the software development lifecycle. Finally, it presents the phases of the V-Model process and how it maps testing to requirements and design.
Software requirement and specification
The document discusses software requirement specification and the requirement engineering process. It describes how requirements are elicited from stakeholders, analyzed for consistency and completeness, and specified in a requirements document. The key activities in requirements engineering include requirements elicitation, analysis, validation, and management, which are iterative processes.
Software requirement and specification
The document discusses software requirements and specifications. It explains that requirements engineering is the process of establishing customer requirements for a system. Requirements can range from high-level abstract statements to detailed functional specifications. Both types of statements may be called requirements. The document also discusses different types of requirements like user requirements, system requirements, functional requirements, and non-functional requirements. It provides examples and explanations of each. The structure and intended users of a requirements document are also covered.
Requirement Engineering
The document discusses requirements engineering for software systems. It introduces concepts like user requirements, system requirements, functional requirements and non-functional requirements. It explains the process of requirements analysis and specification. Requirements can be organized in a requirements document and must be specified precisely to avoid ambiguity. Both functional and non-functional requirements are important to define the key aspects of the system.
2nd MODULE Software Requirements _ SW ENGG 22CSE141.pdf
SOFTWARE ENGINEERING
Course Code: 22CSE141
Module 2: Software Requirements
•SOFTWARE ENGINEERING
Course Code: 22CSE141
Module 2: Software Requirements,
•Functional and nonfunctional requirements,
•User requirements,
•Software requirements Document,
•Requirement Engineering Process,
•Feasibility studies,
•Requirements elicitation and analysis,
•Requirements validation
•System models:
•Context Models,
•Behavioral models,
•Data models,
•Object models,
•structured methods.
•User requirements,
•Software requirements Document
•Requirement Engineering Process
•Feasibility studies,
•Requirements elicitation and analysis,
•Requirements validation
•System models:
•Context Models,
•Behavioral models,
•Data models,
•Object models,
•structured methods.
SOFTWARE ENGINEERING
This is sofware engg , 3rd sem MBA , it has basics and important topics it will help you specially during exams ...all the best
Software Requirements
The document outlines the software requirements engineering process, which includes gathering requirements from stakeholders, documenting them in a software requirements specification (SRS), and validating the requirements. It discusses the different types of requirements like functional, non-functional, and domain requirements. It also describes various techniques used for eliciting requirements, such as interviews, surveys, questionnaires, task analysis, domain analysis, brainstorming, and prototyping.
Software Development
The document describes the key activities and concepts in software development processes including requirements analysis, specification, architecture, design, implementation, testing, deployment, and maintenance. It discusses various process models like waterfall, agile, iterative, RAD, and XP. It also covers supporting disciplines such as configuration management, documentation, quality assurance, and project management as well as development tools.
Software engineering lecture 1
This document discusses software requirements and how to document them. It covers the concepts of functional and non-functional requirements, user requirements versus system requirements, and how requirements can be organized in a requirements document. Different ways of specifying requirements are described, including natural language, structured language, tables, and graphical models. The document also discusses issues like ambiguity, completeness, and consistency in requirements.
8 requirements engineering1
This document provides an overview of requirements engineering for software development. It defines requirements as descriptions of the services a system should provide and constraints under which it operates. Requirements can be functional, describing what a system should do, or non-functional, describing properties like performance or security. The document discusses best practices for writing requirements, including avoiding ambiguity and ensuring requirements are complete and consistent. It also describes the purpose and typical structure of a software requirements specification document.
Similar to Software architecture 2 (20)
6. FUNDAMENTALS OF SE AND REQUIREMENT ENGINEERING.ppt
6. FUNDAMENTALS OF SE AND REQUIREMENT ENGINEERING.ppt
Greate Introduction to Software Engineering @ Track IT Academy
Greate Introduction to Software Engineering @ Track IT Academy
2nd MODULE Software Requirements _ SW ENGG 22CSE141.pdf
2nd MODULE Software Requirements _ SW ENGG 22CSE141.pdf
Recently uploaded
Pengantar Penggunaan Flutter - Dart programming language1.pptx
Pengantar Penggunaan Flutter - Dart programming language1.pptx
How to Fix the Import Error in the Odoo 17
An import error occurs when a program fails to import a module or library, disrupting its execution. In languages like Python, this issue arises when the specified module cannot be found or accessed, hindering the program's functionality. Resolving import errors is crucial for maintaining smooth software operation and uninterrupted development processes.
Reimagining Your Library Space: How to Increase the Vibes in Your Library No ...
Librarians are leading the way in creating future-ready citizens – now we need to update our spaces to match. In this session, attendees will get inspiration for transforming their library spaces. You’ll learn how to survey students and patrons, create a focus group, and use design thinking to brainstorm ideas for your space. We’ll discuss budget friendly ways to change your space as well as how to find funding. No matter where you’re at, you’ll find ideas for reimagining your space in this session.
LAND USE LAND COVER AND NDVI OF MIRZAPUR DISTRICT, UP
This Dissertation explores the particular circumstances of Mirzapur, a region located in the
core of India. Mirzapur, with its varied terrains and abundant biodiversity, offers an optimal
environment for investigating the changes in vegetation cover dynamics. Our study utilizes
advanced technologies such as GIS (Geographic Information Systems) and Remote sensing to
analyze the transformations that have taken place over the course of a decade.
The complex relationship between human activities and the environment has been the focus
of extensive research and worry. As the global community grapples with swift urbanization,
population expansion, and economic progress, the effects on natural ecosystems are becoming
more evident. A crucial element of this impact is the alteration of vegetation cover, which plays a
significant role in maintaining the ecological equilibrium of our planet.Land serves as the foundation for all human activities and provides the necessary materials for
these activities. As the most crucial natural resource, its utilization by humans results in different
'Land uses,' which are determined by both human activities and the physical characteristics of the
land.
The utilization of land is impacted by human needs and environmental factors. In countries
like India, rapid population growth and the emphasis on extensive resource exploitation can lead
to significant land degradation, adversely affecting the region's land cover.
Therefore, human intervention has significantly influenced land use patterns over many
centuries, evolving its structure over time and space. In the present era, these changes have
accelerated due to factors such as agriculture and urbanization. Information regarding land use and
cover is essential for various planning and management tasks related to the Earth's surface,
providing crucial environmental data for scientific, resource management, policy purposes, and
diverse human activities.
Accurate understanding of land use and cover is imperative for the development planning
of any area. Consequently, a wide range of professionals, including earth system scientists, land
and water managers, and urban planners, are interested in obtaining data on land use and cover
changes, conversion trends, and other related patterns. The spatial dimensions of land use and
cover support policymakers and scientists in making well-informed decisions, as alterations in
these patterns indicate shifts in economic and social conditions. Monitoring such changes with the
help of Advanced technologies like Remote Sensing and Geographic Information Systems is
crucial for coordinated efforts across different administrative levels. Advanced technologies like
Remote Sensing and Geographic Information Systems
9
Changes in vegetation cover refer to variations in the distribution, composition, and overall
structure of plant communities across different temporal and spatial scales. These changes can
occur natural.
How to Make a Field Mandatory in Odoo 17
In Odoo, making a field required can be done through both Python code and XML views. When you set the required attribute to True in Python code, it makes the field required across all views where it's used. Conversely, when you set the required attribute in XML views, it makes the field required only in the context of that particular view.
How to Create a More Engaging and Human Online Learning Experience
How to Create a More Engaging and Human Online Learning Experience Wahiba Chair Training & Consulting
Wahiba Chair's Talk at the 2024 Learning Ideas Conference. RHEOLOGY Physical pharmaceutics-II notes for B.pharm 4th sem students
Physical pharmaceutics notes for B.pharm students
Hindi varnamala | hindi alphabet PPT.pdf
हिंदी वर्णमाला पीपीटी, hindi alphabet PPT presentation, hindi varnamala PPT, Hindi Varnamala pdf, हिंदी स्वर, हिंदी व्यंजन, sikhiye hindi varnmala, dr. mulla adam ali, hindi language and literature, hindi alphabet with drawing, hindi alphabet pdf, hindi varnamala for childrens, hindi language, hindi varnamala practice for kids, https://www.drmullaadamali.com
Pollock and Snow "DEIA in the Scholarly Landscape, Session One: Setting Expec...
Pollock and Snow "DEIA in the Scholarly Landscape, Session One: Setting Expec...National Information Standards Organization (NISO)
This presentation was provided by Steph Pollock of The American Psychological Association’s Journals Program, and Damita Snow, of The American Society of Civil Engineers (ASCE), for the initial session of NISO's 2024 Training Series "DEIA in the Scholarly Landscape." Session One: 'Setting Expectations: a DEIA Primer,' was held June 6, 2024.বাংলাদেশ অর্থনৈতিক সমীক্ষা (Economic Review) ২০২৪ UJS App.pdf
বাংলাদেশের অর্থনৈতিক সমীক্ষা ২০২৪ [Bangladesh Economic Review 2024 Bangla.pdf] কম্পিউটার , ট্যাব ও স্মার্ট ফোন ভার্সন সহ সম্পূর্ণ বাংলা ই-বুক বা pdf বই " সুচিপত্র ...বুকমার্ক মেনু 🔖 ও হাইপার লিংক মেনু 📝👆 যুক্ত ..
আমাদের সবার জন্য খুব খুব গুরুত্বপূর্ণ একটি বই ..বিসিএস, ব্যাংক, ইউনিভার্সিটি ভর্তি ও যে কোন প্রতিযোগিতা মূলক পরীক্ষার জন্য এর খুব ইম্পরট্যান্ট একটি বিষয় ...তাছাড়া বাংলাদেশের সাম্প্রতিক যে কোন ডাটা বা তথ্য এই বইতে পাবেন ...
তাই একজন নাগরিক হিসাবে এই তথ্য গুলো আপনার জানা প্রয়োজন ...।
বিসিএস ও ব্যাংক এর লিখিত পরীক্ষা ...+এছাড়া মাধ্যমিক ও উচ্চমাধ্যমিকের স্টুডেন্টদের জন্য অনেক কাজে আসবে ...
Advanced Java[Extra Concepts, Not Difficult].docx
This is part 2 of my Java Learning Journey. This contains Hashing, ArrayList, LinkedList, Date and Time Classes, Calendar Class and more.
ISO/IEC 27001, ISO/IEC 42001, and GDPR: Best Practices for Implementation and...
Denis is a dynamic and results-driven Chief Information Officer (CIO) with a distinguished career spanning information systems analysis and technical project management. With a proven track record of spearheading the design and delivery of cutting-edge Information Management solutions, he has consistently elevated business operations, streamlined reporting functions, and maximized process efficiency.
Certified as an ISO/IEC 27001: Information Security Management Systems (ISMS) Lead Implementer, Data Protection Officer, and Cyber Risks Analyst, Denis brings a heightened focus on data security, privacy, and cyber resilience to every endeavor.
His expertise extends across a diverse spectrum of reporting, database, and web development applications, underpinned by an exceptional grasp of data storage and virtualization technologies. His proficiency in application testing, database administration, and data cleansing ensures seamless execution of complex projects.
What sets Denis apart is his comprehensive understanding of Business and Systems Analysis technologies, honed through involvement in all phases of the Software Development Lifecycle (SDLC). From meticulous requirements gathering to precise analysis, innovative design, rigorous development, thorough testing, and successful implementation, he has consistently delivered exceptional results.
Throughout his career, he has taken on multifaceted roles, from leading technical project management teams to owning solutions that drive operational excellence. His conscientious and proactive approach is unwavering, whether he is working independently or collaboratively within a team. His ability to connect with colleagues on a personal level underscores his commitment to fostering a harmonious and productive workplace environment.
Date: May 29, 2024
Tags: Information Security, ISO/IEC 27001, ISO/IEC 42001, Artificial Intelligence, GDPR
-------------------------------------------------------------------------------
Find out more about ISO training and certification services
Training: ISO/IEC 27001 Information Security Management System - EN | PECB
ISO/IEC 42001 Artificial Intelligence Management System - EN | PECB
General Data Protection Regulation (GDPR) - Training Courses - EN | PECB
Webinars: https://pecb.com/webinars
Article: https://pecb.com/article
-------------------------------------------------------------------------------
For more information about PECB:
Website: https://pecb.com/
LinkedIn: https://www.linkedin.com/company/pecb/
Facebook: https://www.facebook.com/PECBInternational/
Slideshare: http://www.slideshare.net/PECBCERTIFICATION
BÀI TẬP DẠY THÊM TIẾNG ANH LỚP 7 CẢ NĂM FRIENDS PLUS SÁCH CHÂN TRỜI SÁNG TẠO ...
BÀI TẬP DẠY THÊM TIẾNG ANH LỚP 7 CẢ NĂM FRIENDS PLUS SÁCH CHÂN TRỜI SÁNG TẠO ...Nguyen Thanh Tu Collection
https://app.box.com/s/qhtvq32h4ybf9t49ku85x0n3xl4jhr15clinical examination of hip joint (1).pdf
described clinical examination all orthopeadic conditions .
Recently uploaded (20)
Pengantar Penggunaan Flutter - Dart programming language1.pptx
Pengantar Penggunaan Flutter - Dart programming language1.pptx
Film vocab for eal 3 students: Australia the movie
Film vocab for eal 3 students: Australia the movie
Reimagining Your Library Space: How to Increase the Vibes in Your Library No ...
Reimagining Your Library Space: How to Increase the Vibes in Your Library No ...
LAND USE LAND COVER AND NDVI OF MIRZAPUR DISTRICT, UP
LAND USE LAND COVER AND NDVI OF MIRZAPUR DISTRICT, UP
How to Create a More Engaging and Human Online Learning Experience
How to Create a More Engaging and Human Online Learning Experience
RHEOLOGY Physical pharmaceutics-II notes for B.pharm 4th sem students
RHEOLOGY Physical pharmaceutics-II notes for B.pharm 4th sem students
Pollock and Snow "DEIA in the Scholarly Landscape, Session One: Setting Expec...
Pollock and Snow "DEIA in the Scholarly Landscape, Session One: Setting Expec...
বাংলাদেশ অর্থনৈতিক সমীক্ষা (Economic Review) ২০২৪ UJS App.pdf
বাংলাদেশ অর্থনৈতিক সমীক্ষা (Economic Review) ২০২৪ UJS App.pdf
ISO/IEC 27001, ISO/IEC 42001, and GDPR: Best Practices for Implementation and...
ISO/IEC 27001, ISO/IEC 42001, and GDPR: Best Practices for Implementation and...
BÀI TẬP DẠY THÊM TIẾNG ANH LỚP 7 CẢ NĂM FRIENDS PLUS SÁCH CHÂN TRỜI SÁNG TẠO ...
BÀI TẬP DẠY THÊM TIẾNG ANH LỚP 7 CẢ NĂM FRIENDS PLUS SÁCH CHÂN TRỜI SÁNG TẠO ...
Software architecture 2
- 1. Software Architecture & Design Syed Salman Qadri Asisstant Professor (CS) The Islamia University of Bahawalpur
- 2. Types of Software Requirements • Functional requirements • Non-functional requirements • Domain requirements • Inverse requirements • Design and implementation constraints
- 4. Non-Functional Requirements • Most non-functional requirements relate to the system as a whole. They include constraints on timing, performance, reliability, security, maintainability, accuracy, the development process, standards, etc.
- 5. Non-Functional Requirements • They are often more critical than individual functional requirements • Capture the emergent behavior of the system, that is they relate to system as a whole
- 6. Continued… • Must be built into the framework of the software product • Failure to meet a non-functional system requirement may make the whole system unusable
- 7. Example • For example, if an aircraft system does not meet reliability requirements, it will not be certified as ‘safe’ • If a real-time control system fails to meet its performance requirements, the control functions will not operate correctly
- 8. Non-Functional Requirements • Non-functional requirements arise through user needs, because of budget constraints, because of organizational policies, because of the need of interoperability with other software and hardware systems, or because of external factors such as safety regulations, privacy legislation, etc.
- 9. Non-Functional Requirements Non-Functional requirements Product Organizational External requirements requirements requirements
- 10. Product Requirements Product requirements Usability Efficiency Reliability Portability requirements requirements requirements requirements Performance Space requirements requirements
- 11. Product Requirements Examples • The system shall allow one hundred thousand hits per minute on the website • The system shall not have down time of more than one second for continuous execution of one thousand hours
- 12. Organizational Requirements Organizational requirements Standards Implementation Delivery requirements requirements requirements
- 13. Organizational Requirements Examples • Any development work sub-contracted by the development organization shall be carried out in accordance with Capability Maturity Model
- 14. External Requirements External requirements Interoperability Ethical Legislative requirements requirements requirements Privacy Safety requirements requirements
- 15. Examples External Requirements • The system shall not disclose any personal information about members of the library system to other members except system administrators • The system shall comply with the local and national laws regarding the use of software tools
- 16. Observations on Non-Functional Requirements • Non-functional requirements can be written to reflect general goals for the system. Examples include: – Ease of use – Recovery from failure – Rapid user response
- 17. Observations on Non-Functional Requirements • Goals can be useful to designers and developers, as they give clues to them about priorities of the customers
- 18. Observations on Non-Functional Requirements • Some negotiations must be done among different stakeholders, to achieve an agreement in these situations
- 19. Observations on Non-Functional Requirements • Non-functional requirements should be highlighted in the requirements document, so that they can be used to build the architecture of the software product
- 20. Summary • Discussed different aspects of the non-functional requirements • Non-functional requirements capture very important emergent behavior of the automated system • Due importance, time, and resources should be given to non-functional requirements
- 21. References • ‘Requirements Engineering: Processes and Techniques’ by G. Kotonya and I. Sommerville, John Wiley & Sons, 1998 • Software Requirements: Objects, Functions, and States by A. Davis, PH, 1993 • Software Engineering 6th Edition, by I. Sommerville, 2000 • Software Engineering 5th Edition, by R. Pressman