Software Engineering, Requirements Engineering and Testing Training Course

Course Outline

Software Engineering 5 days

Day 1: Project Management

  • Project versus line management and maintenance and support
  • Project definition and project forms
  • Management – general rules and project management
  • Management styles
  • What is special for IT projects?
  • Basic project process
  • Iterative, incremental, waterfall, agile and lean project process
  • Project phases
  • Project roles
  • Project documentation and other artefacts
  • Soft factors and peopleware
  • PRINCE 2, PMBOK, PMI, IPMA and other project standards

Day 2: Business Analysis and Requirements Engineering Fundamentals

  • Defining business goals
  • Business analysis, business process management, business process improvement
  • The boundary between business and system analysis
  • System stakeholders, system users, system context and system boudaries
  • Why are requirements necessary?
  • What us requirements engineering
  • The boundary between requirements engineering and architectural design
  • Where is requirements engineering often hidden?
  • Requirements engineering in iterative, lean, and agile development and in continuous integration – FDD, DDD, BDD, TDD
  • Basic requirements engineering process, roles and artefacts
  • Standards and certifications: BABOK, ISO/IEEE 29148, IREB, BCS, IIBA

Day 3: Architecture and Development Fundamentals

  • Programming languages – structural and object-oriented paradigms
  • Object-oriented development – how much is history, how much is the future
  • Modularity, portability, maintainability and scalability of architectures
  • Definition and type of software architectures
  • Enterprise architecture and system architecture
  • Programming styles
  • Programming environments
  • Programming mistakes and how to avoid and prevent them
  • Modelling architecture and components
  • SOA, Web Services and micro-services
  • Automatic build and continuous integration
  • How much architecture design is there on a project?
  • Extreme programming, TDD and re-factoring

Day 4: Quality Assurance and Testing Fundamentals

  • Product quality: what is it? ISO 25010, FURPS etc.
  • Product quality, user experience, Kano Model, customer experience management and integral quality
  • User-centred design, personas and other ways to make quality individual
  • Just-enough quality
  • Quality Assurance and Quality Control
  • Risk strategies in quality control
  • The components of quality assurance: requirements, process control, configuration and change management, verification, validation, testing, static testing and static analysis
  • Risk-based quality assurance
  • Risk-based testing
  • Risk-driven development
  • Boehm’s curve in quality assurance and in testing
  • The four testing schools – which suits your need?

Day 5: Process Types, Maturity and Process Improvement

  • The evolution of IT process: from Alan Turing through Big Blue to lean startup
  • Process and process-oriented organization
  • The history of processes in crafts and industries
  • Process modelling: UML, BPMN and more
  • Process management, process optimization, process re-engineering and process management systems
  • Innovative process approaches: Deming, Juran, TPS, Kaizen
  • Is (process) quality free? (Philip Crosby)
  • The need and history of maturity improvement: CMMI, SPICE and other maturity scales
  • Special types of maturity: TMM, TPI (for testing), Requirements Engineering Maturity (Gorschek)
  • Process maturity versus product maturity: any correlation? Any causal relationship?
  • Process maturity versus business success: any correlation? any causal relationship?
  • A forsaken lesson: Automated Defect Prevention and The Next Leap in Productivity
  • Attempts: TQM, SixSigma, agile retrospectives, process frameworks

Requirements Engineering – 2 days

Day 1: Requirements Elicitation, Negotiation, Consolidation and Management

  • Finding requirements: what, when and by whom
  • Stakeholder classification
  • Forgotten stakeholders
  • Defining system context – defining requirements sources
  • Elicitation methods and techniques
  • Prototyping, personas, and requirements elicitation through testing (exploratory and otherwise)
  • Marketing and requirements elicitation – MDRA (“Market-Driven Requirements Engineering”)
  • Prioritising requirements: MoSCoW, Karl Wiegers and other techniques (including agile MMF)
  • Refining requirements – agile “specification by example”
  • Requirements negotiation: types of conflicts, conflict-solving methods
  • Solving internal incongruence between some types of requirements (e.g. security versus ease of use)
  • Requirements traceability – why and how
  • Requirements status changes
  • Requirements CCM, versioning and baselines
  • Product view and project view on requirements
  • Product management and requirements management in projects

