Brainscape's Knowledge GenomeTM


Top Flashcards (Certified)
All Flashcards

System Engineering notes > System Engineering Midterm Notes > Flashcards

System Engineering Midterm Notes Flashcards

(37 cards)

Start Studying
1
Q

What is the objective of Requirements Engineering (RE)

A

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

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
2
Q

Why RE?

A

Customer: Knows what he needs
RE engineer: Specifies it precisely
Developer: Understands the product development precisely

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
3
Q

Who are the stakeholders for requirements? What is their connection to the Requirements Engineering Department?

A
  • Customer
  • Quality Management
  • Testers
  • Developers
  • Manufacturing
  • Management
  • Program Management
  • Standardization Institutes

The stakeholders voice out needs & requirements to the RE team.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
4
Q

How does the RE team make structured and meaningful requirements?

A
  • Methods
  • Tools
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
5
Q

What are some examples of Structured and Meaningful Requirements?

A
  • System Requirements
  • Software Requirements
  • Hardware Requirements
  • Mechanical Requirements
  • comments, proposals, hints
    etc.
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
6
Q

The Requirements Engineering team consists of two parts, what are they?

A

Requirements Management & Requirements Development

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
7
Q

What is Requirements Management?

A

Focus: Receive and Organize Requirements
- Plan & Control RE Activities
- Establish a Structure
- Trace Requirements
- Prioritize and Plan For Realization
- Manage Requirements Change

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
8
Q

What is Requirements Development

A

Focus: Creation of Requirements
- Detect Requirements
- Analyze Requirements
- Document Requirements
- Verify & Validate Requirements
- Analyze Impact of Changes

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
9
Q

What is a Requirement?

A
  1. A condition or capability needed by a user to solve a problem or
    achieve an objective
  2. 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.
  3. 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.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
10
Q

What can requirements be associated with?

A
  1. Stakeholder
  2. Vehicle
  3. System
  4. System Component
  5. Disciplines (SE/EE/SW/ME)
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
11
Q

What are detailed requirements dependent on?

A

Architectural design

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
12
Q

What are the two phases of a RE Cycle??

A

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

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
13
Q

What happens in Requirements Collection and Coarse Structuring?

A
  • 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
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
14
Q

Steps in, 1. Identifying collection of requirements

A

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?

  1. Interviews and Workshops with Stakeholders and Experts
  2. 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.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
15
Q
  1. Requirements Detailing?
A
  • Refine Requirements in collaboration with domain experts
  • Achieve Completeness
  • Achieve precision
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
16
Q
  1. Analysis and first Design Consideration?
Study These Flashcards
A
  • Check for consistency
  • Check for design implications and feasibility
  • Involve Project partners
  • Prioritize “High risk first” and synchronize with product maturity
    plan
17
Q
  1. Review & Approval
Study These Flashcards
A
  • Conduct Review to identify
    remaining issues
  • Involve stakeholders
18
Q

Good Requirements

Study These Flashcards
A
  • 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
19
Q

How to write good requirements?

Study These Flashcards
A
  • Needed
  • Atomic
  • Verifiable
  • Design-independent
20
Q

Summary of a good requirement

Study These Flashcards
A

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”

21
Q

Documentation Strategy

Study These Flashcards
A
  • 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
22
Q

What is System Integration?

Study These Flashcards
A

Integration is the reverse activity of decomposition: the different broken-down parts of a physical component are assembled (integrated) together in an appropriate order.

23
Q

An Integration Plan consists of two parts:

Study These Flashcards
A
  1. The integration strategy and 2. the integration steps define the order in which the broken-down parts are integrated
24
Q

What are some System Integration Strategies?

Study These Flashcards
A
  • Global Integration
  • Integration “with the stream”
  • Incremental Integration
  • Subsets Integration
25
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
26
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.
26
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.
27
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
28
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.
29
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)
30
System Aggregation View?
- Files are grouped into logical units where Unit Test is performed. - Several units are aggregated into a software component.
31
Types of Test Methods?
- Functional Test (Req. Verification) - Regression Testing - Validation Testing
32
What is a Functional Test?
Full functional testing is a complete test cycle covering the feature/functionality included in a given prototype delivery.
33
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.
34
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.
35
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
36

System Engineering notes (1 decks)

Brainscape helps you reach your goals faster, through stronger study habits.
© 2025 Bold Learning Solutions. Terms and Conditions