Requirements Engineering Pmi
description
Transcript of Requirements Engineering Pmi
Requirements Engineering
Arta Doci, Quality Assurance Manager
Judy Bennett, Business Process Manager
Ruth Dameron, Senior Instructor, CU Boulder
Agenda
• Requirements
Essentials (Ruth)
• Requirements
Management Tools
(Arta)
• Requirements
Whisperer (Judy)
Requirements Essentials
Getting on the same page
Prof. Ruth Dameron
Dept of Electrical, Computer, & Energy Engineering University of Colorado at Boulder
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?
Objectively verifiable – measurable
diagram thanks to David Lamb
Visible to
user
NOT
Visible to
user
Customer has a preference
Customer has no
preference measurable
not
measurable
Requirements Goals
Implementation
constraints
Implementation
freedom
Unspecified
requirements
YET
Requirements Engineering
Requirements Elicitation Requirements Analysis
Requirements Specification Requirements Verification
Requirements Management
Requirements Engineering
Requirements Elicitation: The process through which the customers and the developer of a software system discover, review, articulate, and understand the stakeholders'
needs and the constraints on the software and the development activity.
Requirements Analysis: The process of analyzing the customers’ and stakeholders' needs to arrive at a definition of software requirements.
Requirements Specification: The development of a "document" or set of documents that clearly and precisely records each of the requirements of the software system.
Requirements Verification: The process of ensuring that the software requirements specification is in compliance with the system requirements, conforms to document standards of the requirements phase, and is an adequate basis for the architectural (preliminary) design phase.
Requirements Management: The planning and controlling of the requirements elicitation, specification, analysis, and verification process.
Systems Requirements Engineering Lifecycle
User Requirements
System Requirements
System Architecture
User Requirements
User Requirements Component Development
Integration Test
Acceptance Test
System Development
Capability Development
Component Development
Component Development Lifecycle
Software Requirements
Detailed design
& coding
Architectural
design
Integration & Verification
User Requirements User
Requirements User Requirements Component Development
Requirements Engineering
Requirements Management
Requirements Verification & Validation
Requirements Specification
Requirements Elicitation
Categories of
activities in a
framework
Not a methodology
Requirements Analysis
Requirements Elicitation
Requirements Verification & Validation
Requirements Specification
Requirements Management
Requirements Analysis
Release 1 Release 3 Release 2
Requirements Engineering III
Requirements Management
Requirements Elicitation
Requirements Verification
Requirements Specification
Requirements Management
Requirements Analysis
Foundation
Foundation
Requirements Elicitation
Requirements Verification & Validation
Requirements Specification
Requirements Management
Requirements Analysis
Requirements Elicitation
Requirements Verification & Validation
Requirements Specification
Requirements Management
Requirements Analysis
The extent of
requirements traceability Origin -- stakeholder and identified need/request
Specified Requirements
Use Cases --> SysRS --> SRS
Design
Code
Test cases What does your development environment need to trace?
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.
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
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
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
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
Important features for the Requirements Management
tool:
Requirements Traceability
Requirements Analysis
Security and Accessibility
Change Management
Online Publishing
Usability
Portability and Backend
Compatibility
Configuration Management
Communication / Collaboration
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?
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)?
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
Who Makes Requirements Engineering Successful?
The Requirements Whisperer
Judy Bennett, Business Process Manager
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
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”?
What A Business Analyst Does
Takes the requirements from the customer
and gives them to the developers
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.)
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
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?