Day 2: Requirements Analysis, Modelling, Specification, Verification and Validation

  • Analysis is the thinking and re-thinking you do between elicitation and specification
  • Requirements process is always iterative, even in sequential projects
  • Describing requirements in natural language: risks and benefits
  • Requirements modelling: benefits and costs
  • The rules for using natural language for requirements specification
  • Defining and managing requirements glossary
  • UML, BPMN and other formal and semi-formal modelling notations for requirements
  • Using document and sentence templates for requirements description
  • Verification of requirements – goals, levels and methods
  • Validation – with prototyping, reviews and inspections, and testing
  • Requirements validation and system validation

Testing – 2 days

Day 1: Test Design, Test Execution and Exploratory Testing

  • Test design: after risk-based testing, choosing the optimum way to use the time and resources available
  • Test design “from infinity to here” – exhaustive testing is not possible
  • Test cases and test scenarios
  • Test design on various test levels (from unit to system test level)
  • Test design for static and for dynamic testing
  • Business-oriented and technique-oriented test design (“black-box” and “white-box”)
  • Attempting to break the system (“negative testing”) and supporting the developers (acceptance testing)
  • Test design to achieve test coverage – various test coverage measures
  • Experience-based test design
  • Designing test cases from requirements and system models
  • Test design heuristics and exploratory testing
  • When to design test cases? – traditional and exploratory approach
  • Describing test cases – how much detail?
  • Test execution – psychological aspects
  • Test execution – logging and reporting
  • Designing tests for “non-functional” testing
  • Automatic test design and MBT (Model-Based Testing)

Day 2: Test Organization, Management and Automation

  • Test levels (or phases)
  • Who does the testing, and when? – various solutions
  • Test environments: cost, administration, access, responsibility
  • Simulators, emulators and virtual test environment
  • Testing in agile scrum
  • Test team organization and role
  • Test process
  • Test automation – what can be automated?
  • Test execution automation – approaches and tools

Object Oriented Design using Design Patterns Training Course


  • What is the System Analysis and Design Process?
  • Place of the Analysis and Design activities in the Unified Process (RUP)
  • A panorama of UML 2 diagrams used in the system analysis and design
  • Frameworks for tracing requirements toward software implementation and tests

How to transform requirements into component based analysis specifications?

  • Traceability between requirements and system analysis
  • Advanced notions for representing the system structure and dynamics
  • Refinement of the requirements on both axis
  • Toward the system design using operation contracts
  • Case Study : Definition of the analysis component model of the system

How to transform analysis specifications into design level ones?

  • Traceability between system analysis and design
  • Design Patterns for loose coupling and high cohesion of components
  • Definition of the Design level Architectural Backbone of the system (components, ports, interfaces, exchange objects)
  • Design level interaction diagrams to implement operation contracts
  • Case Study : Updating design level component diagram with architectural choices

Implementing technical specifications and testing on a component basis

  • Generating design level specifications into an object oriented programming language
  • Deployment of Components on the Physical Nodes
  • Integration and Acceptance tests on the basis of the previous specifications


  • Steps of the system analysis and design processes
  • Patterns for ensuring traceability between requirements and the software code
  • Testing requirements on the system architecture

Notice: The above training-mentoring sessions are conducted interactively using Requirement Engineering and Modeling tools in order to ensure good level of traceability between requirements and underlying solutions. Concepts are explained first using basic examples and are then followed by solution drafts to your own issues. After this session, we can accompany you by reviewing and validating your solutions depending on your needs.

Programming with Python All in One

basic programming skills

computer science concept

python programming language

problem solving – put everything together with software


  • High school mathematics and physics.


Programming is one aspect of computer science and software engineering. The primary goal of this course is to build a solid foundation of programming knowledge and skills. With what learned in this course, the students should find it is easier to learn more advanced concepts in computer science.

Not everyone will be or want to be a software engineer, however, this course can help them realize how a problem can be solved by using computer program; how Python can help scientists and engineers improve their productivity.

Believe or not, software developers usually join a product development from the very beginning to the very end. (while this is not true for mechanical engineers or electrical engineers). Most importantly, sometimes, updating software is the better solution to fix or improve a product.

The teaching can be viewed as a vehicle to help students develop problem solving skills. This course will use some mathematics or physics, but it is not a math or physics course, and we use them in programming to re-enforce the learning in those fields.

At the end of this course, It would be a great achievement for the students and me when they find they are able to learn some other programming languages or computer science topics not taught in this course by themselves

Who this course is for:

  • High school students who are thinking CS as their major.
  • College non-cs major students
  • Anyone

Course content