EECS X491.71 Systems Requirements Engineering 1-1

Systems Requirements
Engineering
EECS X491.71
© Copyright 2012 Rick Hefner 1-1 EECS X491.71 Systems Requirements Engineering
Course Objectives
At the end of this course, students will be able to:
• Develop an initial problem space definition;
• Develop and evaluate user, mission, and operational
needs, including the concept of operations;
• Develop and evaluate specifications for clarity,
completeness, and consistency;
• Perform requirements elicitation, requirements analysis
and requirements management;
• Identify effective approaches for
verification and validation of requirements.
Course Overview
1. Terminology & Definitions 7. System Concept Synthesis

2. System Mission Concepts 8. Requirements Specification
3. System Operational Concepts 9. Interface Requirements
4. Defining Requirements 10.Requirements Management
5. Requirements Elicitation 11.Requirements Validation
6. Requirements Analysis 12.Requirements Verification
Evaluation & Grading
• Class Attendance and Participation (50%)
– Each student is expected to review all lectures and participate fully in all
discussions, requiring 3-4 hours outside of class each week.
• Exercises (25%)
– Students will complete the exercises and post their results.
• Exam (25%)
– The exam will be handed out at the final class week. It will be open book
and open notes, and should result from the student’s individual effort. All
information necessary to answer the questions will be covered in the
lectures, text and other handouts.
Course Text
• The course text is Wasson, Charles, System Analysis,
Design, and Development: Concepts, Principles, and
Practices, Wiley & Sons, 2006
• This text is broader than most requirements texts, and
has some unique subjects and perspectives
• The course will be supplemented with additional
readings supplied as take-home exercises
Module 1:
Terminology & Definitions
Module Objectives
• Review key requirements Topics:
engineering terms and
concepts • Requirement Types
• Requirements Engineering
Processes
Requirements
• Requirements are the stated customer needs and
objectives for the system being designed and developed
– How well the system will work in its intended environment
– Also reflects constraints imposed by external interfaces, project
support, technology, and life cycle support systems
• Defining requirements is a highly creative process,
aimed at showing what the system will do, but avoiding
design decisions about how it will be done
– In the SE process, an intermediate step between user
requirements and the design
Good Requirements are Essential
• Demonstrates to users that their needs and constraints
are recognized
• Provides a foundation for design; allows for tradeoffs,
discussion, optimization
• Provides a basis for testing the system
Types of Requirements
• Customer (User) Requirements: Statements of fact and
assumptions that define the expectations of the system in terms
of mission objectives, environment, constraints, and measures of
effectiveness and suitability (MOE/MOS)
System Engineering Fundamentals, DoD, 2001

Operational Requirements
• Operational distribution or deployment: Where will the system
be used?
• Mission profile or scenario: How will the system accomplish its
mission objective?
• Performance and related parameters: What are the critical
system parameters to accomplish the mission?
• Utilization environments: How are the various system
components to be used?
• Effectiveness requirements: How effective or efficient must the
system be in performing its mission?
• Operational life cycle: How long will the system be in use by the
user?
• Environment: What environments will the system be expected to
operate in an effective manner?
Types of Requirements (cont.)
• Functional Requirements: The necessary task, action or activity
that must be accomplished
– Not quantitative
• Performance Requirements: The extent to which a mission or
function must be executed; generally measured in terms of
quantity, quality, coverage, timeliness or readiness. During
requirements analysis
– Measurable qualities – speed, size, weight, etc.
• Quantitative – how many, how much
• Qualitative – how well
• Coverage – how much area, how far
• Timeliness – how responsive, how frequent

• Design Requirements (Design Constraints): The “build to,” “code
to,” and “buy to” requirements for products and “how to execute”
requirements for processes expressed in technical data packages
and technical manuals
– Often dictated by a higher authority, i.e., laws, regulations, business choices
– E.g., all software shall be written in Ada

• Quality Attributes: Measures of “goodness” in the eyes of the user
or customer
– Typically cannot be measured directly
– Developer and customer must agree on the measurement approach and
how the measures will be interpreted to arrive at “satisfaction
Typical Quality Attributes
Agility The ability of a system to both be flexible and undergo change rapidly.
Flexibility The ease with which a system or component can be modified for use in
applications or environments, other than those for which it was
specifically designed.
Interoperability The ability of two or more systems or components to exchange
information and use the information that has been exchanged.
Maintainability The ease with which a system or component can be modified to correct
faults, improve performance or other attributes, or adapt to a changed
environment.
Reliability The ability of the system to keep operating over time. Reliability is
usually measured by mean time to failure.
Scalability The ability to maintain or improve performance while system demand
increases.
Usability A measure of how well users can take advantage of some system
functionality.
• Derived Requirements: Requirements that are implied or
transformed from higher-level requirement
– Often driven by a particular architecture or design decision
• Allocated Requirements: A requirement that is established by
dividing or otherwise allocating a high-level requirement into
multiple lower-level requirements
– Examples: power, weight, pointing accuracy

Attributes of Good Requirements
• A requirement must be achievable. It must reflect need or objective for which
a solution is technically achievable at costs considered affordable.
• It must be verifiable—that is, not defined by words such as excessive,
sufficient, resistant, etc. The expected performance and functional utility must
be expressed in a manner that allows verification to be objective, preferably
quantitative.
• A requirement must be unambiguous. It must have but one possible meaning.
It must be complete and contain all mission profiles, operational and
maintenance concepts, utilization environments and constraints. All
information necessary to understand the customer’s need must be there.

Attributes of Good Requirements - 2
• It must be expressed in terms of need, not solution; that is, it should address
the “why” and “what” of the need, not how to do it.
• It must be consistent with other requirements. Conflicts must be resolved up
front.
• It must be appropriate for the level of system hierarchy. It should not be too
detailed that it constrains solutions for the current level of design. For example,
detailed requirements relating to components would not normally be in a
system-level specification.

Well-Communicated Requirements
• Develop a common understanding with the customer of the
purpose and objectives of the set of requirements
• Organize requirements of different levels of detail into their
appropriate levels
• Clearly identify the capabilities, conditions, and constraints for
each requirement
• Identify requirements that are derived from other requirements
• Verify the completeness of the set of requirements
• Identify inconsistencies among requirements
MIL-STD-499C
Requirements Engineering Activities
Requirements
Elicitation
Requirements Requirements
Verification Analysis
Requirements
Management
Specification Validation
Adapted from
http://goldpractice.thedacs.com/practices/rto/
Discussion
• Which of the Requirements Engineering activities is
most challenging and why?
Requirements
Elicitation
Verification Analysis
Requirements
Management
Specification Validation

EECS X491.71 Systems Requirements Engineering 1-1

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

EECS X491.71 Systems Requirements Engineering 1-1

Caricato da

Copyright:

Formati disponibili

Systems Requirements

1. Terminology & Definitions 7. System Concept Synthesis

System Engineering Fundamentals, DoD, 2001

System Engineering Fundamentals, DoD, 2001

System Engineering Fundamentals, DoD, 2001

System Engineering Fundamentals, DoD, 2001

System Engineering Fundamentals, DoD, 2001

System Engineering Fundamentals, DoD, 2001

Potrebbero piacerti anche