In this advanced business analysis training session, you will learn Requirement Verification and Validation. Topics covered in this session are:
• Requirements Negotiation And Prioritization
• Requirements Management
• Requirements Traceability
• Requirements Variability and Software/System Product Lines
For more information, click here: https://www.mindsmapped.com/courses/business-analysis/advanced-business-analyst-training/
In this Business Analysis training session, you will learn about Requirement Management. Topics covered in this session are:
• Requirements Management
• Requirement Prioritization
• MoSCoW Analysis
• Time Boxing
• Voting Technique
• Verifying and Validating Requirements
• Verifying Requirements
• Validate Requirements
• Key Requirements Management Practices
• The Requirements Baseline
• Requirements Version Management
• Requirements Change Control
• Impact Analysis of Requirements
• Requirements Attributes
• Requirements status tracking
• Requirements Traceability
• Requirements Traceability Matrix
For more information, click here: https://www.mindsmapped.com/courses/business-analysis/become-a-business-analyst-with-hands-on-practice/
In this Business Analysis training session, you will learn about Requirement Management. Topics covered in this session are:
• Requirements Management
• Requirement Prioritization
• MoSCoW Analysis
• Time Boxing
• Voting Technique
• Verifying and Validating Requirements
• Verifying Requirements
• Validate Requirements
• Key Requirements Management Practices
• The Requirements Baseline
• Requirements Version Management
• Requirements Change Control
• Impact Analysis of Requirements
• Requirements Attributes
• Requirements status tracking
• Requirements Traceability
• Requirements Traceability Matrix
For more information, click here: https://www.mindsmapped.com/courses/business-analysis/become-a-business-analyst-with-hands-on-practice/
Requirement prioritization is used in Software product management for determining which candidate requirements of a software product should be included in a certain release. Requirements are also prioritized to minimize risk during development so that the most important or high risk requirements are implemented first. Several methods for assessing a prioritization of software requirements exist.
Objectives:
1. To understand the different processes in the realm of ‘Requirements Engineering’.
2. To see the challenges in requirements development and the importance of getting requirements right in an IT project.
3. To understand the different techniques used in different phases and processes of requirements development and management.
Slides from a session presented by Fadi Stephan from Kaizenko at the 2019 Global Scrum Gathering in Austin, TX on 05/20/2019 DC. Also see the blog series on Agile Testing at https://www.kaizenko.com/agile-testing/
Abstract:
Many teams struggle with fitting in testing activities inside of a Sprint. They end up doing primarily development activities in a Sprint and push testing activities to run in dedicated testing Sprints following the coding Sprints or have a coding and testing Sprint running in parallel. However, in Scrum, the output of every Sprint is a potentially shippable product increment. This means the product increment should be well tested within the Sprint and ready to be delivered. Come to this presentation to learn how to tackle testing on an Agile team, what kind of tests to execute, what to automate and what not to automate, the different test responsibilities, and when to run which tests. Leave with a testing strategy that you can start applying the next day to gradually get a team to start testing from day 1 of the Sprint and deliver a true product increment at the end of each Sprint.
Software requirements engineering problems and challenges erp implementation as a case study:
Requirements Engineering
Why are Requirements so important?
Purpose of Requirements Engineering
RE process inputs and outputs
Requirements Engineering Activities
Requirements Quality
Requirements quality indicators
Systems RE Standards
Requirements problems and challenges
Research Strategies in RE
RE Research directions
Conclusion
In this advanced business analysis training session, you will learn Requirement Elicitation. Topics covered in this session are:
• What is Elicitation?
• The elicitation methodology
• The stakeholder connection
• Stakeholder Analysis
• Brainstorming
• One-to-One Interview
• Group Interview
• Document Analysis
• Focus Group
• Interface Analysis
• Observation/Social Analysis
• Prototyping
• Use case and scenarios
• Requirements reuse
• Pre-Project Activity
• Request for Proposal
For more information, click here: https://www.mindsmapped.com/courses/business-analysis/advanced-business-analyst-training/
Requirement prioritization is used in Software product management for determining which candidate requirements of a software product should be included in a certain release. Requirements are also prioritized to minimize risk during development so that the most important or high risk requirements are implemented first. Several methods for assessing a prioritization of software requirements exist.
Objectives:
1. To understand the different processes in the realm of ‘Requirements Engineering’.
2. To see the challenges in requirements development and the importance of getting requirements right in an IT project.
3. To understand the different techniques used in different phases and processes of requirements development and management.
Slides from a session presented by Fadi Stephan from Kaizenko at the 2019 Global Scrum Gathering in Austin, TX on 05/20/2019 DC. Also see the blog series on Agile Testing at https://www.kaizenko.com/agile-testing/
Abstract:
Many teams struggle with fitting in testing activities inside of a Sprint. They end up doing primarily development activities in a Sprint and push testing activities to run in dedicated testing Sprints following the coding Sprints or have a coding and testing Sprint running in parallel. However, in Scrum, the output of every Sprint is a potentially shippable product increment. This means the product increment should be well tested within the Sprint and ready to be delivered. Come to this presentation to learn how to tackle testing on an Agile team, what kind of tests to execute, what to automate and what not to automate, the different test responsibilities, and when to run which tests. Leave with a testing strategy that you can start applying the next day to gradually get a team to start testing from day 1 of the Sprint and deliver a true product increment at the end of each Sprint.
Software requirements engineering problems and challenges erp implementation as a case study:
Requirements Engineering
Why are Requirements so important?
Purpose of Requirements Engineering
RE process inputs and outputs
Requirements Engineering Activities
Requirements Quality
Requirements quality indicators
Systems RE Standards
Requirements problems and challenges
Research Strategies in RE
RE Research directions
Conclusion
In this advanced business analysis training session, you will learn Requirement Elicitation. Topics covered in this session are:
• What is Elicitation?
• The elicitation methodology
• The stakeholder connection
• Stakeholder Analysis
• Brainstorming
• One-to-One Interview
• Group Interview
• Document Analysis
• Focus Group
• Interface Analysis
• Observation/Social Analysis
• Prototyping
• Use case and scenarios
• Requirements reuse
• Pre-Project Activity
• Request for Proposal
For more information, click here: https://www.mindsmapped.com/courses/business-analysis/advanced-business-analyst-training/
Useful for BE E & TC engineering students to prepare SRS, SDS documents before implementing their projects. Unit II. It is designed as per SPPU syllabus of Electronic Product Design, BE E & TC Engineering
Software Engineering REQUIREMENTS ANALYSIS AND SPECIFICATIONDr Anuranjan Misra
Software Requirements: Functional and Non-Functional, User requirements, System requirements, Software Requirements Document – Requirement Engineering Process: Feasibility Studies, Requirements elicitation and analysis, requirements validation, requirements management-Classical analysis: Structured system Analysis, Petri Nets- Data Dictionary
This presentation is about a lecture I gave within the "Software systems and services" immigration course at the Gran Sasso Science Institute, L'Aquila (Italy): http://cs.gssi.infn.it/.
http://www.ivanomalavolta.com
This presentation is about a lecture I gave within the "Software systems and services" immigration course at the Gran Sasso Science Institute, L'Aquila (Italy): http://cs.gssi.infn.it/.
http://www.ivanomalavolta.com
In this advanced business analysis training session, you will learn Stakeholder Management. Topics covered in this session are:
• Problem Description
• Stakeholder Management
• Identify your Stakeholders
• Analyze your Stakeholders
• Prioritize your Stakeholders
• Engaging your Stakeholders
• Managing Expectations
For more information, click here: https://www.mindsmapped.com/courses/business-analysis/advanced-business-analyst-training/
In this advanced business analysis training session, you will learn Requirement Planning and Monitoring. Topics covered in this session are:
• Understand requirements risk approach
• Understand the team roles for the project
• Be able to determine requirements activities & planning steps
• Be able to estimate activities & manage the scope
• Be able to manage change to requirements
For more information, click here: https://www.mindsmapped.com/courses/business-analysis/advanced-business-analyst-training/
In this advanced business analysis training session, you will learn OOA and UML. Topics covered in this session are:
• Business Imperatives
• Enterprise Modeling
• Stakehollders
• Value Chains
• Business Processes
• Business Engineering
• System Level Model
• Mapping to Layered Architecture
• Conclusion
For more information, click here: https://www.mindsmapped.com/courses/business-analysis/advanced-business-analyst-training/
In this advanced business analysis training session, you will learn SDLC methodologies. Topics covered in this session are:
• Agile methodology
• Scrum methodology
• Rational Unified Process
• Rapid Prototyping
For more information, click here: https://www.mindsmapped.com/courses/business-analysis/advanced-business-analyst-training/
In this advanced business analysis training session, you will learn Enterprise Analysis. Topics covered in this session are:
• Strategic Planning
• Process and Elements
• Zachman Framework
• POLDAT
• Entity Analysis
• Business Architecture
• Key Stakeholders
• SWOT Analysis
• Cost-Benefit Analysis
For more information, click here: https://www.mindsmapped.com/courses/business-analysis/advanced-business-analyst-training/
In this advanced business analysis training session, you will learn RPA. Topics covered in this session are:
• What is RPA?
• Making Office Productive
• Consequences
• Automation
For more information, click here: https://www.mindsmapped.com/courses/business-analysis/advanced-business-analyst-training/
In this advanced business analysis training session, you will learn Data Analytics Business Intelligence. Topics covered in this session are:
• What is Business Intelligence?
• Data / information / knowledge
• What is Data Analytics?
• What is Business Analytics?
• What is Big Data?
• Types of Data
• Types of Analytics
• What is Business Intelligence?
For more information, click here: https://www.mindsmapped.com/courses/business-analysis/advanced-business-analyst-training/
In this advanced business analysis training session, you will learn User Stories from Scenarios. Topics covered in this session are:
• What is a Use Case?
• The Purpose of Use Case Analysis
• Managing the Building of Product
• The Basic Development Loop
• Analysis paralysis – how much is enough
• Conceptual model development
• Style Guide development
• Usability testing during agile increments
For more information, click here: https://www.mindsmapped.com/courses/business-analysis/advanced-business-analyst-training/
In this advanced business analysis training session, you will learn Use Cases and Its use in Agile World. Topics covered in this session are:
• Requirements Principles
• Identify the principles that lead to effective Agile requirements
• Setting the Stage for Requirements
• Establish the vision as the foundation of Agile requirements
• Levels of Agile Requirements
• Identify the different level of Agile requirements for effective requirements
For more information, click here: https://www.mindsmapped.com/courses/business-analysis/advanced-business-analyst-training/
In this advanced business analysis training session, you will learn Create user story. Topics covered in this session are:
• Create user story
For more information, click here: https://www.mindsmapped.com/courses/business-analysis/advanced-business-analyst-training/
In this advanced business analysis training session, you will learn Requirement Management. Topics covered in this session are:
• Requirements Negotiation And Prioritization
• Requirements Management
• Requirements Traceability
• Requirements Variability and Software/System Product Lines
For more information, click here: https://www.mindsmapped.com/courses/business-analysis/advanced-business-analyst-training/
Essentials of Automations: The Art of Triggers and Actions in FMESafe Software
In this second installment of our Essentials of Automations webinar series, we’ll explore the landscape of triggers and actions, guiding you through the nuances of authoring and adapting workspaces for seamless automations. Gain an understanding of the full spectrum of triggers and actions available in FME, empowering you to enhance your workspaces for efficient automation.
We’ll kick things off by showcasing the most commonly used event-based triggers, introducing you to various automation workflows like manual triggers, schedules, directory watchers, and more. Plus, see how these elements play out in real scenarios.
Whether you’re tweaking your current setup or building from the ground up, this session will arm you with the tools and insights needed to transform your FME usage into a powerhouse of productivity. Join us to discover effective strategies that simplify complex processes, enhancing your productivity and transforming your data management practices with FME. Let’s turn complexity into clarity and make your workspaces work wonders!
GraphRAG is All You need? LLM & Knowledge GraphGuy Korland
Guy Korland, CEO and Co-founder of FalkorDB, will review two articles on the integration of language models with knowledge graphs.
1. Unifying Large Language Models and Knowledge Graphs: A Roadmap.
https://arxiv.org/abs/2306.08302
2. Microsoft Research's GraphRAG paper and a review paper on various uses of knowledge graphs:
https://www.microsoft.com/en-us/research/blog/graphrag-unlocking-llm-discovery-on-narrative-private-data/
UiPath Test Automation using UiPath Test Suite series, part 6DianaGray10
Welcome to UiPath Test Automation using UiPath Test Suite series part 6. In this session, we will cover Test Automation with generative AI and Open AI.
UiPath Test Automation with generative AI and Open AI webinar offers an in-depth exploration of leveraging cutting-edge technologies for test automation within the UiPath platform. Attendees will delve into the integration of generative AI, a test automation solution, with Open AI advanced natural language processing capabilities.
Throughout the session, participants will discover how this synergy empowers testers to automate repetitive tasks, enhance testing accuracy, and expedite the software testing life cycle. Topics covered include the seamless integration process, practical use cases, and the benefits of harnessing AI-driven automation for UiPath testing initiatives. By attending this webinar, testers, and automation professionals can gain valuable insights into harnessing the power of AI to optimize their test automation workflows within the UiPath ecosystem, ultimately driving efficiency and quality in software development processes.
What will you get from this session?
1. Insights into integrating generative AI.
2. Understanding how this integration enhances test automation within the UiPath platform
3. Practical demonstrations
4. Exploration of real-world use cases illustrating the benefits of AI-driven test automation for UiPath
Topics covered:
What is generative AI
Test Automation with generative AI and Open AI.
UiPath integration with generative AI
Speaker:
Deepak Rai, Automation Practice Lead, Boundaryless Group and UiPath MVP
Pushing the limits of ePRTC: 100ns holdover for 100 daysAdtran
At WSTS 2024, Alon Stern explored the topic of parametric holdover and explained how recent research findings can be implemented in real-world PNT networks to achieve 100 nanoseconds of accuracy for up to 100 days.
GDG Cloud Southlake #33: Boule & Rebala: Effective AppSec in SDLC using Deplo...James Anderson
Effective Application Security in Software Delivery lifecycle using Deployment Firewall and DBOM
The modern software delivery process (or the CI/CD process) includes many tools, distributed teams, open-source code, and cloud platforms. Constant focus on speed to release software to market, along with the traditional slow and manual security checks has caused gaps in continuous security as an important piece in the software supply chain. Today organizations feel more susceptible to external and internal cyber threats due to the vast attack surface in their applications supply chain and the lack of end-to-end governance and risk management.
The software team must secure its software delivery process to avoid vulnerability and security breaches. This needs to be achieved with existing tool chains and without extensive rework of the delivery processes. This talk will present strategies and techniques for providing visibility into the true risk of the existing vulnerabilities, preventing the introduction of security issues in the software, resolving vulnerabilities in production environments quickly, and capturing the deployment bill of materials (DBOM).
Speakers:
Bob Boule
Robert Boule is a technology enthusiast with PASSION for technology and making things work along with a knack for helping others understand how things work. He comes with around 20 years of solution engineering experience in application security, software continuous delivery, and SaaS platforms. He is known for his dynamic presentations in CI/CD and application security integrated in software delivery lifecycle.
Gopinath Rebala
Gopinath Rebala is the CTO of OpsMx, where he has overall responsibility for the machine learning and data processing architectures for Secure Software Delivery. Gopi also has a strong connection with our customers, leading design and architecture for strategic implementations. Gopi is a frequent speaker and well-known leader in continuous delivery and integrating security into software delivery.
DevOps and Testing slides at DASA ConnectKari Kakkonen
My and Rik Marselis slides at 30.5.2024 DASA Connect conference. We discuss about what is testing, then what is agile testing and finally what is Testing in DevOps. Finally we had lovely workshop with the participants trying to find out different ways to think about quality and testing in different parts of the DevOps infinity loop.
Generative AI Deep Dive: Advancing from Proof of Concept to ProductionAggregage
Join Maher Hanafi, VP of Engineering at Betterworks, in this new session where he'll share a practical framework to transform Gen AI prototypes into impactful products! He'll delve into the complexities of data collection and management, model selection and optimization, and ensuring security, scalability, and responsible use.
LF Energy Webinar: Electrical Grid Modelling and Simulation Through PowSyBl -...DanBrown980551
Do you want to learn how to model and simulate an electrical network from scratch in under an hour?
Then welcome to this PowSyBl workshop, hosted by Rte, the French Transmission System Operator (TSO)!
During the webinar, you will discover the PowSyBl ecosystem as well as handle and study an electrical network through an interactive Python notebook.
PowSyBl is an open source project hosted by LF Energy, which offers a comprehensive set of features for electrical grid modelling and simulation. Among other advanced features, PowSyBl provides:
- A fully editable and extendable library for grid component modelling;
- Visualization tools to display your network;
- Grid simulation tools, such as power flows, security analyses (with or without remedial actions) and sensitivity analyses;
The framework is mostly written in Java, with a Python binding so that Python developers can access PowSyBl functionalities as well.
What you will learn during the webinar:
- For beginners: discover PowSyBl's functionalities through a quick general presentation and the notebook, without needing any expert coding skills;
- For advanced developers: master the skills to efficiently apply PowSyBl functionalities to your real-world scenarios.
In his public lecture, Christian Timmerer provides insights into the fascinating history of video streaming, starting from its humble beginnings before YouTube to the groundbreaking technologies that now dominate platforms like Netflix and ORF ON. Timmerer also presents provocative contributions of his own that have significantly influenced the industry. He concludes by looking at future challenges and invites the audience to join in a discussion.
Removing Uninteresting Bytes in Software FuzzingAftab Hussain
Imagine a world where software fuzzing, the process of mutating bytes in test seeds to uncover hidden and erroneous program behaviors, becomes faster and more effective. A lot depends on the initial seeds, which can significantly dictate the trajectory of a fuzzing campaign, particularly in terms of how long it takes to uncover interesting behaviour in your code. We introduce DIAR, a technique designed to speedup fuzzing campaigns by pinpointing and eliminating those uninteresting bytes in the seeds. Picture this: instead of wasting valuable resources on meaningless mutations in large, bloated seeds, DIAR removes the unnecessary bytes, streamlining the entire process.
In this work, we equipped AFL, a popular fuzzer, with DIAR and examined two critical Linux libraries -- Libxml's xmllint, a tool for parsing xml documents, and Binutil's readelf, an essential debugging and security analysis command-line tool used to display detailed information about ELF (Executable and Linkable Format). Our preliminary results show that AFL+DIAR does not only discover new paths more quickly but also achieves higher coverage overall. This work thus showcases how starting with lean and optimized seeds can lead to faster, more comprehensive fuzzing campaigns -- and DIAR helps you find such seeds.
- These are slides of the talk given at IEEE International Conference on Software Testing Verification and Validation Workshop, ICSTW 2022.
Maruthi Prithivirajan, Head of ASEAN & IN Solution Architecture, Neo4j
Get an inside look at the latest Neo4j innovations that enable relationship-driven intelligence at scale. Learn more about the newest cloud integrations and product enhancements that make Neo4j an essential choice for developers building apps with interconnected data and generative AI.
Alt. GDG Cloud Southlake #33: Boule & Rebala: Effective AppSec in SDLC using ...James Anderson
Effective Application Security in Software Delivery lifecycle using Deployment Firewall and DBOM
The modern software delivery process (or the CI/CD process) includes many tools, distributed teams, open-source code, and cloud platforms. Constant focus on speed to release software to market, along with the traditional slow and manual security checks has caused gaps in continuous security as an important piece in the software supply chain. Today organizations feel more susceptible to external and internal cyber threats due to the vast attack surface in their applications supply chain and the lack of end-to-end governance and risk management.
The software team must secure its software delivery process to avoid vulnerability and security breaches. This needs to be achieved with existing tool chains and without extensive rework of the delivery processes. This talk will present strategies and techniques for providing visibility into the true risk of the existing vulnerabilities, preventing the introduction of security issues in the software, resolving vulnerabilities in production environments quickly, and capturing the deployment bill of materials (DBOM).
Speakers:
Bob Boule
Robert Boule is a technology enthusiast with PASSION for technology and making things work along with a knack for helping others understand how things work. He comes with around 20 years of solution engineering experience in application security, software continuous delivery, and SaaS platforms. He is known for his dynamic presentations in CI/CD and application security integrated in software delivery lifecycle.
Gopinath Rebala
Gopinath Rebala is the CTO of OpsMx, where he has overall responsibility for the machine learning and data processing architectures for Secure Software Delivery. Gopi also has a strong connection with our customers, leading design and architecture for strategic implementations. Gopi is a frequent speaker and well-known leader in continuous delivery and integrating security into software delivery.
How to Get CNIC Information System with Paksim Ga.pptxdanishmna97
Pakdata Cf is a groundbreaking system designed to streamline and facilitate access to CNIC information. This innovative platform leverages advanced technology to provide users with efficient and secure access to their CNIC details.
GridMate - End to end testing is a critical piece to ensure quality and avoid...ThomasParaiso2
End to end testing is a critical piece to ensure quality and avoid regressions. In this session, we share our journey building an E2E testing pipeline for GridMate components (LWC and Aura) using Cypress, JSForce, FakerJS…
2. 2
Agenda
• Introduction to Requirements Verification and Validation
• Requirements Verification and Validation Techniques
– Simple checks
– Prototyping
– Functional test design
– User manual development
– Reviews and inspections
– Model-based (formal) Verification and Validation
• The software is done. We are just trying to get it to work…1
3. 3
• Requirements Validation
– Check that the right product is being built
– Ensures that the software being
developed (or changed) will satisfy its
stakeholders
– Checks the software requirements specification
against stakeholders goals and requirements
• Requirements Verification
– Check that product is being built right
– Ensures that each step followed in the process of
building the software yields the right products
– Checks consistency of the software requirements
specification artefacts and other software
development products (design, implementation, ...)
against the specification
Requirements Verification and
Validation
4. 4
Requirements Verification and
Validation (2)
• Help ensure delivery of what the client wants
• Need to be performed at every stage during the
(requirements) process
– Elicitation
• Checking back with the elicitation sources
• “So, are you saying that . . . . . ?”
– Analysis
• Checking that the domain description and requirements are
correct
– Specification
• Checking that the defined system requirement will meet the user
requirements under the assumptions of the domain/environment
• Checking conformity to well-formedness rules, standards…
5. 5
The World and the Machine1
(or the problem domain and the system) These 6 slides are taken from Introduction to Analysis
• Validation question (do we build the
right system?) : if the domain-to-be
(excluding the system-to-be) has
the properties D, and the
system-to-be has the properties
S, then the requirements R will
be satisfied.
D and S R
• Verification question (do we build
the system right?) : if the hardware
has the properties H, and the
software has the properties P,
then the system requirements
S will be satisfied.
C and P S
• Conclusion:
D and C and P R
[1] M. Jackson, 1995
problem
domain
interface
solution
system
Hardware (C)
Software (P)
Domain
properties (D)
these are assumptions
about the environment
of the system-to-be
Requirements (R)
Specification (S)
6. 6
Example
• Requirement
– (R) Reverse thrust shall only be enabled
when the aircraft is moving on runway.
• Domain Properties
– (D1) Deploying reverse thrust in mid-flight
has catastrophic effects.
– (D2) Wheel pulses are on if and only if wheels are turning.
– (D3) Wheels are turning if and only if the plane is moving on the
runway.
• System specification
– (S) The system shall allow reverse thrust to be enabled if and only if
wheel pulses are on.
• Does D1 and D2 and D3 and S R?
– Are the domain assumptions (D) right? Are the requirement (R) or
specification (S) what is really needed?
based on P. Heymans, 2005
7. 7
Requirement specifications including
assumptions
• Often the requirements for a system-to-be include
assumptions about the environment of the system.
• The system specification S, then, has the form:
S = A G
where A are the assumptions about the environment and G are the
guarantees that the system will provide as long as A hold.
• If these assumptions (A) are implied by the known
properties of the domain (D), that is D A, and we can
check that the domain properties (D) and the system
guarantees (G) imply the requirements (R), that is D
and G R, then the “validation condition” D and S
R is satisfied.
8. 8
Specification with assumptions and guarantees (example)
Example: A power utility provides electricity to a client.
The problem is that the monthly invoice is not related
to the electricity consumption, because there is no
information about this consumption.
• Idea of a solution: introduce an electricity counter.
• Specification of the electricity counter
– Inputs and outputs
• input power from utility (voltage, current) – voltage supplied by utility
• output power to client (voltage, current) – current used by client
• Reset button (input)
• consumption (output - watt-hours of electricity consumption)
9. 9
Example (suite)
– Assumptions
• Input voltage < 500 Volts (determined by utility)
• Output current < 20 Amps (determined by client)
– Guarantees
• Output voltage = input voltage
• Input current = output current
• Consumption output shall indicate the consumption since the last
reset operation, that is, the integral of (output voltage x output
current) over the time period from the occurrence of the last reset
operation to the current time instant.
• Software example
• Specification of a method providing the interface “List search(Criteria c. Assumption: c
is a data structure satisfying the Criteria class properties. Guarantee: the returned
result is a list satisfying the List class properties and includes all items from the
database that satisfy c.
10. 10
Formal Verification and Validation
• Evaluating the satisfaction of “D and S R” is difficult with natural
language
– Descriptions are verbose, informal, ambiguous, incomplete...
– This represents a risk for the development and organization
• Verification of this “validation question” is more effective with
formal methods (see below)
– Based on mathematically formal syntax and semantics
– Proving can be tool-supported
• Depending on the modeling formalism used, different verification
methods and tools may be applied. We call this “Model-Based
V&V”
– In the case of the aircraft example above, we used Logic to write down
statements about the model. This is a particular case of modeling
formalism.
11. 11
V&V vs. Analysis
• Both have several activities in common
– Reading requirements, problem analysis, meetings and discussions...
• Analysis works with raw, incomplete requirements as elicited from
the system stakeholders
– Develop a software requirements specification document
– Emphasis on "we have the right requirements"
• Requirements V&V works with a software requirements
specification and with negotiated and agreed (and presumably
complete) domain requirements
– Check that this these specifications are accurate
– Emphasis on "we have the right requirements well done"
13. 13
Various Requirements V&V Techniques
• Simple checks
– Traceability, well-written requirements
• Prototyping
• Functional test design
• User manual development
• Reviews and inspections
– Walkthroughs
– Formal inspections
– Checklists
• Model-Based V&V
– First-order logic
– Behavioral models
14. 14
Simple Checks
• Various checks can be done using traceability techniques
– Given the requirements document, verify that all elicitation
notes are covered
– Tracing between different levels of requirements
• Checking goals against tasks, features, requirements…
• Involves developing a traceability matrix
– Ensures that requirements have been taken into consideration
(if not there should be a reason)
– Ensures that everything in the specification is justified
• Verify that the requirements are well written (according to
the criteria already discussed)
15. 15
Prototyping (1)
• Excellent for validation by users and customers
– More accessible than specification
– Demonstrate the requirements and help stakeholders
discover problems
• Come in all different shapes and sizes
– From paper prototype of a computerized system to
formal executable models/specifications
– Horizontal, vertical
– Evolutive, throwaway
16. 16
Prototyping (2)
• Important to choose scenarios or use cases for
elicitation session
• Prototyping-based validation steps
– Choose prototype testers
– Develop test scenarios
• Careful planning is required to draw up a set of test scenarios
which provide broad coverage of the requirements
• Users should not just play around with the system as this may
never exercise critical system features
– Execute test scenarios
– Document problems using a problem reporting tool
17. 17
Comment on next two techniques
• The two V&V techniques, namely Functional
Test Design and User Manual Development,
are not really V&V techniques.
• They are activities that must be performed
anyway, and they are based on the
specification document.
– Through these activities, as for any other activities
based on the specification document, errors and
other problems with this document may be
detected.
18. 18
Functional Test Design
• Functional tests at the system level must be developed sooner or
later...
– Can (and should) be derived from the requirements specification
– Each (functional) requirement should have an associated test
– Non-functional (e.g., reliability) or exclusive (e.g., define what should
not happen) requirements are harder to validate with testing
– Each requirements test case must be traced to its requirements
– Inventing requirements tests is an effective validation technique
• Designing these tests may reveal errors in the specification (even
before designing and building the system)!
– Missing or ambiguous information in the requirements description
may make it difficult to formulate tests
• Some software development processes (e.g., agile methods) begin
with tests before programming Test-Driven Development (TDD)
19. 19
User Manual Development
• Same reasoning as for functional test design
– Has to be done at some point
– Reveals problems earlier
• Forces a detailed look at requirements
• Particularly useful if the application is rich in user
interfaces / for usability requirements
• Typical information in a user manual
– Description of the functionality
– How to get out of trouble
– How to install and get started with the system
20. 20
Reviews and Inspections (1)
• A group of people read and analyze requirements, look for
potential problems, meet to discuss the problems, and
agree on a list of action items needed to address these
problems
• A widely used requirements validation technique
– Lots of evidence of effectiveness of the technique
• Can be expensive
– Careful planning and preparation
– Pre-review checking
– Need appropriate checklists (must be developed if necessary
and maintained)
21. 21
Reviews and Inspections (2)
• Different types of reviews with varying degrees of formality
exist (similar to JAD vs. brainstorming sessions)
– Reading the document
• A person other than the author of the document
– Reading and approval (sign-off)
• Encourages the reader to be more careful (and responsible)
– Walkthroughs
• Informal, often high-level overview
• Can be led by author/expert to educate others on his/her work
– Formal inspections
• Very structured and detailed review, defined roles for participants,
preparation is needed, exit conditions are defined
• E.g., Fagan Inspection
22. 22
Reviews and Inspections (3)
• Different types of reviews (cont’d)
– Focused inspections
• Reviewers have roles, each reviewer looks only for
specific types of errors
– Active reviews
• Author asks reviewer questions which can only be
answered with the help of the document to be
reviewed
23. 23
Typical Review / Inspection Steps (1)
• Plan review
– The review team is selected and a time and place for the review meeting is
chosen
• Distribute documents
– The requirements document is distributed to the review team members
24. 24
Typical Review / Inspection Steps (2)
• Prepare for review
– Individual reviewers read the requirements to find conflicts, omissions,
inconsistencies, deviations from standards, and other problems
• Hold review meeting
– Individual comments and problems are discussed and a set of action items to
address the problems is established
25. 25
Typical Review / Inspection Steps (3)
• Follow-up actions
– The chair of the review checks that the agreed action items have been carried
out
• Revise document
– Requirements document is revised to reflect the agreed action items
– At this stage, it may be accepted or it may be re-reviewed
26. 26
Review Team
• Reviews should involve a number of
stakeholders drawn from different
backgrounds
– People from different backgrounds bring different
skills and knowledge to the review
– Stakeholders feel involved in the RE process and
develop an understanding of the needs of other
stakeholders
– Review team should always involve at least a
domain expert and a user
27. 27
Review – Problem Categorization
• Requirements clarification
– The requirement may be badly expressed or may have accidentally
omitted information which has been collected during requirements
elicitation
• Missing information
– Some information is missing from the requirements document
• Requirements conflict
– There is a significant conflict between requirements
– The stakeholders involved must negotiate to resolve the conflict
• Unrealistic requirement
– The requirement does not appear to be implementable with the
technology available or given other constraints on the system
– Stakeholders must be consulted to decide how to make the
requirement more realistic
28. 28
Pre-Review Checking
• Reviews can be expensive because they involve many people over several
hours reading and checking the requirements document
• We can reduce this cost by asking someone to make a first pass called the
pre-review
– Check the document and look for straightforward problems such as
missing requirements (sections), lack of conformance to standards,
typographical errors, etc.
29. 29
Fagan Inspection (1)
• Formal and structured inspection process
Note: the boss is not
involved in the process!
30. 30
Fagan Inspection (2)
• Characterized by rules on who should participate, how
many reviewers should participate, and what roles they
should play
– Not more than 2 hours at a time, to keep participants focused
– 3 to 5 reviewers
– Author serves as the presenter of the document
– Metrics are collected
• Important: the author’s supervisor does not participate in the
inspection and does not have access to data
• This is not an employee evaluation
– Moderator is responsible for initiating the inspection, leading
the meeting, and ensuring issues found are fixed
– All reviewers need to prepare themselves using checklists
– Issues are recorded in special forms
31. 31
Fagan Inspection (3)
• The inspection meeting is like a brainstorming
session to identify (potential) problems
• Re-inspection if > 5% of the document change
– Some variants are less tolerant... too easy to
introduce new errors when correcting the
previous ones!
32. 32
Active Review
• Reviewer is asked to use the specification
• Author poses questions for the reviewer
to answer that can be answered only by
reading the document
• Author may also ask reviewer to simulate
a set of scenarios
33. 33
Requirements Review Checklists (1)
• Essential tool for an effective review process
– List common problem areas and guide reviewers
– May include questions an several quality aspects of the
document: comprehensibility, redundancy, completeness,
ambiguity, consistency, organization, standards
compliance, traceability ...
• There are general checklists and checklists for
particular modeling and specification languages
• Checklists are supposed to be developed and
maintained
• See example on course website
34. 34
Requirements Review Checklists (2)
• Sample of elements in a requirements review checklist
– Comprehensibility – can readers of the document understand
what the requirements mean?
– Redundancy – is information unnecessarily repeated in the
requirements document?
– Completeness – does the checker know of any missing
requirements or is there any information missing from individual
requirement descriptions?
– Ambiguity – are the requirements expressed using terms which
are clearly defined? Could readers from different backgrounds
make different interpretations of the requirements?
– Consistency – do the descriptions of different requirements
include contradictions? Are there contradictions between
individual requirements and overall system requirements?
35. 35
Requirements Review Checklists (3)
• Sample of elements (cont’d)
– Organisation – is the document structured in a
sensible way? Are the descriptions of requirements
organised so that related requirements are grouped?
– Conformance to standards – does the requirements
document and individual requirements conform to
defined standards? Are departures from the standards
justified?
– Traceability – are requirements unambiguously
identified? Do they include links to related
requirements and to the reasons why these
requirements have been included?
36. 36
Comments on Reviews and Inspections
• Advantages
– Effective (even after considering cost)
– Allow finding sources of errors (not only symptoms)
– Requirements authors are more attentive when they know their work
will be closely reviewed
• Encourage them to conform to standards
– Familiarize large groups with the requirements (buy-in)
– Diffusion of knowledge
• Risks
– Reviews can be dull and draining (need to be limited in time)
– Time consuming and expensive (but usually cheaper than the
alternative)
– Personality problems
– Office politics…
38. 38
The problem domain and the system– copied from Introduction to Analysis
and Specification
• Validation question (do we build the
right system?) : if the domain-to-be
(excluding the system-to-be) has
the properties D, and the
system-to-be has the properties
S, then the requirements R will
be satisfied.
D and S R
• Verification question (do we build
the system right?) : if the hardware
has the properties H, and the
software has the properties P,
then the system requirements
S will be satisfied.
C and P S
• Conclusion:
D and C and P R
[1] M. Jackson, 1995
problem
domain
interface
solution
system
Hardware (C)
Software (P)
Domain
properties (D)
these are assumptions
about the environment
of the system-to-be
Requirements (R)
Specification (S)
39. 39
Modeling paradigms
• Modeling paradigms
– Entity-Relationship modeling – e.g. UML Class diagrams
– Workflow modeling notations – there are many different
“dialects”, such as UML Activity diagrams, UCM, BPML, Petri
nets (a very simple formal model), Colored Petri nets
– State machines – e.g. Finite State Machines (FSM – a very simple
formal model), extended FSMs, such as UML State diagrams
– First-order logic – notations such as Z, VDM, UML-OCL, etc.
• Can be used as an add-on with the other paradigms above, by
providing information about data objects and relationships (possibly in
the form of “assertions” or “invariants” that hold at certain points
during the dynamic execution of the model)
• Can be used alone, expressing structural models and behavioral
models (there are many examples of using Z for such purpose)
40. 40
Formal V&V techniques and tools (i)
• Available V&V techniques will vary from one modeling
paradigms to another and will also depend on the available
tools (that usually only apply to a particular “dialect” of the modeling paradigm)
• The following functions may be provided through tools
– Completeness checking – only according to certain syntax rules, templates
– Consistency checking : given model M, show that M does not imply a contradiction
and does not have any other undesirable general property (e.g. deadlock possibility)
– Refinement checking : given two models M and M’, show that the properties of M imply
the properties of M’. This can be used for the validation of the system specification S, that is, showing
that D and S R where D are the domain properties and R are the domain requirements (M = D
and S; M’ = R)
– Model checking : given a model M and some properties P, show that any system
implementation satisfying M will have the properties P
– Generation of system designs or prototype implementations (from
workflow or state machine models)
– Generation of test cases
– Performance evaluation
41. 41
Formal V&V techniques and tools (ii)
• Consistency and Refinement checking
– Logic models
• Theorem proving
– Workflow and State machine models
• Simulated execution (prototype implementations)
• Reachability analysis (determining all reachable states of a system
consisting of a composition of several state machines, or of a
workflow model). In contrast, simulated execution will only perform partial
analysis – namely a certain number of test cases (note: one may consider a very
large number of such cases, possibly randomly generated).
42. 42
Consistency checking for state
machines
– Different types of refinements
• Refinement (also called Conformance) between two machines (for
example, one abstract and the other one more concrete)
• Reduction of non-determinism
• Reduction of optional behavior (compliant, but some behaviors
are not supported)
• Extension (conformance, but some new events are treated and
lead to new behaviors)
– Equivalence checking
• Between two machines (for example, one abstract and the other
one more concrete)
• Several types of equivalence: trace equivalence (same traces of
events can be observed), refusal equivalence (same blocking
behavior), observational equivalence (equivalent states in both
machines), etc.
43. 43
Formal V&V techniques and tools (iii)
• Model checking: Is normally used for behavioral
workflow and state machine models (however, the
Alloy tool can also be used for checking structural Class
diagram models).
– Uses the approach of reachability analysis
– The typical properties to be verified for a given model could be the
following (note: can also be checked by simulated execution):
• General properties (to be satisfied by most systems):
– Absence of deadlocks in a system with concurrency
– No non-specified messages, that is, for all events that may occur their handling is
defined
– All states can be reached and all transitions can be traversed
• Specific properties (depending on this particular system): Such specific
properties must be specified in some suitable notation, such as
– Logic assertions or invariants
– Temporal logic (extension of predicate calculus with two operators: always and
eventually (corresponding to Maintain/Avoid goals and Achieve goals, respectively)
44. 44
Different types of goals – copied from Goal-oriented
modeling
• Behavioral goal: establishment of goal can be checked
– Describes intended behavior declaratively
– Implicitly defines a maximal set of admissible behaviors
• Achieve: points to future (like “eventually” operator in Temporal Logic)
• Maintain/Avoid: states property that always holds (like “always”
operator)
• Soft-Goal: are more or less fulfilled by different alternatives
of (external) design – often difficult to quantify – one says,
some alternative may “satisfice” the goal
45. 45
Model checking
– Verifies that the model satisfies temporal logic
properties, for example:
• If A occurs, B will occur in the future (eventually)
• If C occurs, D will be true always in the future
– Traverse systematically all possible behaviors
(execution paths) of the machine (reachability
analysis)
• Verification of properties done after reachability
analysis or on the fly
– Model checker verifies M P (if no trace of states and transitions
leading to the violation of P is found) – otherwise a counter example
trace is provided
– Major obstacle is state space explosion
Example tools:
SPIN (see http://spinroot.com/spin/whatispin.html ) - for distributed systems with message passing
Alloy (see http://alloy.mit.edu/community/ ) – for OO Class diagrams with assertions
47. 47
Performance Analysis
Different approaches to performance analysis
– Informal: Qualitative analysis with GRL strategies
– Counting the number of messages involved: e.g.
transformations of workflow scenarios into
sequence diagrams
– Model-based performance evaluation
• Queuing models : consider resources, service times and
request queuing
• Markov models : consider transition probabilities of
state machine models
48. 48
Performance modeling : Markov models
Markov models
– State machine model where each transition has a given rate
of occurrence; this leads to an exponential distribution of
the sejourn time in a given state.
– This modeling paradigm is often used for modeling
reliability, availability etc.
– Example: Machine may be operational or failed. In the
operational state, the rate of the failing transition is 0.001
per hour, in the failed state, the rate of the repaired
transition (back to the operational state) is 1.0 per hour
(the machine remains in the failed state a duration that has
an exponential distribution with average 1 hour).
49. 49
Performance modeling : Queuing models
Queuing models
– One considers: user requests, resources (servers), service times (for processing requests
by resources) and request queuing
– One talks about queueing networks – a kind of workflow model involving several
resources providing various services and requests that flow between resources (closed
system: users are also modeled as resources – open system: users are outside the
“system”)
– The performance of workflow models (UML Activity diagrams or UCMs) can be naturally
modeled by queueing networks.
• The jUCMNav provides for the automatic transformation into such a model using an
intermediate representation called Core Senario Model (CSM)
– The functional workflow model must be complemented with performance parameters
in order to provide the necessary input data for performance modeling. This includes:
• Performance data on resources: e.g. service times, queuing disciplines, etc.
• Performance data on work load: e.g. number of requests per unit time, etc.
50. 50
Performance evaluation tools
• For both, Markov and Queuing models, there are two
basic approaches to performance evaluation:
– Analytical formulas
– Simulation studies
• Special versions of modeling paradigms
– Layered Queuing Networks (LQN - using several layers of
abstraction, like layered operating system functions) –
developed by Dr. Woodside at Carleton University
– Stochastic Petri nets (Markov’s rate-based transitions
applied to Petri nets)
51. 51
Typical Performance Results from
Queuing models
• General statistics
– Elapsed time, system time…
• Measured quantities
– Service demands, number of blocking and non-blocking
calls, call delays, synchronization delays
• Service times
– For every entry and activity, with confidence intervals and
variances (where relevant)
• Throughputs and utilizations for every entry and
activity, with confidence intervals
• Utilizations and waiting times for devices (by entry)
52. 52
• Automated translation to Core Scenario Model (CSM) for analytical
evaluations and simulations
Security E_Accountant
Ready
ContinueCheckBio
TaxPayer
Access
Resource Characteristics
• Passive/active, external operations
• Disks, processors, …
• Operation time
• Multiplicity
Rejected
Workload
Characteristics
• Poisson, periodic…
• Population size
• Open/closed
Responsibilities
• Host demand
• External op. demands
• Multiplicity
OR Forks and
Dynamic Stubs
• Probability
Components
• Allocated responsibilities
• Resource assignment
e.g. Performance Annotations for UCMs (Use Case
Maps)
55. 55
From UCM to Core Scenario Model
(CSM)
• Export CSM (XML) from URN model
• Translation of CSM file to LQN, QN, stochastic Petri Nets…
56. 56
LQN (Layered Queuing Network)
Generation from UCMs (2)
• Useful for various types of analyses
– Sensitivity (importance or impact
of parameters)
– Scalability (what if there are
more users/requests?)
– Concurrency (what if there are
more/fewer threads?)
– Deployment and configuration
(different hardware allocation)
• Quantitative evaluation of
architecture!
Source: D.B. Petriu et al., 2003
58. 58
Model-based testing
• Behavioral models can be used for
– Deriving test cases
– Providing an oracle that predicts the correct output expected for
given inputs. (However: if the behavioral model is non-
deterministic – for a given input there may be different outputs
– then this is quite difficult)
• This is black-box testing – the system implementation
under test is observed only at its external interfaces – no
internal view
• Test cases – two complementary coverage issues
– Covering different control flows through the behavior
– Covering different data parameter values
– Question of executability of given control flow path with given
data parameters
59. 59
Coverage issues for black-box testing
• Issues of control flow coverage
– All branches of the behavioral model will be exercised
at least once
• E.g. so-called transition tour for FSM model
– All paths … (leads normally to too many test cases)
– Covering all faults – one needs a fault model
• Fault model for FSMs:
– Output faults (wrong output produced): will be detected by
transition tour
– Transfer faults (wrong next state): difficult to detect - either
introduce state visibiility, or use so-called state identification test
sequences
60. 60
Automating test development from
models ?
• FSM models:
– There has been much work on deriving test suites
(sets of test cases) from FSM models (for different
coverage criteria)
• UCM models:
– Deriving sequence diagram (test case – without data)
for each scenario that can be realized from the given
UCM
– Automatic generation of scenarios and corresponding
test cases (see next page)
62. 62
The problem
Service2
Service1
Service3
C 1 C 2 C 3 C 4
Service models
Design models
Implementations
S1.1 S1.2
Design synthesis
Code generation
Service2
Service1
Service3
C 1 C 2 C 3 C 4
Service models
Design models
Implementations
S1.1 S1.2
Design synthesis
Code generation
63. 63
Type of applications
• Communication services
– telephony features (e.g. call waiting)
– teleconference involving many parties
– Social networking
• Workflows
– Intra-organization, e.g. banking application, manufacturing
– inter-organisations, e.g. supply-chain management
– Different underlying technologies:
• Web Services
• GRID computing
• Cloud computing
– Dynamic partner selection: negotiation of QoS – possibly involving several exchanges
64. 64
The problem
(early phase of the software development process)
• Define
– Global functional requirements
– Non-functional requirements
• Make high-level architectural choices
– Identify system components
– Define underlying communication service
• Define behavior of system components:
– Locally performed functions
– Communication protocol
• Required messages to be exchanged and order of exchanges
• Coding of message types and parameters
65. 65
Issues
• Define
– Global functional
requirements
– Non-functional requirements
• Make high-level architectural
choices
– Identify system components
– Define underlying
communication service
• Define behavior of system
components
– Local functions
– Protocol:
• Required messages to be
exchanged and order of
exchanges
• Coding of message types
and parameters
What language / notation to use for defining global
requirements (dynamic behavior)
Architectural choices have strong impact on performance
Automatic derivation of component behaviors ? e.g.
[Bochmann 2007]
Performance prediction – based on component behavior
• Response time, Throughput, Reliability
Choice of middleware platform for inter-process
communication
• E.g. Java RMI, Web Services, etc.
66. 66
Example: Taxi system (an activity diagram - each activity is a collaboration between several roles: client, taxi, manager)
new client C
Request Free
Assign
Meet
Pick-up
Drive
Pay
FreeWithdraw
new taxi T
taxi leaves
client leaves
client
leaves
T
T
T
T
T
T
T
T
T
C
C
C C
M
C
M
M
M
M
M
M : taxi manager
initiating role
terminating
roles
Off-duty
67. 67
Taxi System
Detailed definitions of collaborations
req
C M
Request
meet
Drive
OK
CM
Meet
T
drive
OK
C T
assign
C
Assign
T
assign
M
assign
C T
assign
req
free
meet
OK
drivepay
OK
off-duty
Example scenario
(sequence diagram)
68. 68
Taxi System : Problematic scenarios
M
assign
C T
assign
req
free
non-local
choice
[Gouda 84] suggests:
define different priorities
for different roles
M
assign
C T
assign
req
free
meet
with-
draw
race
condition
M
assign
C1 T
assign
req
free
C2
pick-up
non-local
Choice
(conflict over taxi)
“implied scenario”:
[Alur 2000] component behaviors
that realize the normal scenario
will also give rise to implied scenarios
70. 70
Code generation from behavioral models
This has been explored in research projects since the 1980s
for extended FSM languages and commercial tools have
been around since the 1990s, in particular for SDL,
Statecharts and other notations – now also for UML State
machines.