Brainscape's Knowledge GenomeTM

Browse over 1 million classes created by top students, professors, publishers, and experts.


See full index

System Engineering notes > System Engineering Midterm Notes > Flashcards

System Engineering Midterm Notes Flashcards

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?
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
A
  • Conduct Review to identify
    remaining issues
  • Involve stakeholders
18
Q

Good Requirements

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?

A
  • Needed
  • Atomic
  • Verifiable
  • Design-independent
20
Q

Summary of a good requirement

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

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?

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:

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?

A
  • Global Integration
  • Integration “with the stream”
  • Incremental Integration
  • Subsets Integration
25
Q

What is Global Integration?

A

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
Q

What is Incremental Integration?

A

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
Q

What is Integration with the Stream

A

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
Q

What is Subsets Integration?

A

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
Q

Integration Lifecycle Activities within PLC

A
  • 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
Q

System Integration Test Levels:

A

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
Q

System Aggregation View?

A
  • Files are grouped into logical units where Unit Test is performed.
  • Several units are aggregated into a software component.
31
Q

Types of Test Methods?

A
  • Functional Test (Req. Verification)
  • Regression Testing
  • Validation Testing
32
Q

What is a Functional Test?

A

Full functional testing is a complete test cycle covering the feature/functionality included in a given prototype delivery.

33
Q

What is Regression Testing?

A

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
Q

What is Validation Testing?

A

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
Q

Test Execution Criteria:

A

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
Q
A

System Engineering notes (1 decks)

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