Post on 28-May-2020
INFO2110 – Lecture 2 Presenter – Paul Zervos and John MacLeod
1 7-Aug-12© Copyright IBM Corporation 2012
IBM Global Business Services
© Copyright IBM Corporation 2012Paul Zervos
Lecture 2 – The Business Analyst, Requirements, and Gathering Techniques
INFO2110 – Systems Analysis and Modelling
IBM Global Business Services
© Copyright IBM Corporation 2012
Overview
� Role of a Business Analyst
� Types of Requirements
� Requirements Gathering Techniques
� Presentation from a Requirements Guru
INFO2110 – Systems Analysis and Modelling – Lecture 2 | Presenter - Paul Zervos | 7-Aug-12 1
IBM Global Business Services
© Copyright IBM Corporation 2012
The Role of the Business Analyst
� Liaises with the stakeholder to elicit, analyse, communicate and validate requirements for changes to business processes, policies and information systems.
� BA understands the business problems and opportunities and recommends solutions so the organisation can achieve its goal.
INFO2110 – Systems Analysis and Modelling – Lecture 2 | Presenter - Paul Zervos | 7-Aug-12 2
Business Analyst
Role
Define and Scope
Business Area
Elicit Requirements
Analyse and Document
Requirements
Communicate Requirements
Validate Requirements
IBM Global Business Services
© Copyright IBM Corporation 2012
The Role of the Business Analyst
INFO2110 – Systems Analysis and Modelling – Lecture 2 | Presenter - Paul Zervos | 7-Aug-12 3
IBM Global Business Services
© Copyright IBM Corporation 2012
Project Team Without A Business Analyst
INFO2110 – Systems Analysis and Modelling – Lecture 2 | Presenter - Paul Zervos | 7-Aug-12 4
IBM Global Business Services
© Copyright IBM Corporation 2012
The Need for a Business Analyst
INFO2110 – Systems Analysis and Modelling – Lecture 2 | Presenter - Paul Zervos | 7-Aug-12 5
INFO2110 – Lecture 2 Presenter – Paul Zervos and John MacLeod
2 7-Aug-12© Copyright IBM Corporation 2012
IBM Global Business Services
© Copyright IBM Corporation 2012
Cost of Requirements Errors
The later you catch an error the more it costs to f ix!
INFO2110 – Systems Analysis and Modelling – Lecture 2 | Presenter - Paul Zervos | 7-Aug-12 6
Cost of Requirements Errors
Phase
Relative Cost
MissingRequirement
DefectiveLogic
DesignErrorMissing
Function
FaultyItemsMissing
Test Case
OperationalFailure
IBM Global Business Services
© Copyright IBM Corporation 2012
What is a Requirement?
INFO2110 – Systems Analysis and Modelling – Lecture 2 | Presenter - Paul Zervos | 7-Aug-127
� A condition or capability that must be met or possessed by a system that is documented.
� Seen as a measurement of success, or the exit criteria where a software project is judged on.
IBM Global Business Services
© Copyright IBM Corporation 2012
Types of Requirements
� Business Requirement:
–Higher-level statements of the goals, objectives, or needs of the enterprise.
–They describe the reasons why a project is initiated, the things that the project will achieve, and the metrics which will be used to measure its success.
� Stakeholder Requirements:
–The needs of the stakeholders and how they will interact with the solution.
� Solution Requirements:
–Describe the characteristics of a solution that meet the business and stakeholder requirements.
–Two types: Functional and Non-Functional Requirements.
INFO2110 – Systems Analysis and Modelling – Lecture 2 | Presenter - Paul Zervos | 7-Aug-12 8
Business
Stakeholder
Solution
Functional Non-Functional
IBM Global Business Services
© Copyright IBM Corporation 2012
Types of Requirements
� Functional Requirements:
–Describe the process a system must perform or information it needs to contain.
� Non-Functional Requirements:
–Refer to behavioral properties that the system must have.
– Include constraints and qualities.
INFO2110 – Systems Analysis and Modelling – Lecture 2 | Presenter - Paul Zervos | 7-Aug-12 9
� FURPSS
–Functionality
–Usability
–Reliability
–Performance
–Supportability
–Security
� +
–Design requirements
– Implementation Requirements
– Interface Requirements
–Physical Requirements
Functional
Requirements
Non-Functional
Requirements
IBM Global Business Services
© Copyright IBM Corporation 2012
FURPSS+
� Usability
–User interface issues such as accessibility, aesthetics and consistency
� Reliability
–Availability, accuracy, recoverability
� Performance
–Throughput, response time, recovery time, start-up time
� Supportability
–Testability, adaptability, maintainability, compatibility, configurability, installability, scalability and localisability
� Security
–Who has authorised access to the system and under what circumstances
INFO2110 – Systems Analysis and Modelling – Lecture 2 | Presenter - Paul Zervos | 7-Aug-12 10
IBM Global Business Services
© Copyright IBM Corporation 2012
FURPSS+ (Operational)
� Design requirement
–Constraints on the design
–E.g. a relational database is required
� Implementation requirement
–Constrains on the coding or construction
–E.g. required standards, platform or implementation language
� Interface requirement
–A requirement to interact with an external item
� Physical requirement
–A physical constraint imposed on the hardware used to house the system
–E.g. Shape, size and weight
INFO2110 – Systems Analysis and Modelling – Lecture 2 | Presenter - Paul Zervos | 7-Aug-12 11
INFO2110 – Lecture 2 Presenter – Paul Zervos and John MacLeod
3 7-Aug-12© Copyright IBM Corporation 2012
IBM Global Business Services
© Copyright IBM Corporation 2012
Relationships between user needs, concerns and NFRs
INFO2110 – Systems Analysis and Modelling – Lecture 2 | Presenter - Paul Zervos | 7-Aug-1212
User’s need User’s concern NFR
Function
1. Ease of use 2. Unauthorised access 3. Likelihood of failure
1. Usability2. Security3. Reliability
Performance
1. Resource utilisation 2. Performance verification 3. Ease of interfacing
1. Efficiency2. Verifiability3. Interoperability
Change
1. Ease of repair 2. Ease of change3. Ease of transport ?4. Ease of expanding or upgrading
capacity or performance ?
1. Maintainability2. Flexibility3. Portability4. Expandability
IBM Global Business Services
© Copyright IBM Corporation 2012
Requirements must be SMART!
� S pecific
� M easurable
� A ttainable
� R ealistic
� T ime-bound
INFO2110 – Systems Analysis and Modelling – Lecture 2 | Presenter - Paul Zervos | 7-Aug-12 13
IBM Global Business Services
© Copyright IBM Corporation 2012
QUIZ
What type of requirements are the following:
1. Any interaction between the user and the system should not exceed 2seconds.
2. Only direct managers can see personnel records of staff
3. An online help system is required
4. The system will run 7 days a week, 24 hours a day
INFO2110 – Systems Analysis and Modelling – Lecture 2 | Presenter - Paul Zervos | 7-Aug-12 14
IBM Global Business Services
© Copyright IBM Corporation 2012
Process for Identifying and Validating Requirements
Gather Requirements
• Ask Questions• Interview sponsor• Research needs• Conduct focus group sessions
Categorise Requirements
• Determine whether requirement is a requirement or an exclusion
• Document decision
Validate Requirements
• Establish requirements baseline and deliverables
� Requirements baseline:
– Requirements document that has been approved by the sponsor, stakeholders, and key members of the project team.
– Defines what the sponsor wants and what the project team has agreed to deliver.
INFO2110 – Systems Analysis and Modelling – Lecture 2 | Presenter - Paul Zervos | 7-Aug-12 15
� MoSCow:
� Determine the scope
–Must have
–Should have Budget limited
–Could have Time limited
–Won’t have Nice, Non-Essential, future enhancements
In Scope
Out of Scope
IBM Global Business Services
© Copyright IBM Corporation 2012INFO2110 – Systems Analysis and Modelling – Lecture 2 | Presenter - Paul Zervos | 7-Aug-12 16
Rules to follow while conducting analysis
� Rule 1
– Start by focusing on the "what" and leave the "how" for later iterations
� Rule 2
– Never do design before analysis
� Rule 3
– Start from a clear description of the concepts and think in terms of the problem domain
� Rule 4
– Communicate with your partners extensively
NOTE: 68% of projects fail due to poor requirements analysis (Ellis, 2008).
Hence, a project is doomed right from the start.
IBM Global Business Services
© Copyright IBM Corporation 2012
Determining Requirements
� Requirements are best determined together by BAs and business people
� The basic process of analysis is divided into:
1. Understanding the as-is system
2. Identifying improvements
3. Developing requirements for the to-be system
� Strategies for analysing the requirements
–Business Process Automation (BPA)
–Business Process Improvement (BPI)
–Business Process Re-engineering (BPR)
INFO2110 – Systems Analysis and Modelling – Lecture 2 | Presenter - Paul Zervos | 7-Aug-1217
INFO2110 – Lecture 2 Presenter – Paul Zervos and John MacLeod
4 7-Aug-12© Copyright IBM Corporation 2012
IBM Global Business Services
© Copyright IBM Corporation 2012
Business Process Automation
� Leaves the way the organisation operates unchanged and uses computer technology to do some work.
Techniques:
� Problem analysis
–Ask users to identify problems with the current system
–Ask users how they would solve these problems
–Good for improving efficiency or ease-of-use
INFO2110 – Systems Analysis and Modelling – Lecture 2 | Presenter - Paul Zervos | 7-Aug-1218
IBM Global Business Services
© Copyright IBM Corporation 2012
Business Process Automation
� Root cause analysis
–Focus is on the cause of a problem, not its solution
–Create a prioritisedlist of problems
–Try to determine their causes
–Once the causes are known, solutions can be developed
INFO2110 – Systems Analysis and Modelling – Lecture 2 | Presenter - Paul Zervos | 7-Aug-1219
IBM Global Business Services
© Copyright IBM Corporation 2012
Business Process Improvement
� Makes moderate changes to the way an organisation operates to take advantage of opportunities technology offers (or copy competitors ☺)
� Techniques:
–Duration analysis
� Determine the time required to complete each step in a business process
� Compare this to the total time required for the entire process
� Large differences suggest problems that might be solved by:
- Integrating some steps together
- Performing some steps simultaneously (in parallel)
–Activity-based costing – same as duration analysis but applied to costs
– Informal benchmarking – analyses similar processes in other successful organisations
INFO2110 – Systems Analysis and Modelling – Lecture 2 | Presenter - Paul Zervos | 7-Aug-1220
IBM Global Business Services
© Copyright IBM Corporation 2012
Business Process Re-engineering
� Institutes maximum change: “Out with the old and in with the new”
� Techniques:
–Outcome analysis:
� What does the customer want in the end?
–Technology analysis:
� Apply new technologies to business processes & identify benefits
–Activity elimination:
� Eliminate each activity in a business process in a “force-fit” exercise
INFO2110 – Systems Analysis and Modelling – Lecture 2 | Presenter - Paul Zervos | 7-Aug-1221
IBM Global Business Services
© Copyright IBM Corporation 2012
� Techniques:
– Interviews
– Joint Application Development (JAD) / Workshops
– Observation
– Questionnaires
– Document analysis
� Approach needs to be planned and agreed with client
� Don’t underestimate preparation required
Requirements Gathering Techniques
INFO2110 – Systems Analysis and Modelling – Lecture 2 | Presenter - Paul Zervos | 7-Aug-1222
IBM Global Business Services
© Copyright IBM Corporation 2012
Interviews
� Most popular technique – If you need to know something, just ask
Steps:
1. Select people to interview & create a schedule
2. Design interview questions (Open-ended, closed-ended, & probing types of questions)
3. Prepare for the interview (Unstructured vs. structured interview organised in a logical order)
4. Conduct the interview (Top-down vs. bottom-up)
5. Follow-up after the interview
INFO2110 – Systems Analysis and Modelling – Lecture 2 | Presenter - Paul Zervos | 7-Aug-1223
INFO2110 – Lecture 2 Presenter – Paul Zervos and John MacLeod
5 7-Aug-12© Copyright IBM Corporation 2012
IBM Global Business Services
© Copyright IBM Corporation 2012
Question Types
NOTE: Avoid leading questions!
INFO2110 – Systems Analysis and Modelling – Lecture 2 | Presenter - Paul Zervos | 7-Aug-1224
Types of Questions
Examples
Closed-ended
• How many telephone orders are received per day? • What information is missing from the monthly sales report? • How do customers place orders?
Open-ended
• What do you think about the current system?• What are some of the problems you face on a daily basis? • What are some of the improvements you would like to see in a
new system?
Probing
• Why?• Can you give me an example?• Can you explain that in a bit more detail?
IBM Global Business Services
© Copyright IBM Corporation 2012
Interviewing Strategies
INFO2110 – Systems Analysis and Modelling – Lecture 2 | Presenter - Paul Zervos | 7-Aug-12 25
How
can order
processing be
improved?
How can we reduce the
number of times that customers
return ordered items?
How can we reduce the number of
errors in order processing (e.g., shipping
the wrong products)?
Top-down
Bottom-up
High-level:
Very general
Medium-level:
Moderately specific
Low-level:
Very specific
IBM Global Business Services
© Copyright IBM Corporation 2012
Post-Interview
� Prepare notes and send to the interviewee for verification
INFO2110 – Systems Analysis and Modelling – Lecture 2 | Presenter - Paul Zervos | 7-Aug-1226
IBM Global Business Services
© Copyright IBM Corporation 2012
Joint Application Development (JAD)
� Allow project team, users and management to work together to identify requirements for a system.
� Meeting hosted by a facilitator
� 10 to 20 users
� 1 to 2 scribes
� Sessions require careful planning to be successful
INFO2110 – Systems Analysis and Modelling – Lecture 2 | Presenter - Paul Zervos | 7-Aug-1227
IBM Global Business Services
© Copyright IBM Corporation 2012
JAD / Workshop Tips
INFO2110 – Systems Analysis and Modelling – Lecture 2 | Presenter - Paul Zervos | 7-Aug-1228
� Work through the context
� Brief participants on what they are to do
� Check for agreement to the process
� Check for understanding throughout
� Summarise regularly
� Use parking lots or other techniques to maintain focus
� Anticipate obvious and difficult questions / issues
� Remember to conclude with actions/issues/decisions list and next steps
IBM Global Business Services
© Copyright IBM Corporation 2012
Questionnaires
� A set of written questions used to obtain information from individuals
� May be paper based or electronic (e.g. web based)
� Common uses:
–Large numbers of people
–Need both information and opinions
–For use outside an organisation (customers, vendors, etc.)
INFO2110 – Systems Analysis and Modelling – Lecture 2 | Presenter - Paul Zervos | 7-Aug-1229
INFO2110 – Lecture 2 Presenter – Paul Zervos and John MacLeod
6 7-Aug-12© Copyright IBM Corporation 2012
IBM Global Business Services
© Copyright IBM Corporation 2012
Questionnaire Steps
1. Select the participants
– Identify the population
– Use representative samples for large populations
2. Designing the questionnaire
– Careful question selection
– Remove ambiguities
3. Administering the questionnaire
– Working to get good response rate
– Offer an incentive (e.g., a free pen)
4. Questionnaire follow-up
– Send results to participants
– Send a thank-you
INFO2110 – Systems Analysis and Modelling – Lecture 2 | Presenter - Paul Zervos | 7-Aug-1230
IBM Global Business Services
© Copyright IBM Corporation 2012
Good Questionnaire Design
� Begin with interesting questions
� Group items into logically coherent sections
� Do not crowd a page with too many items
� Avoid abbreviations
� Avoid biased or suggestive items or terms
� Pretest to identify confusing questions
� Provide anonymity to respondents
INFO2110 – Systems Analysis and Modelling – Lecture 2 | Presenter - Paul Zervos | 7-Aug-1231
IBM Global Business Services
© Copyright IBM Corporation 2012
Document Analysis
� Provides information about the “as-is” system
� Review technical documents when available
� Review typical user documents:
–Forms
–Reports
–Policy manuals
� Look for user additions to forms
� Look for unused form elements
INFO2110 – Systems Analysis and Modelling – Lecture 2 | Presenter - Paul Zervos | 7-Aug-1232
IBM Global Business Services
© Copyright IBM Corporation 2012
Observation
� Users/managers often don’t remember everything they do
� Checks validity of information gathered in other ways
� Be careful not to ignore periodic activities
– Weekly … Monthly … Annually
� Pitfall: Behaviors may change when people are watched
–Workers tend to be very careful when watched
–Keep a low profile
–Try not to interrupt or influence workers
INFO2110 – Systems Analysis and Modelling – Lecture 2 | Presenter - Paul Zervos | 7-Aug-1233
IBM Global Business Services
© Copyright IBM Corporation 2012
Common mistakes
� Requirements are too general
–Be specific as possible.
� Premature solutions
–Specify requirements not solutions.
� Talking to the wrong people
– Identify the type of stakeholder responsible for answering each
� Requirements are not measurable
–Ensure that requirements are unambiguous and as measurable as possible
INFO2110 – Systems Analysis and Modelling – Lecture 2 | Presenter - Paul Zervos | 7-Aug-1234
IBM Global Business Services
© Copyright IBM Corporation 2012
Common mistakes
INFO2110 – Systems Analysis and Modelling – Lecture 2 | Presenter - Paul Zervos | 7-Aug-1235
� The “shopping cart” mentality
–Ensure stakeholders understand the “cost” of their purchases
INFO2110 – Lecture 2 Presenter – Paul Zervos and John MacLeod
7 7-Aug-12© Copyright IBM Corporation 2012
IBM Global Business Services
© Copyright IBM Corporation 2012
Case Study – Event Management System
Snippet from a System Proposal Document:
� Business Needs
1) Increase general student participation for events hosted by university clubs and societies.
2) Allow all university clubs and societies the opportunity to promote and manage their events.
3) Increase the efficiency of the event management and booking process.
4) Reduce the costs associated with manual booking and event management processes.
5) Reduce costs associated with the provision of funds for development and maintenance of separate event
management systems for individual clubs or societies.
� Business Requirements
1) Customers should be able make bookings for events that they are interested in.
2) Event hosts should be able to register, promote and manage their events.
3) Event hosts should be able to manage customer bookings for their events.
INFO2110 – Systems Analysis and Modelling – Lecture 2 | Presenter - Paul Zervos | 7-Aug-12 36
IBM Global Business Services
© Copyright IBM Corporation 2012
Case Study – System Functional Requirements
PriorityBusiness
Req. ID System Functional Requirement
Must
Must
MustMust
Must
Must
2
2
22
2
2
SFR1. Event Host Enrolment1.1. The system will allow event hosts like union clubs and societies to enrol into the
system. 1.2. Event hosts will be able to enter at least the following details at enrolment: event
host name, ABN, and email.1.3. Event hosts will be able to update the details mentioned in SFR1.2 at anytime. 1.4. During enrolment, the event host will be prompted to enter a nominated account
into which booking revenues can be deposited and from which refunds can be issued.
1.5. The event host should be able to change their nominated account details (see SFR1.2) at any time.
1.6. Event hosts shall be able to make changes to any enrolment details at any time.
Other SFRs (Event Registration, Customer Enrolment, Event News)
Must
Must
1,2
1,2
SFR5. Event Queries5.1. All users shall be able to query for events by event name, description, event host
name, venue, time, duration, or cost. 5.2. Event hosts shall be able to see a list of events that they have registered, and
query them by name, description, venue, time, duration and cost.
INFO2110 – Systems Analysis and Modelling – Lecture 2 | Presenter - Paul Zervos | 7-Aug-12 37
IBM Global Business Services
© Copyright IBM Corporation 2012
Case Study – System Functional Requirements
PriorityBusiness
Req. ID System Functional Requirement
MustMust
Must
Must
11
1
1
SFR7. Event Bookings7.1. Enrolled customers shall be able to make bookings for any listed event. 7.2. Customers will be asked to pay immediately by credit card, or at the venue (if
permitted by the event host (see SFR2.7)).7.3. If customers choose to pay immediately, payment is deducted from their
nominated account (SFR3.2)7.4. Enrolled customers shall be able to cancel their bookings if the event host permits
booking cancellations, and the booking cancellation deadline defined in SFR2.6 has not passed.
Other SFRs (Event Details, Event Updates)
Could 1SFR9. Event Recommendations
9.1. Enrolled customers shall be able to recommend an event to friends.
INFO2110 – Systems Analysis and Modelling – Lecture 2 | Presenter - Paul Zervos | 7-Aug-12 38
IBM Global Business Services
© Copyright IBM Corporation 2012
Case Study – System Non-Functional Requirements
Priority System Non-Functional Requirement
MustSNFR1. Interoperability
1.1. The system will allow enrolled event hosts to import and export event and booking information using a public data exchange API, after logging in with appropriate event host credentials.
Must
Must
SNFR2. Operational2.1. Event hosts and Customers should be able to access the system from any desktop
web browser.2.2. Customers should be able to access the system from the default iPhone, android, and
Windows Phone web browsers.
Must
Must
SNFR3. Security3.1. Only customers with appropriate login credentials shall be able to see and update their
personal details and their personal booking details with the exception of SFR3.3.3.2. Event hosts shall be able to view customer postal address, name, and email address
for customers that have made bookings for their events. Event hosts shall also be able to see details for all bookings related to their events.
MustSNFR4. Performance
4.1. Response times for any type of request should be less than 2 seconds.
INFO2110 – Systems Analysis and Modelling – Lecture 2 | Presenter - Paul Zervos | 7-Aug-12 39
IBM Global Business Services
© Copyright IBM Corporation 2012
References
� IBM resource material
� Business analysis benchmark, Ellis, K. 2008.
� Systems Analysis and Design with UML, 4th Edition, Dennis, A. 2012.
� The University of Sydney – INFO2110 resource material
For full details of references please contact me.
INFO2110 – Systems Analysis and Modelling – Lecture 2 | Presenter - Paul Zervos | 7-Aug-12 40
IBM Global Business Services
© Copyright IBM Corporation 2012
The End
INFO2110 – Systems Analysis and Modelling – Lecture 2 | Presenter - Paul Zervos | 7-Aug-12 41
Feel free to contact me if you have any further questions paul.zervos@au1.ibm.com
INFO2110 – Lecture 2 Presenter – Paul Zervos and John MacLeod
8 7-Aug-12© Copyright IBM Corporation 2012
REQUIREMENTS MANAGEMENT
FROM AN INDUSTRY PERSPECTIVE
John MacLeod - <john.macleod@au1.ibm.com>
INFO2110 – Systems Analysis and Modelling – Lecture 2 | Presenter – John Macleod | 7-Aug-12 | © Copyright IBM Corporation 2012
Agenda
• The Case for Requirements Management• 3 Good Requirements Management Practices• Requirements and Measurement
INFO2110 – Systems Analysis and Modelling – Lecture 2 | Presenter – John Macleod | 7-Aug-12 | © Copyright IBM Corporation 2012
The Hardest Single PartThe hardest single part of building a software system is deciding
precisely what to build. No other part of the conceptual work is as difficult as establishing the detailed technical requirements, including all the interfaces to people, to machines, and to other software systems. No other part of the work so cripples the resulting system if done wrong. No other part is more difficult to rectify later.
Frederick Brooks in his classic 1987 Essay “No Silver Bullet: Essence and Accidents of Software Engineering”
INFO2110 – Systems Analysis and Modelling – Lecture 2 | Presenter – John Macleod | 7-Aug-12 | © Copyright IBM Corporation 2012
Start at the beginning.
65%
20%
10%
4%
17%
60%
21%WhereFound
Requirements and Design
Code and Test
User Acceptance Test
Production
The majority of the problems are coming from bad requirements and design.
And they are found too late in the application lifecycle.
WhereInjected
INFO2110 – Systems Analysis and Modelling – Lecture 2 | Presenter – John Macleod | 7-Aug-12 | © Copyright IBM Corporation 2012
Cost of requirements errors
The message is simple. The later you catch an error the more it costs to fix!It will never be cheaper to catch errors than in th e Requirements Phases.
Cost of Requirements Errors
Phase
Relative Cost
MissingRequirement
DefectiveLogic
DesignErrorMissing
Function
FaultyItemsMissing
Test Case
OperationalFailure
INFO2110 – Systems Analysis and Modelling – Lecture 2 | Presenter – John Macleod | 7-Aug-12 | © Copyright IBM Corporation 2012
The oldest (IT) joke in the book
INFO2110 – Systems Analysis and Modelling – Lecture 2 | Presenter – John Macleod | 7-Aug-12 | © Copyright IBM Corporation 2012
INFO2110 – Lecture 2 Presenter – Paul Zervos and John MacLeod
9 7-Aug-12© Copyright IBM Corporation 2012
The Hardest Part
The hardest single part of building a software system is deciding precisely what to build. No other part of the conceptual work is as difficult as establishing the detailed technical requirements, including all the interfaces to people, to machines, and to other software systems. No other part of the work so cripples the resulting system if done wrong. No other part is more difficult to rectify later.
Frederick Brooks in his classic 1987 Essay “No Silver Bullet: Essence and Accidents of Software Engineering”
INFO2110 – Systems Analysis and Modelling – Lecture 2 | Presenter – John Macleod | 7-Aug-12 | © Copyright IBM Corporation 2012
Mars Climate Orbiter
“The 'root cause' of the loss of the spacecraft was the failed translation of imperial units into metric units in a segment of ground-based, navigation-related mission software“
“The process to verify and validate certain engineering requirements and technical interfaces between some project groups, and between the project and its prime mission contractor, was inadequate”
INFO2110 – Systems Analysis and Modelling – Lecture 2 | Presenter – John Macleod | 7-Aug-12 | © Copyright IBM Corporation 2012
But When Requirements are Right…
INFO2110 – Systems Analysis and Modelling – Lecture 2 | Presenter – John Macleod | 7-Aug-12 | © Copyright IBM Corporation 2012
Why are better requirements needed?
Requirements Management is a High Leverage Activity
“Quality is free” Phillip Crosby
INFO2110 – Systems Analysis and Modelling – Lecture 2 | Presenter – John Macleod | 7-Aug-12 | © Copyright IBM Corporation 2012
Impact of Requirements Practice - Unisys
RequirementsEngineering
Process
Improved FeatureCoverage
Reduced Rework
Improved Communication
Fewer Defects
Accurate Estimates
Effective Project Negotiation
Reduced Requirements Creep
PeerReview
Conformance to Specification
CrossFunctional
Teams
ProjectTrackingChange
Management
FeatureSizing
Testing AgainstRequirementsRisk
Productivity
Quality
Source: Requirements Payoff: An Empirical study of the relationship between requirements practice and software productivity, quality and risk management.
-Damian, Chisan, Samy & Pal
INFO2110 – Systems Analysis and Modelling – Lecture 2 | Presenter – John Macleod | 7-Aug-12 | © Copyright IBM Corporation 2012
Requirements Are Everywhere
RequirementsINFO2110 – Systems Analysis and Modelling – Lecture 2 | Presenter – John Macleod | 7-Aug-12 | © Copyright IBM Corporation 2012
INFO2110 – Lecture 2 Presenter – Paul Zervos and John MacLeod
10 7-Aug-12© Copyright IBM Corporation 2012
Whole-life Management
Requirements form the basis for:• project planning• risk management• acquisition management• trade-off• change control• qualification / testing• deployment• maintenance / support / enhancements• retirement / disposal
(RMB-44)
INFO2110 – Systems Analysis and Modelling – Lecture 2 | Presenter – John Macleod | 7-Aug-12 | © Copyright IBM Corporation 2012
3 GOOD PRACTICES
• Understand the difference between the problem & the solution
• Drive testing from requirements
• Create, review and use traceability
• Use concise, clear, consistent language in statements (if we
have time!)
INFO2110 – Systems Analysis and Modelling – Lecture 2 | Presenter – John Macleod | 7-Aug-12 | © Copyright IBM Corporation 2012
Good Practice 1: Distinguish between Problem and Solution
Problemdefinition
Specificsolution
Abstractsolution
CustomerRequirements
SystemRequirements
Design
Risk of definingthe wrong problem
INFO2110 – Systems Analysis and Modelling – Lecture 2 | Presenter – John Macleod | 7-Aug-12 | © Copyright IBM Corporation 2012
Example
INFO2110 – Systems Analysis and Modelling – Lecture 2 | Presenter – John Macleod | 7-Aug-12 | © Copyright IBM Corporation 2012
Good Practice 1: Distinguish between Problem and Solution
Problemdefinition
Specificsolution
Abstractsolution
CustomerRequirements
SystemRequirements
Design or Acquire
Risk of definingthe wrong problem
Risk of not meeting the requirements
Should be possible to change thedesign withoutchanging systemrequirements
Risk ofunnecessarilyconstrainingthe solution
INFO2110 – Systems Analysis and Modelling – Lecture 2 | Presenter – John Macleod | 7-Aug-12 | © Copyright IBM Corporation 2012
Differentiating Problem and Solution
Customer requirements• A description of the problem
and its context• Results that stakeholders want
from the system• Do not define the solution, other
than for environment• Quality of results• Owned by stakeholders or their
representatives (e.g. marketing)
System requirements• An abstract representation of
the solution• What the system does
• Do not define the design
• How well it does it• Owned by systems engineers
“The user shall be able to ....” “The system shall do ….”
Problem Solution
INFO2110 – Systems Analysis and Modelling – Lecture 2 | Presenter – John Macleod | 7-Aug-12 | © Copyright IBM Corporation 2012
INFO2110 – Lecture 2 Presenter – Paul Zervos and John MacLeod
11 7-Aug-12© Copyright IBM Corporation 2012
HOW DO YOU KNOW WHEN YOU ARE DONE?
INFO2110 – Systems Analysis and Modelling – Lecture 2 | Presenter – John Macleod | 7-Aug-12 | © Copyright IBM Corporation 2012
Good Practice 2: Drive Testing from Requirements
• Of every requirement statement, ask:• “How will you know if the need has been met?”
• Improves the way the requirement is expressed• Is it quantified?• What are the success criteria?• Add requirements to make system testable
• Plan the tests now, not later:• What kind of tests will be used?• When will the tests be performed?
• Preparing the tests may take months or years:• Collect requirements for test facilities
• Trace tests to requirements• Include tests in impact analysis
INFO2110 – Systems Analysis and Modelling – Lecture 2 | Presenter – John Macleod | 7-Aug-12 | © Copyright IBM Corporation 2012
Principles of Requirements-Driven Testing
• Plan Tests Early• To understand the requirements better
• Conduct Tests Early• Phase injection vs. phase detection
• Relate Tests to Requirements• Assurance requirements are met
• Relate Defects to Requirements• Understand impact of defects
• Measure Progress against Requirements
INFO2110 – Systems Analysis and Modelling – Lecture 2 | Presenter – John Macleod | 7-Aug-12 | © Copyright IBM Corporation 2012
Good Practice 3: Create, review and use traceabilityDEFINITION OF TRACEABILITY
• Documenting how high-level goals are transformed into low-level goals.
• Understanding how needs are satisfied
• Understand how requirements are qualified (tests, inspections, trials
INFO2110 – Systems Analysis and Modelling – Lecture 2 | Presenter – John Macleod | 7-Aug-12 | © Copyright IBM Corporation 2012
Traceability in the lifecycleGood Practice: Create, review and use traceability
Acceptance test
validating the productStakeholderRequirements
satisfies
ComponentRequirements
Component test
evaluating components
SubsystemRequirements
Subsystem test
evaluating the subsystems
satisfies
SystemRequirements
System test
verifying the system
satisfies
Operational UseStatement of need
INFO2110 – Systems Analysis and Modelling – Lecture 2 | Presenter – John Macleod | 7-Aug-12 | © Copyright IBM Corporation 2012
Impact AnalysisGood Practice: Create, review and use traceability
Acceptance test
validating the productStakeholderRequirements
satisfies
ComponentRequirements
Component test
evaluating components
SubsystemRequirements
Subsystem test
evaluating the subsystems
satisfies
SystemRequirements
System test
verifying the system
satisfies
Operational UseStatement of need
INFO2110 – Systems Analysis and Modelling – Lecture 2 | Presenter – John Macleod | 7-Aug-12 | © Copyright IBM Corporation 2012
INFO2110 – Lecture 2 Presenter – Paul Zervos and John MacLeod
12 7-Aug-12© Copyright IBM Corporation 2012
Derivation AnalysisGood Practice: Create, review and use traceability
Acceptance test
validating the productStakeholderRequirements
satisfies
ComponentRequirements
Component test
evaluating components
SubsystemRequirements
Subsystem test
evaluating the subsystems
satisfies
SystemRequirements
System test
verifying the system
satisfies
Operational UseStatement of need
INFO2110 – Systems Analysis and Modelling – Lecture 2 | Presenter – John Macleod | 7-Aug-12 | © Copyright IBM Corporation 2012
Derivation Coverage AnalysisGood Practice: Create, review and use traceability
Acceptance test
validating the productStakeholderRequirements
satisfies
ComponentRequirements
Component test
evaluating components
SubsystemRequirements
Subsystem test
evaluating the subsystems
satisfies
SystemRequirements
System test
verifying the system
satisfies
Operational UseStatement of need
?
?
INFO2110 – Systems Analysis and Modelling – Lecture 2 | Presenter – John Macleod | 7-Aug-12 | © Copyright IBM Corporation 2012
Three Criteria for Reviewing Traceability
1. Coverage: is every requirement traced?2. Sufficiency: are the traced lower-level requirements sufficient
to satisfy the higher-level?3. Necessity: are all the traced lower-level requirements
necessary to satisfy the higher-level?
The fuel system shall manage up to 6 injectors operating in a pressure range of between 3 bar and 300 bar.
This requirement is satisfied by providing a fuel system capable of• supplying fuel at a sufficiently high pressure, so ensure that the mixture is homogeneous and combustible.• controlling the booster pressure to ensure optimum fuel combustion. • feeding up to 6 injectors, since a 1.4 litre engine may have 6 cylinders.
The EMS shall control the booster pressure ranging from 0 bar to 3 bar with a precision of ±30 mBar.
The fuel system shall manage a high-pressure pump with a displacement of between 500 mm3 and 1000 mm3.
The EMS shall control a turbo-charged, gasoline, direct injection engine with a displacement range between 1.0 litres and 1.4 litres.
Good Practice: Create, review and use traceability
INFO2110 – Systems Analysis and Modelling – Lecture 2 | Presenter – John Macleod | 7-Aug-12 | © Copyright IBM Corporation 2012
Using Office Documents
Need to use some tags to identify the element to trace.
Customer’s needs
System Spec
INFO2110 – Systems Analysis and Modelling – Lecture 2 | Presenter – John Macleod | 7-Aug-12 | © Copyright IBM Corporation 2012
70
Traceability; drag-and-drop linking
INFO2110 – Systems Analysis and Modelling – Lecture 2 | Presenter – John Macleod | 7-Aug-12 | © Copyright IBM Corporation 2012
Traceability view1. 820.30(b) Design and Development Planning
Each manufacturer shall establish and maintain plans that describe or reference the design and developmentactivities and define responsibility for implementation.
The plans shall identify and describe the interfaces with different groups or activities that provide, or resultin, input to the design and development process.
The plans shall be reviewed as design and development evolves.The plans shall be updated as design and development evolves.The plans shall be approved as design and development evolves.
2. 820.30(c) Design Input2.1. Each manufacturer shall establish procedures to ensure that the design requirements relating to a
device are appropriate and address the intended use of the device, including the needs of the userand patient.
2.2. Each manufacturer shall maintain procedures to ensure that the design requirements relating to adevice are appropriate and address the intended use of the device, including the needs of the userand patient.
2.3. The procedures shall include a mechanism for addressing incomplete requirements.2.4. The procedures shall include a mechanism for addressing ambiguous requirements.2.5. The procedures shall include a mechanism for addressing conflicting requirements.2.6. The design input requirements shall be documented by a designated individual(s).2.7. The design input requirements shall be reviewed by a designated individual(s).2.8. The design input requirements shall be approved by a designated individual(s).2.9. The approval, including the date and signature of the individual(s) approving the requirements,
shall be documented.2.10. Questions.
2.10.1. Summarize the manufacturer's written procedure(s) for identification and control ofdesign input.
2.10.2. From what sources are design inputs sought?2.10.3. Do design input procedures cover the relevant aspects, such as: (Mark all that apply and
list additional aspects.)2.10.3.1. intended use2.10.3.2. user/patient/clinical2.10.3.3. performance characteristics2.10.3.4. safety2.10.3.5. limits and tolerances2.10.3.6. risk analysis2.10.3.7. toxicity and biocompatibility2.10.3.8. electromagnetic compatibility (EMC)2.10.3.9. compatibility with accessories/auxiliary devices2.10.3.10. compatibility with the environment of intended use2.10.3.11. human factors2.10.3.12. physical/chemical characteristics2.10.3.13. labeling/packaging2.10.3.14. reliability2.10.3.15. statutory and regulatory requirements2.10.3.16. voluntary standards2.10.3.17. manufacturing processes2.10.3.18. sterility2.10.3.19. MDRs/complaints/failures and other historical data2.10.3.20. design history files (DHFs)
2.10.4. For the specific design covered, how were the design input requirements identified?2.10.5. For the specific design covered, how were the design input requirements reviewed for
adequacy?
Comply with FDA Design Control Guidance GMP Regulation
1. Capture design and related information1.1. Input electronically formatted data1.2. Reference external information sources1.3. Reference external documentation
2. Store design and related information2.1. Identify and tag design information as unique “design elements”2.2. Organize design elements
2.2.1. Organize by Design Control Guidance Element2.2.2. Organize by inter-relationships
2.3. Ensure all design elements are available2.3.1. Store design elements by Design Control Guidance Element2.3.2. Store design elements and their historical values
3. Manage all user needs3.1. Identify the source of the user need3.2. Identify all user types (groups)3.3. Identify the customer (s)3.4. Profile the expected patients3.5. State the intended use of the product (family)3.6. Capture the acceptance criteria for each user need
4. Manage design input requirements4.1. Identify the source of the requirement4.2. Identify the associated user need4.3. Capture requirement description and attributes4.4. Capture acceptance criteria4.5. Assign responsibility for each requirement4.6. Manage incomplete requirements4.7. Manage ambiguous requirements4.8. Manage conflicting requirements4.9. Approve all requirements
5. Manage acceptance5.1. Ensure the acceptance of every user need5.2. Ensure the acceptance of every design input requirement5.3. Document the results of every user need acceptance test5.4. Document the results of every design input requirements test5.5. Make acceptance results available
6. Manage change6.1. Maintain history of design element changes
6.1.1. Make complete change history available6.1.2. Maintain history within and across any organizational procedure6.1.3. Maintain history within and across any project milestone6.1.4. Maintain history within and across any Design Control Guidance Elements
6.2. Capture frequency and nature of element changes6.2.1. Provide rationale for change6.2.2. Describe decisions made6.2.3. Identify approval authority for the change6.2.4. Capture date, time, and signature of approving authority
6.3. Identify impacted elements due to a change in another element6.3.1. Create backward traces to design elements within and across any organizational procedure6.3.2. Create backward traces to design elements within and across any project milestone
1.1. Identify impacted elements due to a change in another element• Traceability Reports: consistency with driving design elements• Impact Reports: other design elements affected• Links to impacted design elements1.1.1. Create backward traces to design elements within and across any organizational
procedure• Traceability Reports: Procedure Attribute
1.1.2. Create backward traces to design elements within and across any project milestone• Traceability Reports: Milestone Attribute
1.1.3. Create backward traces to design elements within and across Design ControlGuidance Elements• Traceability Reports: Linked design elements
1.1.4. Create forward impacts to design elements within and across any organizationalprocedure• Impact Reports: Procedure Attribute
1.1.5. Create forward impacts to design elements within and across any project milestone• Impact Reports: Milestone Attribute
1.1.6. Create forward impacts to design elements within and across Design ControlGuidance Elements• Impact Reports: Linked design elements
1.2. Associate changed design elements with related elements• Link Change Design Object with affected design element(s)• Traceability Links and Reports from affected design element(s)• Impact Links and Reports from affected design element(s)1.2.1. Associate design element changes with decisions, rationale, and approval authority
information• Change Decision Objects with following Attributes:• Disposition Attribute• Decision Attribute• Rationale Attribute• Owner Attribute• Management Approval Attribute
1.2.2. Provide associations within and across any organizational procedure• Change Design Object Traceability Link on Procedure Attribute• Change Design Object Impacts Link on Procedure Attribute
1.2.3. Provide associations within and across any project milestone• Change Design Object Traceability Link on Milestone Attribute• Change Design Object Impacts Link on Milestone Attribute
1.2.4. Provide associations within and across Design Control Guidance Elements• Change Design Object Traceability Link to traced design elements• Change Design Object Impacts Link to linked design elements
1.3. Mange the change process• Design Change Module• Design Change Reports• Object History• Object History Reports• Versions• Baselines
1. 820.30(b) Design and Development Planning
Each manufacturer shall establish and maintain plans that describe or reference the design and developmentactivities and define responsibility for implementation.
The plans shall identify and describe the interfaces with different groups or activities that provide, or resultin, input to the design and development process.
The plans shall be reviewed as design and development evolves.The plans shall be updated as design and development evolves.The plans shall be approved as design and development evolves.
2. 820.30(c) Design Input2.1. Each manufacturer shall establish procedures to ensure that the design requirements relating to a
device are appropriate and address the intended use of the device, including the needs of the userand patient.
2.2. Each manufacturer shall maintain procedures to ensure that the design requirements relating to adevice are appropriate and address the intended use of the device, including the needs of the userand patient.
2.3. The procedures shall include a mechanism for addressing incomplete requirements.2.4. The procedures shall include a mechanism for addressing ambiguous requirements.2.5. The procedures shall include a mechanism for addressing conflicting requirements.2.6. The design input requirements shall be documented by a designated individual(s).2.7. The design input requirements shall be reviewed by a designated individual(s).2.8. The design input requirements shall be approved by a designated individual(s).2.9. The approval, including the date and signature of the individual(s) approving the requirements,
shall be documented.2.10. Questions.
2.10.1. Summarize the manufacturer's written procedure(s) for identification and control ofdesign input.
2.10.2. From what sources are design inputs sought?2.10.3. Do design input procedures cover the relevant aspects, such as: (Mark all that apply and
list additional aspects.)2.10.3.1. intended use2.10.3.2. user/patient/clinical2.10.3.3. performance characteristics2.10.3.4. safety2.10.3.5. limits and tolerances2.10.3.6. risk analysis2.10.3.7. toxicity and biocompatibility2.10.3.8. electromagnetic compatibility (EMC)2.10.3.9. compatibility with accessories/auxiliary devices2.10.3.10. compatibility with the environment of intended use2.10.3.11. human factors2.10.3.12. physical/chemical characteristics2.10.3.13. labeling/packaging2.10.3.14. reliability2.10.3.15. statutory and regulatory requirements2.10.3.16. voluntary standards2.10.3.17. manufacturing processes2.10.3.18. sterility2.10.3.19. MDRs/complaints/failures and other historical data2.10.3.20. design history files (DHFs)
2.10.4. For the specific design covered, how were the design input requirements identified?2.10.5. For the specific design covered, how were the design input requirements reviewed for
adequacy?
Comply with FDA Design Control Guidance GMP Regulation
1. Capture design and related information1.1. Input electronically formatted data1.2. Reference external information sources1.3. Reference external documentation
2. Store design and related information2.1. Identify and tag design information as unique “design elements”2.2. Organize design elements
2.2.1. Organize by Design Control Guidance Element2.2.2. Organize by inter-relationships
2.3. Ensure all design elements are available2.3.1. Store design elements by Design Control Guidance Element2.3.2. Store design elements and their historical values
3. Manage all user needs3.1. Identify the source of the user need3.2. Identify all user types (groups)3.3. Identify the customer (s)3.4. Profile the expected patients3.5. State the intended use of the product (family)3.6. Capture the acceptance criteria for each user need
4. Manage design input requirements4.1. Identify the source of the requirement4.2. Identify the associated user need4.3. Capture requirement description and attributes4.4. Capture acceptance criteria4.5. Assign responsibility for each requirement4.6. Manage incomplete requirements4.7. Manage ambiguous requirements4.8. Manage conflicting requirements4.9. Approve all requirements
5. Manage acceptance5.1. Ensure the acceptance of every user need5.2. Ensure the acceptance of every design input requirement5.3. Document the results of every user need acceptance test5.4. Document the results of every design input requirements test5.5. Make acceptance results available
6. Manage change6.1. Maintain history of design element changes
6.1.1. Make complete change history available6.1.2. Maintain history within and across any organizational procedure6.1.3. Maintain history within and across any project milestone6.1.4. Maintain history within and across any Design Control Guidance Elements
6.2. Capture frequency and nature of element changes6.2.1. Provide rationale for change6.2.2. Describe decisions made6.2.3. Identify approval authority for the change6.2.4. Capture date, time, and signature of approving authority
6.3. Identify impacted elements due to a change in another element6.3.1. Create backward traces to design elements within and across any organizational procedure6.3.2. Create backward traces to design elements within and across any project milestone
1.1. Identify impacted elements due to a change in another element• Traceability Reports: consistency with driving design elements• Impact Reports: other design elements affected• Links to impacted design elements1.1.1. Create backward traces to design elements within and across any organizational
procedure• Traceability Reports: Procedure Attribute
1.1.2. Create backward traces to design elements within and across any project milestone• Traceability Reports: Milestone Attribute
1.1.3. Create backward traces to design elements within and across Design ControlGuidance Elements• Traceability Reports: Linked design elements
1.1.4. Create forward impacts to design elements within and across any organizationalprocedure• Impact Reports: Procedure Attribute
1.1.5. Create forward impacts to design elements within and across any project milestone• Impact Reports: Milestone Attribute
1.1.6. Create forward impacts to design elements within and across Design ControlGuidance Elements• Impact Reports: Linked design elements
1.2. Associate changed design elements with related elements• Link Change Design Object with affected design element(s)• Traceability Links and Reports from affected design element(s)• Impact Links and Reports from affected design element(s)1.2.1. Associate design element changes with decisions, rationale, and approval authority
information• Change Decision Objects with following Attributes:• Disposition Attribute• Decision Attribute• Rationale Attribute• Owner Attribute• Management Approval Attribute
1.2.2. Provide associations within and across any organizational procedure• Change Design Object Traceability Link on Procedure Attribute• Change Design Object Impacts Link on Procedure Attribute
1.2.3. Provide associations within and across any project milestone• Change Design Object Traceability Link on Milestone Attribute• Change Design Object Impacts Link on Milestone Attribute
1.2.4. Provide associations within and across Design Control Guidance Elements• Change Design Object Traceability Link to traced design elements• Change Design Object Impacts Link to linked design elements
1.3. Mange the change process• Design Change Module• Design Change Reports• Object History• Object History Reports• Versions• Baselines
User Reqts Technical Reqts Test CasesDesign
INFO2110 – Systems Analysis and Modelling – Lecture 2 | Presenter – John Macleod | 7-Aug-12 | © Copyright IBM Corporation 2012
INFO2110 – Lecture 2 Presenter – Paul Zervos and John MacLeod
13 7-Aug-12© Copyright IBM Corporation 2012
Traceability view
1. 820.30(b) Design and Development Planning
Each manufacturer shall establish and maintain plans that describe or reference the design and developmentactivities and define responsibility for implementation.
The plans shall identify and describe the interfaces with different groups or activities that provide, or resultin, input to the design and development process.
The plans shall be reviewed as design and development evolves.The plans shall be updated as design and development evolves.The plans shall be approved as design and development evolves.
2. 820.30(c) Design Input2.1. Each manufacturer shall establish procedures to ensure that the design requirements relating to a
device are appropriate and address the intended use of the device, including the needs of the userand patient.
2.2. Each manufacturer shall maintain procedures to ensure that the design requirements relating to adevice are appropriate and address the intended use of the device, including the needs of the userand patient.
2.3. The procedures shall include a mechanism for addressing incomplete requirements.2.4. The procedures shall include a mechanism for addressing ambiguous requirements.2.5. The procedures shall include a mechanism for addressing conflicting requirements.2.6. The design input requirements shall be documented by a designated individual(s).2.7. The design input requirements shall be reviewed by a designated individual(s).2.8. The design input requirements shall be approved by a designated individual(s).2.9. The approval, including the date and signature of the individual(s) approving the requirements,
shall be documented.2.10. Questions.
2.10.1. Summarize the manufacturer's written procedure(s) for identification and control ofdesign input.
2.10.2. From what sources are design inputs sought?2.10.3. Do design input procedures cover the relevant aspects, such as: (Mark all that apply and
list additional aspects.)2.10.3.1. intended use2.10.3.2. user/patient/clinical2.10.3.3. performance characteristics2.10.3.4. safety2.10.3.5. limits and tolerances2.10.3.6. risk analysis2.10.3.7. toxicity and biocompatibility2.10.3.8. electromagnetic compatibility (EMC)2.10.3.9. compatibility with accessories/auxiliary devices2.10.3.10. compatibility with the environment of intended use2.10.3.11. human factors2.10.3.12. physical/chemical characteristics2.10.3.13. labeling/packaging2.10.3.14. reliability2.10.3.15. statutory and regulatory requirements2.10.3.16. voluntary standards2.10.3.17. manufacturing processes2.10.3.18. sterility2.10.3.19. MDRs/complaints/failures and other historical data2.10.3.20. design history files (DHFs)
2.10.4. For the specific design covered, how were the design input requirements identified?2.10.5. For the specific design covered, how were the design input requirements reviewed for
adequacy?
Comply with FDA Design Control Guidance GMP Regulation
1. Capture design and related information1.1. Input electronically formatted data1.2. Reference external information sources1.3. Reference external documentation
2. Store design and related information2.1. Identify and tag design information as unique “design elements”2.2. Organize design elements
2.2.1. Organize by Design Control Guidance Element2.2.2. Organize by inter-relationships
2.3. Ensure all design elements are available2.3.1. Store design elements by Design Control Guidance Element2.3.2. Store design elements and their historical values
3. Manage all user needs3.1. Identify the source of the user need3.2. Identify all user types (groups)3.3. Identify the customer (s)3.4. Profile the expected patients3.5. State the intended use of the product (family)3.6. Capture the acceptance criteria for each user need
4. Manage design input requirements4.1. Identify the source of the requirement4.2. Identify the associated user need4.3. Capture requirement description and attributes4.4. Capture acceptance criteria4.5. Assign responsibility for each requirement4.6. Manage incomplete requirements4.7. Manage ambiguous requirements4.8. Manage conflicting requirements4.9. Approve all requirements
5. Manage acceptance5.1. Ensure the acceptance of every user need5.2. Ensure the acceptance of every design input requirement5.3. Document the results of every user need acceptance test5.4. Document the results of every design input requirements test5.5. Make acceptance results available
6. Manage change6.1. Maintain history of design element changes
6.1.1. Make complete change history available6.1.2. Maintain history within and across any organizational procedure6.1.3. Maintain history within and across any project milestone6.1.4. Maintain history within and across any Design Control Guidance Elements
6.2. Capture frequency and nature of element changes6.2.1. Provide rationale for change6.2.2. Describe decisions made6.2.3. Identify approval authority for the change6.2.4. Capture date, time, and signature of approving authority
6.3. Identify impacted elements due to a change in another element6.3.1. Create backward traces to design elements within and across any organizational procedure6.3.2. Create backward traces to design elements within and across any project milestone
1.1. Identify impacted elements due to a change in another element• Traceability Reports: consistency with driving design elements• Impact Reports: other design elements affected• Links to impacted design elements1.1.1. Create backward traces to design elements within and across any organizational
procedure• Traceability Reports: Procedure Attribute
1.1.2. Create backward traces to design elements within and across any project milestone• Traceability Reports: Milestone Attribute
1.1.3. Create backward traces to design elements within and across Design ControlGuidance Elements• Traceability Reports: Linked design elements
1.1.4. Create forward impacts to design elements within and across any organizationalprocedure• Impact Reports: Procedure Attribute
1.1.5. Create forward impacts to design elements within and across any project milestone• Impact Reports: Milestone Attribute
1.1.6. Create forward impacts to design elements within and across Design ControlGuidance Elements• Impact Reports: Linked design elements
1.2. Associate changed design elements with related elements• Link Change Design Object with affected design element(s)• Traceability Links and Reports from affected design element(s)• Impact Links and Reports from affected design element(s)1.2.1. Associate design element changes with decisions, rationale, and approval authority
information• Change Decision Objects with following Attributes:• Disposition Attribute• Decision Attribute• Rationale Attribute• Owner Attribute• Management Approval Attribute
1.2.2. Provide associations within and across any organizational procedure• Change Design Object Traceability Link on Procedure Attribute• Change Design Object Impacts Link on Procedure Attribute
1.2.3. Provide associations within and across any project milestone• Change Design Object Traceability Link on Milestone Attribute• Change Design Object Impacts Link on Milestone Attribute
1.2.4. Provide associations within and across Design Control Guidance Elements• Change Design Object Traceability Link to traced design elements• Change Design Object Impacts Link to linked design elements
1.3. Mange the change process• Design Change Module• Design Change Reports• Object History• Object History Reports• Versions• Baselines
1. 820.30(b) Design and Development Planning
Each manufacturer shall establish and maintain plans that describe or reference the design and developmentactivities and define responsibility for implementation.
The plans shall identify and describe the interfaces with different groups or activities that provide, or resultin, input to the design and development process.
The plans shall be reviewed as design and development evolves.The plans shall be updated as design and development evolves.The plans shall be approved as design and development evolves.
2. 820.30(c) Design Input2.1. Each manufacturer shall establish procedures to ensure that the design requirements relating to a
device are appropriate and address the intended use of the device, including the needs of the userand patient.
2.2. Each manufacturer shall maintain procedures to ensure that the design requirements relating to adevice are appropriate and address the intended use of the device, including the needs of the userand patient.
2.3. The procedures shall include a mechanism for addressing incomplete requirements.2.4. The procedures shall include a mechanism for addressing ambiguous requirements.2.5. The procedures shall include a mechanism for addressing conflicting requirements.2.6. The design input requirements shall be documented by a designated individual(s).2.7. The design input requirements shall be reviewed by a designated individual(s).2.8. The design input requirements shall be approved by a designated individual(s).2.9. The approval, including the date and signature of the individual(s) approving the requirements,
shall be documented.2.10. Questions.
2.10.1. Summarize the manufacturer's written procedure(s) for identification and control ofdesign input.
2.10.2. From what sources are design inputs sought?2.10.3. Do design input procedures cover the relevant aspects, such as: (Mark all that apply and
list additional aspects.)2.10.3.1. intended use2.10.3.2. user/patient/clinical2.10.3.3. performance characteristics2.10.3.4. safety2.10.3.5. limits and tolerances2.10.3.6. risk analysis2.10.3.7. toxicity and biocompatibility2.10.3.8. electromagnetic compatibility (EMC)2.10.3.9. compatibility with accessories/auxiliary devices2.10.3.10. compatibility with the environment of intended use2.10.3.11. human factors2.10.3.12. physical/chemical characteristics2.10.3.13. labeling/packaging2.10.3.14. reliability2.10.3.15. statutory and regulatory requirements2.10.3.16. voluntary standards2.10.3.17. manufacturing processes2.10.3.18. sterility2.10.3.19. MDRs/complaints/failures and other historical data2.10.3.20. design history files (DHFs)
2.10.4. For the specific design covered, how were the design input requirements identified?2.10.5. For the specific design covered, how were the design input requirements reviewed for
adequacy?
Comply with FDA Design Control Guidance GMP Regulation
1. Capture design and related information1.1. Input electronically formatted data1.2. Reference external information sources1.3. Reference external documentation
2. Store design and related information2.1. Identify and tag design information as unique “design elements”2.2. Organize design elements
2.2.1. Organize by Design Control Guidance Element2.2.2. Organize by inter-relationships
2.3. Ensure all design elements are available2.3.1. Store design elements by Design Control Guidance Element2.3.2. Store design elements and their historical values
3. Manage all user needs3.1. Identify the source of the user need3.2. Identify all user types (groups)3.3. Identify the customer (s)3.4. Profile the expected patients3.5. State the intended use of the product (family)3.6. Capture the acceptance criteria for each user need
4. Manage design input requirements4.1. Identify the source of the requirement4.2. Identify the associated user need4.3. Capture requirement description and attributes4.4. Capture acceptance criteria4.5. Assign responsibility for each requirement4.6. Manage incomplete requirements4.7. Manage ambiguous requirements4.8. Manage conflicting requirements4.9. Approve all requirements
5. Manage acceptance5.1. Ensure the acceptance of every user need5.2. Ensure the acceptance of every design input requirement5.3. Document the results of every user need acceptance test5.4. Document the results of every design input requirements test5.5. Make acceptance results available
6. Manage change6.1. Maintain history of design element changes
6.1.1. Make complete change history available6.1.2. Maintain history within and across any organizational procedure6.1.3. Maintain history within and across any project milestone6.1.4. Maintain history within and across any Design Control Guidance Elements
6.2. Capture frequency and nature of element changes6.2.1. Provide rationale for change6.2.2. Describe decisions made6.2.3. Identify approval authority for the change6.2.4. Capture date, time, and signature of approving authority
6.3. Identify impacted elements due to a change in another element6.3.1. Create backward traces to design elements within and across any organizational procedure6.3.2. Create backward traces to design elements within and across any project milestone
1.1. Identify impacted elements due to a change in another element• Traceability Reports: consistency with driving design elements• Impact Reports: other design elements affected• Links to impacted design elements1.1.1. Create backward traces to design elements within and across any organizational
procedure• Traceability Reports: Procedure Attribute
1.1.2. Create backward traces to design elements within and across any project milestone• Traceability Reports: Milestone Attribute
1.1.3. Create backward traces to design elements within and across Design ControlGuidance Elements• Traceability Reports: Linked design elements
1.1.4. Create forward impacts to design elements within and across any organizationalprocedure• Impact Reports: Procedure Attribute
1.1.5. Create forward impacts to design elements within and across any project milestone• Impact Reports: Milestone Attribute
1.1.6. Create forward impacts to design elements within and across Design ControlGuidance Elements• Impact Reports: Linked design elements
1.2. Associate changed design elements with related elements• Link Change Design Object with affected design element(s)• Traceability Links and Reports from affected design element(s)• Impact Links and Reports from affected design element(s)1.2.1. Associate design element changes with decisions, rationale, and approval authority
information• Change Decision Objects with following Attributes:• Disposition Attribute• Decision Attribute• Rationale Attribute• Owner Attribute• Management Approval Attribute
1.2.2. Provide associations within and across any organizational procedure• Change Design Object Traceability Link on Procedure Attribute• Change Design Object Impacts Link on Procedure Attribute
1.2.3. Provide associations within and across any project milestone• Change Design Object Traceability Link on Milestone Attribute• Change Design Object Impacts Link on Milestone Attribute
1.2.4. Provide associations within and across Design Control Guidance Elements• Change Design Object Traceability Link to traced design elements• Change Design Object Impacts Link to linked design elements
1.3. Mange the change process• Design Change Module• Design Change Reports• Object History• Object History Reports• Versions• Baselines
Stakeholder Reqts System Reqts Test CasesSubsystemAcceptance
test
validating the product
StakeholderRequirements
Statement of need(Capability)
Operational use
satisfies
ComponentRequirements
Component test
evaluating components
SubsystemRequirements
Subsystem test
evaluating the subsystemssatisfies
SystemRequirements
System test
verifying the systemsatisfies
Acceptance test
validating the product
StakeholderRequirements
Acceptance test
validating the product
StakeholderRequirements
Acceptance test
validating the product
StakeholderRequirements
Statement of need(Capability)
Operational use
satisfies
ComponentRequirements
Component test
evaluating componentssatisfies
ComponentRequirements
Component test
evaluating components
ComponentRequirements
Component test
evaluating components
SubsystemRequirements
Subsystem test
evaluating the subsystemssatisfies
SubsystemRequirements
Subsystem test
evaluating the subsystemssatisfies
SystemRequirements
System test
verifying the systemsatisfies
SystemRequirements
System test
verifying the systemsatisfies
INFO2110 – Systems Analysis and Modelling – Lecture 2 | Presenter – John Macleod | 7-Aug-12 | © Copyright IBM Corporation 2012
System Architectural DesignDocument
Requirements
Business (BR) Marketing(MR) Technical(TR)
Internal(IR) UCFs & SILs
Product Aspect Specification Document
Subsystem Specification Document
Subsystem Specification Document
Subsystem Design Document
Subsystem Design
Document
ACUS Global Glossary
The Unisys Documentation Set
SADD
SSD
SDD
PASD
CM Change
Proposals
Traceability
And Change Control
Code
INFO2110 – Systems Analysis and Modelling – Lecture 2 | Presenter – John Macleod | 7-Aug-12 | © Copyright IBM Corporation 2012
Good Practice 4: Use concise, clear, consistent language
Each requirement statement should be:
1. Individual: each statement is a single traceable element
2. Unique: each statement is uniquely identified3. Clear: each statement is clearly understandable4. Precise: each statement is precise and concise5. Abstract: does not impose a solution on the next layer6. Testable: each statement can be validated/verified 7. Quantified: each statement has acceptance criteria
INFO2110 – Systems Analysis and Modelling – Lecture 2 | Presenter – John Macleod | 7-Aug-12 | © Copyright IBM Corporation 2012
Six Things to Avoid
1. Rambling: conciseness is a virtue2. Let-out clauses: such as “if that should be necessary”;
they render the requirements useless3. Multiple requirements: often indicated by “and”, “or”,
“but”, “however”4. Vague terms: usually, generally, often, normally,
typically, user friendly, versatile, flexible5. Wishful thinking: “100% reliable”, “please all users”,
“run on all platforms”, handle all unexpected failures”, “upgradeable to all future situations”
6. Speculation: stick to what you know
Good Practice: Use concise, clear, consistent language
INFO2110 – Systems Analysis and Modelling – Lecture 2 | Presenter – John Macleod | 7-Aug-12 | © Copyright IBM Corporation 2012
Monitoring Progress based on requirements state
• Number (or %) of input requirements agreed
• Number (or %) of input requirements that have derived requirements linked to them
• Number (or %) of derived requirements in each requirement state (e.g. Draft, Proposed, Reviewed, Rejected)
• Number (or %) of derived requirements that have qualification activities linked to them
• Number (or %) of derived requirements in each qualification state (e.g. No qualification agreed, Qualification agreed, Qualification suspect)
• Number (or %) of input requirements with a change pending
INFO2110 – Systems Analysis and Modelling – Lecture 2 | Presenter – John Macleod | 7-Aug-12 | © Copyright IBM Corporation 2012
Agenda
• The case for requirements management• Good Requirements Management Practices• Excuses!
INFO2110 – Systems Analysis and Modelling – Lecture 2 | Presenter – John Macleod | 7-Aug-12 | © Copyright IBM Corporation 2012
INFO2110 – Lecture 2 Presenter – Paul Zervos and John MacLeod
14 7-Aug-12© Copyright IBM Corporation 2012
Real Results
• Project • Requirements Management in
Rational DOORS• Build - some Agile techniques
• Change Requests• Expected 20• Actual 3
• UAT• Expected 20• Actual 2
� Rework�Expected 20
�Actual 0
� Requirements Acquittal�Expected 80%
�Actual 125%
� Business Benefits Realisation�Expected 80%
�Actual 110%
INFO2110 – Systems Analysis and Modelling – Lecture 2 | Presenter – John Macleod | 7-Aug-12 | © Copyright IBM Corporation 2012
REQUIREMENTS MANAGEMENT
FROM AN INDUSTRY PERSPECTIVE
John MacLeod - <john.macleod@au1.ibm.com>
INFO2110 – Systems Analysis and Modelling – Lecture 2 | Presenter – John Macleod | 7-Aug-12 | © Copyright IBM Corporation 2012