Requirements Engineering

1
Lesson 4

• Requirements Engineering

2
Course Outline Day 1

• Introduction to Systems Engineering
• Systems Engineering and Procurement
• Concept of Operations
• Requirements Engineering
• System Design Practices

3
Learning Objectives

• Define what is a requirement
• List the types of requirements
• Define good requirements
• Recognize poorly-written detailed requirements

4
Systems Engineering Life Cycle
Concept of Operations
Operations Maintenance
High Level Requirements
System Verification
Detailed Requirements
Integration Verification and Validation
High Level Design
Subsystem Verification
Definition and Decomposition
Detailed Design
Integration Test
Implementation
Time
5
What Are Requirements?

• Definition Something that governs what, how
  well, and under what conditions a product will
  achieve a given purpose. EIA 632 V. 1.0 1998
• Defines WHAT and not HOW
• Must be based on concept of operations

6
What is Requirements Engineering?

• Requirements engineering is a process to elicit,
  define (discover), document, analyze (derive),
  verify, validate and manage requirements.
• Understanding the problem space and bridging to
  the solution space.

5a
7
What is Requirements Engineering? Elicit and
Define

• Elicit Requirements capture raw requirements,
  expectations, user solutions, issues, previous
  studies, priorities, etc.
• Define/Discover Requirements. Translates the
  requirements captured by the concept of
  operations into well formed requirements.

5d
8
What is Requirements Engineering? Documentation
and Engineering

• Documentation Development of a requirements
  specification, Well structured and complete.
• Requirements Engineering - is the bridge between
  user requirements and system requirements.

5e
9
What is Requirements Engineering? Verification
and Validation

• Requirements Verification and Validation Are
  these the correct (valid) requirements? And are
  they verifiable.
• Write the verification and validation test plans
  with the requirements specification not after
  implementation.

5f
10
What is Requirements Engineering? Requirements
Management

• Requirements Management is the process of
  developing baselines, change management, and
  traceability of requirements.

5h
11
Two Types of Requirements

• End product requirements such as
• Functional
• Performance
• Interface
• Enabling requirements such as
• Development
• Testing
• Deployment
• Support

• Production
• Training
• Disposal

Ref. EIA 632 V. 1.0
6
12
Examples of the What

• The system verifies a toll users account
• The system exchanges incident data with another
  system
• The system displays bus locations to operators

13
Requirements Who has lead responsibility?
14
Types of requirements

• Functional requirements
• Interface requirements
• Data requirements I.e. what type of information
  should be stored
• System life-cycle cost requirements
• Performance requirements
• Testing requirements

15
Requirements should be addressed at increasing
levels of detail
High Level Requirements
Detailed Requirements
Detailed Requirements
Detailed Requirements
Very Detailed Requirements
Very Detailed Requirements
Very Detailed Requirements
16
Example of a Functional Requirement Hierarchy

• High level
• The system shall read tag data
• Detailed
• The system shall read tag ID
• The system shall read vehicle type (car, truck)
• More Details about reading tag ID
• The tag ID shall be checked for validity
• The tag ID shall be sent to other processes to
  debit user account

17
Characteristics a Good Requirement

• Necessary
• Clear (unambiguous)
• Complete
• Measurable (quantifiable)
• Consistent (with each other)
• Achievable (feasible)
• Testable
• Technology independent

12
18
Characteristics of Poorly-Written Detailed
Requirements

• Vague
• Mix interim goals with final output
• Presume a technology
• Poorly linked to customer expectations
• Subjective
• Qualitative
• Inappropriate (refer to a system design)

19
Examples of Poor Requirements

• The system shall use radar detectors for traffic
  monitoring
• State-of-the-art computers shall be used
• The system shall manage incidents
• All work shall be performed to the satisfaction
  of the Engineer
• Industry standard designs and components shall be
  used

20
Writing Style for Requirements

• Use shall rather than will or should
• One requirement per sentence
• Avoid the use of pronouns
• Avoid vague references such as good workmanship
  and proven technology

21
Examples (good or bad?)

• The retrieval of any single status from any field
  device shall not exceed 2 seconds from the
  initiation of the request
