Look for someone who can... - Translate complex ideas simply - Build consensus among stakeholders - Represent different perspectives

1. Requirements
Engineering
Arta Doci, Quality Assurance Manager
Judy Bennett, Business Process Manager
Ruth Dameron, Senior Instructor, CU Boulder

2. Agenda
• Requirements
Essentials (Ruth)
• Requirements
Management Tools
(Arta)
• Requirements
Whisperer (Judy)

3. Requirements Essentials
Getting on the same page
Prof. Ruth Dameron
Dept of Electrical, Computer, & Energy Engineering
University of Colorado at Boulder

4. Working definitions for today
• What is a requirement?
• What are the categories of activities in requirements
engineering?
• Systems requirements engineering life cycle
• Framework
• In this context, what is the extent of requirements
traceability?

5. Objectively verifiable – measurable
diagram thanks to David Lamb
Customer has a preference
Customer has no not
measurable
preference YET measurable
Visible to Unspecified Requirements Goals
user requirements
Implementation Implementation
NOT freedom constraints
Visible to
user

6. Requirements Engineering
Requirements Engineering
Requirements Elicitation Requirements Analysis
Requirements Specification Requirements Verification
Requirements Management
Requirements Management:The process of ensuring that the software requirements
The planning and controlling of the requirements
Requirements Verification: The development of a "document" or set of documents
Requirements Specification: process of analyzing the customers’ and stakeholders'
Requirements Analysis:analysis, and verification process.
elicitation, specification, The with the system requirements, conforms to document
specification is Elicitation: The processof the requirements customers and the developer
Requirements in compliance through which the of the software system.
that clearly andat a definition of software requirements.
needs to arrive precisely records each
standards of the requirements review,and is an adequate basis forthe stakeholders'
of a software system discover, phase, articulate, and understand the architectural
(preliminary) design phase.
needs and the constraints on the software and the development activity.

7. Systems Requirements
Engineering Lifecycle
User Acceptance
Requirements Test
Capability
Development
System System Integration
Requirements Architecture Test
System
Development
Component User
Development User
Requirements
Requirements
Component
Development

8. Component Development
Lifecycle
User
User
Requirements
User
Requirements
Component
Requirements
Development
Software Architectural Detailed design Integration &
Requirements design & coding Verification

9. Requirements Engineering
Requirements
Elicitation
Requirements Requirements
Verification & Analysis
Validation
Requirements
Specification
Requirements Management
Categories of
activities in a
framework
Not a methodology

10. Requirements Engineering III
Release 1 Release 2 Release 3
Foundation
Requirements
Elicitation
Requirements
Requirements Analysis
Verification &
Validation Foundation
Requirements
Requirements Requirements
Elicitation
Specification Elicitation
Requirements
Requirements
Management Requirements Requirements
Requirements Analysis
Verification & Analysis
Verification
Validation
Requirements Requirements
Requirements Elicitation
Specification
Specification
Requirements
Requirements
Management Requirements
Management Requirements Analysis
Verification &
Validation
Requirements
Specification Requirements
Requirements
Management
Management

11. The extent of
requirements traceability
Origin -- stakeholder and identified need/request
Specified Requirements
Use Cases --> SysRS --> SRS
Design
Code
What does your
development Test cases
environment need
to trace?

12. Requirements Management
Tools
Arta Doci, Quality Assurance Manager

13. As a QA Manager, Why
Do I care about:
• Requirements?
• Requirements Management Tools?

14. Why do I care about
Requirements?
• My role: Software Validation and Verification
• As defined by the FDA (Quality System Regulation –
21 CFR § 820.3)
Validation means confirmation by examination and
provision of objective evidence that the particular
requirements for a specific intended use can be
consistently fulfilled.
Verification means confirmation by examination and
provision of objective evidence that specified
requirements have been fulfilled.

15. Why do I care about
Requirements
Management Tools?
• Need to provide Objective Evidence that:
o Requirements for a specific intended use can be consistently fulfilled.
o Requirements have been Fulfilled
• Need to provide Traceability
o Traceability is an essential requirement for regulatory approval of a medical device

