System Engineering Midterm Notes Flashcards
What is the objective of Requirements Engineering (RE)
Utilize RE personnel, processes, tools and support facilities:
- To lower system costs
- To minimize technical risk
- To reduce development time
- and to improve the quality of new systems and applications
Overall, make a good product and a nice & smooth development project possible
Why RE?
Customer: Knows what he needs
RE engineer: Specifies it precisely
Developer: Understands the product development precisely
Who are the stakeholders for requirements? What is their connection to the Requirements Engineering Department?
- Customer
- Quality Management
- Testers
- Developers
- Manufacturing
- Management
- Program Management
- Standardization Institutes
The stakeholders voice out needs & requirements to the RE team.
How does the RE team make structured and meaningful requirements?
- Methods
- Tools
What are some examples of Structured and Meaningful Requirements?
- System Requirements
- Software Requirements
- Hardware Requirements
- Mechanical Requirements
- comments, proposals, hints
etc.
The Requirements Engineering team consists of two parts, what are they?
Requirements Management & Requirements Development
What is Requirements Management?
Focus: Receive and Organize Requirements
- Plan & Control RE Activities
- Establish a Structure
- Trace Requirements
- Prioritize and Plan For Realization
- Manage Requirements Change
What is Requirements Development
Focus: Creation of Requirements
- Detect Requirements
- Analyze Requirements
- Document Requirements
- Verify & Validate Requirements
- Analyze Impact of Changes
What is a Requirement?
- A condition or capability needed by a user to solve a problem or
achieve an objective - A condition or capability that must be met or possessed by a
system or system component to satisfy a contract, standard,
specification or other formally imposed documents. - A documented representation of a condition or capability as in 1
or 2
Requirements should specify WHAT and not HOW.
i.e. understand and specify the PROBLEM to be solved rather than the SOLUTION.
What can requirements be associated with?
- Stakeholder
- Vehicle
- System
- System Component
- Disciplines (SE/EE/SW/ME)
What are detailed requirements dependent on?
Architectural design
What are the two phases of a RE Cycle??
A - Identify Requirements
B - Analyze Requirements
A - Identify Requirements
1. Requirements Collection and Coarse Structuring
2. Requirements Detailing
B - Analyze Requirements
3. Analysis and first Design Consideration
4. Review and Approval
What happens in Requirements Collection and Coarse Structuring?
- Collect Requirements from various sources (Low details with
headlines or very simple desc) - Develop a structure with reasonable coherent chapters
- Generate first version of product maturity plan
Steps in, 1. Identifying collection of requirements
Identify Stakeholders:
- Who has an interest in our product?
- Who will use the functionality?
- Who in the organization will use the system?
- Who will take part in development of the product?
- What are external resources of the system
- What other systems will need to interact with this one?
- Interviews and Workshops with Stakeholders and Experts
- Document Analyses
Possible external Sources
− Customer Requirements Specification
− Any information received from the customer (e.g.
mail, dialogue, meetings)
− Competitors’ systems
− Standards and Norms (e.g. IEC 61508 Functional
safety of electrical/electronic/programmable electronic
safety-related systems)
− Technical research studies
− Laws (regulation need)
− Patents and patent situation
− etc.
Possible internal sources
− Long-term product strategy of the company
− Market surveys
− Quality goals (safety, reliability, performance,
usability)
− Internal re-use strategy
− Requirements of preceding projects
− Module and / or Integration tests
− Manufacturing
− Validation
− Lessons learned database
− Feedback from Architecture or Design Phase
− etc.
- Requirements Detailing?
- Refine Requirements in collaboration with domain experts
- Achieve Completeness
- Achieve precision
- Analysis and first Design Consideration?
- Check for consistency
- Check for design implications and feasibility
- Involve Project partners
- Prioritize “High risk first” and synchronize with product maturity
plan
- Review & Approval
- Conduct Review to identify
remaining issues - Involve stakeholders
Good Requirements
- Express what our customer wants
to obtain / what has been agreed
to deliver to him - are specified in a way that
different backgrounds will come to
the same understanding of these
requirements - are processed in a way that they
can be used later on in this project
and as well as for other projects
too
How to write good requirements?
- Needed
- Atomic
- Verifiable
- Design-independent
Summary of a good requirement
Completeness of Information
- one requirement per
Requirements-Object
- Always use active tense
- Replace references with the
referenced terms
- Always use the same word for the
same item
Conciseness
- Eliminate flowery phrases
- Use lists/enumeration to structure
complex requirements.
- Use diagrams/sketches to
illustrate complex requirements
Wording
- Express mandatory requirements
with “shall”/”shall not”
- Express descriptions/statement
with “to be”
Documentation Strategy
- Single source principle:
1. no information duplication
2. no redundant information - “off the shelf” principle:
1. standardized for all projects
2. easy navigation - documentation of functions top down
- integration of all documents of the project team into one information data base
- unambiguous simple structure
What is System Integration?
Integration is the reverse activity of decomposition: the different broken-down parts of a physical component are assembled (integrated) together in an appropriate order.
An Integration Plan consists of two parts:
- The integration strategy and 2. the integration steps define the order in which the broken-down parts are integrated
What are some System Integration Strategies?
- Global Integration
- Integration “with the stream”
- Incremental Integration
- Subsets Integration
What is Global Integration?
all the delivered implemented elements are assembled in only one step.
- Simple
- Dont need to simulate the implemented elements not avail at
that time
CONS:
- Difficult to detect and localize faults; interface faults are detected
late
- Should be reserved for simple systems, with few interactions and
few implemented elements without technological risk
What is Incremental Integration?
one or a few implemented elements are added to an already integrated increment of implemented elements, in a predefined order.
Fast localization of faults: a new fault is usually localized in lately integrated implemented elements or dependent of a faulty interface.
CONS:
- Require simulators for absent implemented elements. Require
many test cases, as each implemented addition required the verification of the new configuration and regression testing.
- Applicable to any type of architecture.
What is Integration with the Stream
The delivered implemented elements are assembled as they become available. Allowing starting the integration quickly.
CONS:
- Complex to implement because of the necessity to simulate the
implemented elements not yet available.
- Should be reserved for well known and controlled systems
without technological risks.
What is Subsets Integration?
Implemented elements are assembled by subset, and then subsets are assembled together (a subset is an aggregate); could also be called “functional chains integration”. Time saving due to parallel integrations of subsets; delivery of partial products is possible. Requires less means and fewer test cases than integration by increments.
- Subsets shall be defined during the design
- Applicable to architectures composed of sub-systems
Integration Lifecycle Activities within PLC
- Delivery arrives @ deadline
- Perform incoming inspection
- Generate System/Sub-sys. build
- Perform Pre-Verification
- Release/Freeze baseline @ deadline
- Activties for final approval:
. perform test against architechture
. perform assigned requirements tests
. verify solved problem reports
. derive add. test cases from PRs
. prepare product test spec.
System Integration Test Levels:
Smoke test:
- First time a build of a SW collection is created and loaded to a target
- SW loading works and the build starts and does not crash immediately
Spot Check Test:
- Test on feature level to ensure basic functionality and testability of a system
- One test case for every functionals area (or feature)
Interface Test:
- Scope of SI Test is test against SYS arch.
- Interfaces of SY building blocks will be tested with a white box
integration test
- Test cases based on important use cases defined by Sys
architects
- Automated Test preferred (ATP)
System Aggregation View?
- Files are grouped into logical units where Unit Test is performed.
- Several units are aggregated into a software component.
Types of Test Methods?
- Functional Test (Req. Verification)
- Regression Testing
- Validation Testing
What is a Functional Test?
Full functional testing is a complete test cycle covering the feature/functionality included in a given prototype delivery.
What is Regression Testing?
After a change in the product or its environment, it is necessary to ensure that no new faults have been introduced.
Based upon the nature of the changed that were made, a subset from the test case repo is selected to be used as a regression test set. Predefined or new test cases may be used.
What is Validation Testing?
testing the system from the end-user’s POV. Even if we fulfill the requirements as specified, it does not mean that the end-user will be satisfied with the product’s look-and-feel, usability, and performance.
Test Execution Criteria:
Entry Criteria: analyze to make sure that starting the test cycle makes sense
Suspend Criteria: Check test results on a regular basis to make sure that continuing the test cycle makes sense
Exit Criteria: Check test results summary to determine whether the goals of the test cycle have been met