• The system user shall be able to verify
  reversible lane gate status of up, down, locked,
  and 15º status
• The system user interface shall indicate the
  current date and time, users name, and
  workstation location name

22
Can these requirements be met?

• Congestion shall be reduced
• People shall feel safer about riding the bus
• The system shall be implemented using
  state-of-the-art equipment.
• The signal timing system shall be automated

23
Workshop Problem 4

• Developing High Level and Detailed Requirements

24
How do I validate my requirements?

• Walkthroughs!

25
What is a Walkthrough?

• A walkthrough is a very boring
  sentence-by-sentence review of the requirements
  performed to ensure that all parties fully
  understand their intent,
• and
• To verify that they are the right requirements

26
Requirements Walk Through

• When
• At initial development
• At every evolutionary phase
• Whenever multiple requirements are being changed
• With whom Developer, project manager and all
  affected stakeholders

27
Substance of Walk Through

• Clarify
• Ensure common understanding
• Agree on the constraints
• Prioritize and eliminate unnecessary requirements
• Discuss any changes since the last walkthrough

28
Requirements Drive the Project

• Well defined requirements limit scope creep
• Well defined requirements minimize stakeholder
  disappointments
• Well defined requirements are the basis for cost
  and schedule management

29
User Services Can Help
Detailed Requirements
High Level Requirements
User Service Requirements (Approx. 1,300)
User Services (32)
User Service Bundles (8)
30
User Service Bundles

• Travel and Traffic Management
• Public Transportation Management
• Electronic Payment
• Commercial Vehicle Operations
• Emergency Management
• Advanced Vehicle Safety Systems
• Archived Data Information Services
• Maintenance Construction Operations

31
User Services Travel and Traffic Management
Example

• 1.1 Pre-trip Travel Information
• 1.2 En-route Driver Information
• 1.3 Route Guidance
• 1.4 Ride Matching and Reservation
• 1.5 Traveler Services Information

32
User Service Requirements Pre-trip Travel
Information Example

• 1.1.1 Provide travelers with information on
  available travel services
• 1.1.2 Permit users to access information on
  current conditions
• 1.1.3 Provide trip planning services
• 1.1.4 Provide user access from multiple locations

33
Requirements Traceability

• Begins during the concept of operations
• Use a numbering system to relate
• Operational concepts to requirements
• Requirements to design specifications
• Design specifications to tests

34
Requirements Traceability
Concept of Operations
Design Specifications
Requirements
Configuration Management
Implementation
Testing
35
Requirements Traceability
Concept of Operations
Design Specifications
Requirements
Configuration Management
Implementation
Testing
36
Traceability An Example
1.2 Vehicle drives Through Toll Lane
Concept of Operations
3.8.4 Check for Valid Tag
Requirements and Specs.
12.5.6 ID Verification S/W Module
Implementation
8.2 Drive Past the Reader
Testing
37
The Secret to Traceability is in the
Documentation An Example
Requirement 3.8.4 Check for Valid
ID Generating concept of operations
1.2 Related Software Modules 12.5.6 Related
Test 8.2
38
Principles of Traceability

• The components of every step are numbered
• Numbering is hierarchical and sequential
• Each step includes forward and backward
  references
• 3rd party software is available to support this
  process

39
Requirements Can Be Changed During Project
Develop requirements
Conduct Walkthrough
Concept of Operations
Develop Deploy
Acceptance Test
Requirements
Design
Configuration Management
Modify Requirements
Modify Requirements
40
But Late Changes Are Very Expensive
1x
Requirements
Design
10x
Cost to Change
100x
Implementation
Source Barry Bohem Software Economics
41
Documenting the Requirements

• Scope
• Referenced documentation           
• Definition of Requirements
• Process Information
• Interfaces and Standards
• See Appendix A for detailed outline

42
Learning Objectives

• Define what is a good requirement
• List the types of requirements
• Define good requirements
• Recognize poorly-written detailed requirements

43
Systems Engineering Life Cycle
Concept of Operations
Operations Maintenance
High Level Requirements
System Verification
Detailed Requirements
Integration Verification and Validation
High Level Design
Subsystem Verification
Definition and Decomposition
Detailed Design
Integration Test
Implementation
Time