Model Based Requirements Engineering, MBRE Training
Model Based Systems Engineering (MBRE) training course provides you with a good knowledge and understanding of the Model Based Systems Engineering (MBRE) and modeling techniques applied to requirements engineering and management. The MBRE course is impartial to tools and vendors. It encompasses a broad range of concepts rather than focusing on any specific tool.
Model Based Requirements Engineering in a digital-modeling environment provides advantages that document-based systems engineering cannot provide.
Model Based Requirements Engineering, MBRE Training
Requirements modeling in systems and software engineering identifies the requirements that a software application or system must meet in order to solve the business problem.
Requirements are divided into functional (what the system will have to do) and non-functional (constraints within which the system will have to perform).
A functional requirement specifies something that the application or system should do. Often, this is defined as a behavior of the system that takes input and provides output. For example, a traveler fills out a form in an airline’s mobile application with his/her name and passport details (input), submits the form, and the application generates a boarding pass with the traveler’s details (output).
Non-functional requirements, sometimes also called quality requirements, describe how the system should be, as opposed to what it should do. Non-functional requirements of a system include performance (e.g., response time), maintainability and scalability, among many others. In the airline application example, the requirement that the application must display the boarding pass after a maximum of five seconds from the time the traveler presses the ‘submit’ button would be a non-functional requirement.
Advantages of model based requirements engineering have led to increased and growing adoption since MBSE can save costs by reducing development time and improve the ability to produce secure and correctly functioning software.
Although various types of requirements can be represented in the model, there are three main types:
- Business requirements: High-level statements of the goals, objectives, or needs of an organization. They usually describe opportunities or problems that pertain to the organization.
- User requirements: Mid-level statements of the needs of a particular stakeholder or group of stakeholders. They usually describe how someone wants to interact with the intended solution. User requirements are often situated midway between the high-level business requirements and more detailed solution requirements.
- System requirements: Usually detailed statements of capabilities, behavior, and information that the solution will need including detailed statements of the conditions under which the solution must remain effective, qualities that the solution must have, or constraints within which it must operate. System requirements include non-functional requirements, often called quality attributes or “ilities,” such as security, usability, testability and modifiability.
MBSE with SysML offers the generic element type requirement, as well as subclasses: business requirement, usability requirement, functional requirement, performance requirement, interface requirement, physical requirement, and design constraint.
There are no strict rules on whether to use different types of requirements. All requirements can be modeled as a generic requirement type. Alternatively, sophisticated models can be created by using all offered types and even adding customized types.
Model Based Requirements Engineering Course Specifics
Model Based Requirements Engineering training introduces you to model-based requirements engineering and management by providing various perspectives that shaped the fundamentals and principals of this technique. Such perspectives consider each requirement one by one in regard to its definition, but then also give meaning to each requirement by positioning it into the proper “context.”
The requirement being put into a context is known as a “use case.” It is put based on either the stakeholders or levels of hierarchy in a system. Then, every use case must be evaluated and validated by a series of scenarios and official mathematical and logic-based verifications that deliver the precision necessary for safety-critical and mission-critical systems.
Model-based requirements engineering training also discusses the important question of modeling notations for requirements modeling and it includes the use and application of UML, SysML, text and tabular formats.
Model-based requirements engineering training also covers all the key factors of Model-Based requirements engineering including concepts, modeling, structures and exercises.
Tonex Training Feature
Model-based requirements engineering training is a combination of interactive lectures and practical exercises.
Added Value of the Training
- Enhanced systems engineering by using MBSE approach
- How to accomplish more effective communication, improved understanding, and how to reduce complication by modeling
- How to present the advantages of MBSE and their relevant significance to stakeholders within the organization
- Greater self-assurance for you, your teams, your business and your clients
Learn About:
- Systems Engineering (SE), Model-Based Systems Engineering (MBSE) and Digital Engineering
- Requirements engineering and requirements management
- Requirements modeling
- Context-based modeling
- A framework for requirements modeling
- Modeling requirements in UML
- Requirement model traceability
- Non-functional software requirements
- Requirements in SysML
- Using formal methods
- The need for an efficient technique to requirements modeling
- The main visions that build a model-based method, including the meta-model and what contains each view
- How to model individual requirements and use cases
- How to arrange and manage requirements, including traceability and automation
Audience
- System engineers
- Requirements engineers
- System managers
- Software engineers
- Test engineers
Learning objectives
Upon the completion of model-based requirements engineering training, the attendees are able to:
- Understand and describe the principles and concepts of requirements engineering and management
- Apply a systematic method to modeling requirements in a model-based systems engineering (MBSE) environment
- Make a decision as to which level of rigour and relevant techniques is suitable for them
- Explain the concept of MBSE, and how it compares to traditional systems engineering
- Discuss the advantages of MBSE
- Apply MBSE in their industry
- Understand how SysML supports MBSE
- Offer various ways their organization can apply a systems modeling tool to construct systems models
- Apply MBSE methods to specify and design systems
- Transition an organization to MBSE
- Determine and explain the use of SysML™ diagrams
- Apply a formal approach to create a system model in a modeling tool
- Use an activity diagram to model system behavior
- Use a state diagram to model system behavior
- Use a sequence diagram to model system behavior
- Use a requirements diagram to model requirements
- Use a use case diagram to model requirements
- Use block diagrams to model structure
- Assign behavior to framework in a model
- Identify parametric and restraints and describe their application
Course Outline
Overview of Systems Engineering, MBSE/SysML and Model-Based Requirements Engineering (MBRE)
- Requirements engineering definition
- Fundamentals of communication theory
- Characteristics of a requirements engineer
- Requirement types
- Importance and categorization of quality requirements
System and Context Boundaries
- System context
- Defining system and context boundaries
- Defining the system boundary
- Defining the context boundary
- Documenting the system context
Eliciting Requirements
- Requirements sources
- Stakeholders and their roles
- Managing stakeholders in the project
- Requirements classification based on the Kano model
- Elicitation techniques
- Types of elicitation methods
- Survey techniques
- Creativity techniques
- Document-based techniques
- Observation techniques
- Support techniques
Documenting Requirements in Traditional Systems Engineering (SE)
- Document design
- Types of documentation
- The three views of requirements
- Requirements documentation using natural language
- Requirements documentation using conceptual models
- Hybrid requirements documents
- Document framework
- Standardized document structures
- Customized standard contents
- Introduction
- General view
- Requirements
- Appendices
- Using requirements documents
- Quality standards for requirements documents
- Unambiguity and consistency
- Clear structure
- Modifiability and extendibility
- Completeness
- Traceability
- Quality standard for requirements
- Documenting requirements in natural language
- Impacts of natural language
- Nominalization
- Nouns without reference Index
- Universal measurements
- Incompletely specified conditions
- Incompletely specified process verbs
- Requirement construction using templates
- Identify the legal obligation
- The requirement core
- Recognize the activity of a system
- Enter objects
- Identify logical and temporal conditions
Model-Based Requirements Documentation and Modeling
- The term model
- Properties of models
- Modeling languages
- Requirements models
- Advantages of requirements models
- Combined use of models and natural language
- Goal models
- Goal documentation using and/or trees
- Example of and/or trees
- Use Cases
- UML Use Case diagrams
- Modeling elements of UML Use Case diagrams
- Example of UML Use Case diagrams
- Use Case requirements
- Three perspectives on the requirements
- Requirements modeling in the data perspective
- Entity-relationship diagrams
- Modeling elements of entity-relationship diagrams
- Example of an entity-relationship diagram
- UML class diagrams
- Modeling elements of class diagrams
- Example of a UML class diagram
- Requirements modeling in the functional perspective
- Data flow diagrams
- Modeling elements of data flow diagrams
- Example of a data flow diagram
- Models of the functional perspective and control flow
- UML activity diagrams
- Sequence modeling using UML activity diagrams
- Control flow of main and alternative scenarios
- Requirements modeling in the behavioral perspective
- Statecharts
- UML state diagrams
Modeling with SysML
- SysML in Support of model-based requirements engineering
- Modeling functionality with Use Cases
- Modeling requirements and their relationships
- Modeling structure with blocks (Block Definition Diagrams)
- Modeling structure with blocks (Internal Block Diagrams)
- Modeling flow-based behavior with activities
- Modeling event-based behavior with state machines
- Modeling message-based behavior with interactions
- Modeling constraints with parametric
- Modeling cross-cutting relationships with allocations
Requirements Validation and Negotiation
- Fundamentals of requirements validation
- Fundamentals of requirements negotiation
- Quality aspects of requirements
- Quality aspect “content”
- Quality aspect “documentation”
- Quality aspect “agreement”
- Principles of requirements validation
- Engaging the proper stakeholders
- Specifying the determination and the correction of errors
- Validation from various perspectives
- Sufficient variation of documentation type
- Building of development artifacts
- Double validation
- Requirements validation methods
- Commenting
- Inspection
- Walk-through
- Perspective-based reading
- Validation through prototypes
- Using checklists for validation
- Requirements negotiation
- Conflict identification
- Conflict analysis
- Conflict resolution
- Documentation of the conflict resolution
Requirements Management
- Assigning attributes to requirements
- Attributes for natural language requirements and models
- Attribute scheme
- Attribute types of requirements
- Visions on requirements
- Selective views on the requirements foundation
- Condensed views on the requirements
- Prioritizing requirements
- Method for requirements prioritization
- Techniques for requirements prioritization
- Ranking and top-ten technique
- Single-criterion classification
- Kano classification
- Prioritization matrix according to Wiegers
- Traceability of requirements
- Advantages of traceable requirements
- Purpose-driven definition of traceability
- Classification of traceability relations
- Representation of requirements traceability
- Text-based references and hyperlinks
- Trace matrices
- Trace graphs
- Versioning of requirements
- Requirements versions
- Requirements configurations
- Requirements baselines
- Management of requirements changes
- Requirements changes
- The change control board
- The change request
- Classification of incoming change requests
- Basic method for corrective and adaptive changes
Workshop 1
- Defining your project
- Defining the goals and objectives
- Identifying the requirements
- Fully understanding the system and its components
- Defining the Use Case
- Modeling the requirements
- Verifying and validating the requirements
- Presenting the results to the class