16. Traceability Analysis
• Traceability is an essential requirement for regulatory approval of a
medical device
[Design Control Guidance For Medical Device Manufacturers]
• The following concepts are associated with Traceability:
o Ensure backward traceability from system requirements to the
acquisition needs
o Ensure backward traceability from system architecture, hardware, and
software requirements, and manual operations to the system
requirements.
o Ensure backward traceability from the software requirements to the
system requirements and design
o Ensure backward traceability from software detailed design and test
requirements to the software requirements
[Handbook of Medical Device Design]
Example: URS to SRS; SRS to Verification Test Cases; URS to Validation Test Cases

17. Requirements
Management Tools
• Provide a Common Repository for the project team
• Make Traceability Analysis Easier
• Facilitate team Collaboration and Communication
• Adhere to the Change Management Requirements
• Provide Online Publishing

18. Example: Traceability
Matrix
URS & SRS TRACEABILITY MATRIX
Project
Name:
The purpose of the Requirements Traceability document is to map user
requirements, functional specifications, to test cases, and illustrate the
relationships between these activities and documents of the <insert computer
system name>. Requirements traceability ensures that all requirements and
specifications are addressed and appropriately tested according to the results of
the risk assessment and ensures that design is based on predefined established
requirements. The requirements traceability will also assist with determining the
scope of a change of the system and with developing the regression test plans.
URS # UR Description SRS # SRS Description

19. Important features for the
Requirements Management
tool:
Requirements
Traceability Security and
Accessibility
Requirements
Analysis Change
Management
Online Publishing
Configuration
Management
Usability
Portability and Communication /
Backend Collaboration
Compatibility

20. Requirements Management
Tools: Case Study
• When selecting the right tool, the following factors
are important:
o Company size?
o Testing integration?
o Issue tracking integration?
o Software Development integration?

21. Requirements Management
Tools: Survey
• Compiled a list of 30 requirement management
tools (survey) – Let’s review them together!
• What tool do you use (how/why did you select the
tool)?

22. Tools can Integrate Requirements-
SW Development-SW Verification,
as per the V-Model SW Lifecycle

23. What is your main Requirements
(Software / Hardware) Problem?
• Track changes
• Difficult to write
• Feature creep
• Not well organized
• Are not always obvious and have many sources
• Are not always easy to express clearly in words
• Many different types of requirements at different levels
of detail
• Number of requirements can become unmanageable
if not controlled
• Can be time-sensitive
• Change

24. Who Makes Requirements
Engineering Successful?
The
Requirements Whisperer
Judy Bennett, Business Process Manager

25. Success Factors
• Process?
• Tools?
• Standards?
• Communication?
People!

26. Who is the Right Person?
• Analytical / Organized
o Simplify complex ideas into organized ideas
o Experience with various modeling techniques
• Translator / Communicator
o Bridges the gap between business and technology
o Restructure same idea for different audiences
o Experience in different roles

27. Who is the Right Person?
• Facilitator / Diplomat
o Helps build consensus
• Ambassador
o Represents SMEs to the development team
o Represents the development team to the SMEs
• Presenter
o Comfortable explaining ideas
o “Reads” their audience – do they “get it”?

28. What A Business Analyst
Does
Takes the requirements from the customer
and gives them to the developers

29. What a Business Analyst
Really Does
• Interact with subject matter experts
o understand business processes and needs
o Set expectations
• Gather requirements (not solutions)
• Author requirement specifications
• Present requirements to …
o SMEs to confirm/refine requirements
o Business leaders to facilitate decisions
o Developers to facilitate design coverage
• Verify that the solution meets requirements
• Support implementation
o Demonstrate to SMEs how the solution meets requirements
o Support documentation (user guide, online help, etc.)

30. Finding the Right Person
• Challenges
o Soft skills are rarely in a resume
o Job titles vary wildly
• Interview questions
o Objective assessment for hard skills
o Subjective assessment for soft skills

31. Interview Questions
• Give an example of when you explained the same
concept to different audiences (e.g., end user,
executive management).
• Explain how your job history led you to apply for this
position?
• What role do you typically take in meetings?
• A developer tells you “this requirement is too hard
technically”. What do you do?