info2110 – lecture 2 presenter – paul zervos and john macleod · 7. • • • • • • •...

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


© 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



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.


Business Analyst

Role

Define and Scope

Business Area

Elicit Requirements

Analyse and Document

Requirements

Communicate Requirements

Validate Requirements



The Role of the Business Analyst




Project Team Without A Business Analyst




The Need for a Business Analyst






Cost of Requirements Errors

The later you catch an error the more it costs to f ix!



Phase

Relative Cost

MissingRequirement

DefectiveLogic

DesignErrorMissing

Function

FaultyItemsMissing

Test Case

OperationalFailure



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.



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.


Business

Stakeholder

Solution

Functional Non-Functional



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.


� FURPSS

–Functionality

–Usability

–Reliability

–Performance

–Supportability

–Security

� +

–Design requirements

– Implementation Requirements

– Interface Requirements

–Physical Requirements

Functional

Requirements

Non-Functional

Requirements



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




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






Relationships between user needs, concerns and NFRs


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



Requirements must be SMART!

� S pecific

� M easurable

� A ttainable

� R ealistic

� T ime-bound




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




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.


� 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


© 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.



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)






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




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




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




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




� 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




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






Question Types

NOTE: Avoid leading questions!


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?



Interviewing Strategies


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



Post-Interview

� Prepare notes and send to the interviewee for verification




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




JAD / Workshop Tips


� 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



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.)






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




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




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




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




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




Common mistakes


� The “shopping cart” mentality

–Ensure stakeholders understand the “cost” of their purchases





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.




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.




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.




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.




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.




The End


Feel free to contact me if you have any further questions [email protected]



REQUIREMENTS MANAGEMENT

FROM AN INDUSTRY PERSPECTIVE

John MacLeod - <[email protected]>

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


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”


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


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.


Phase

Relative Cost

MissingRequirement

DefectiveLogic

DesignErrorMissing

Function

FaultyItemsMissing

Test Case

OperationalFailure


The oldest (IT) joke in the book




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”


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”


But When Requirements are Right…


Why are better requirements needed?

Requirements Management is a High Leverage Activity

“Quality is free” Phillip Crosby


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


Requirements Are Everywhere

RequirementsINFO2110 – Systems Analysis and Modelling – Lecture 2 | Presenter – John Macleod | 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)


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!)


Good Practice 1: Distinguish between Problem and Solution

Problemdefinition

Specificsolution

Abstractsolution

CustomerRequirements

SystemRequirements

Design

Risk of definingthe wrong problem


Example


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


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




HOW DO YOU KNOW WHEN YOU ARE DONE?


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


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


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


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


Impact AnalysisGood Practice: Create, review and use traceability

Acceptance test


satisfies


Component test



Subsystem test


satisfies

SystemRequirements

System test


satisfies





Derivation AnalysisGood Practice: Create, review and use traceability

Acceptance test


satisfies


Component test



Subsystem test


satisfies

SystemRequirements

System test


satisfies



Derivation Coverage AnalysisGood Practice: Create, review and use traceability

Acceptance test


satisfies


Component test



Subsystem test


satisfies

SystemRequirements

System test


satisfies


?

?


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


Using Office Documents

Need to use some tags to identify the element to trace.

Customer’s needs

System Spec


70

Traceability; drag-and-drop linking


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













adequacy?


























User Reqts Technical Reqts Test CasesDesign




Traceability view














adequacy?







































adequacy?


























Stakeholder Reqts System Reqts Test CasesSubsystemAcceptance

test

validating the product

StakeholderRequirements

Statement of need(Capability)

Operational use

satisfies


Component test



Subsystem test

evaluating the subsystemssatisfies

SystemRequirements

System test

verifying the systemsatisfies

Acceptance test



Acceptance test



Acceptance test



Statement of need(Capability)

Operational use

satisfies


Component test

evaluating componentssatisfies


Component test



Component test



Subsystem test



Subsystem test


SystemRequirements

System test


SystemRequirements

System test



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


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


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


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


Agenda

• The case for requirements management• Good Requirements Management Practices• Excuses!




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%


REQUIREMENTS MANAGEMENT

FROM AN INDUSTRY PERSPECTIVE

John MacLeod - <[email protected]>
