reverse engineering testable requirements
TRANSCRIPT
Reverse Engineering Testable Requirements:Current Capabilities Assessments
SQuAD Conference: March 12, 2009Laura Brandau
What is a Current Capabilities Assessment?
12/09/09Clear Spring Business Analysis2
“Just enough” of each to meet your business goals.
What problem are we trying to solve?
12/09/09Clear Spring Business Analysis3
No comprehensive understanding of the system’s functionality
Causes issues because: New projects overlook
requirements implications Inability to fully regression
test
Why does this happen?
12/09/09Clear Spring Business Analysis4
People leave Organizations change focus We can build IT systems without documentation (gasp!)
“Chaos in the world brings uneasiness, but it also allows the opportunity for creativity and growth.”-Tom Barrett
Why QA
12/09/09Clear Spring Business Analysis5
WHY NOT?
You have 4 choices: Wait for someone else to do it, Hire someone else to do it, Tell someone else to do it, (this isn’t available to most of us) Do it.
Current Capabilities Assessment in Context
12/09/09Clear Spring Business Analysis6
Defined project requirements
Test case matrices
Scalable
methodologies
Initiate: Identify Business Sponsor
12/09/09Clear Spring Business Analysis8
Who Your manager or other manager/executive-level sponsor.
What do they do? Guide the project Keep you informed of organizational goals Gain support across the organization Help you define scope Help you identify subject matter experts
Initiate: Define Scope: Business Goals and Systems
12/09/09Clear Spring Business Analysis9
Business Goals What value does this project provide to
your organization? For example,
Decrease coding errors released to production
Decrease requirements discovered late in the project
Systems and Functionality Select systems or components within
systems Use a system context diagram to create
a visual picture
Initiate: Define Scope: Identifying Deliverables
12/09/09Clear Spring Business Analysis10
Varying levels of detail are possible. Select from the following to meet your business goals
Features List Use Case List Actor/Use Case Diagram Use Cases Test Case List Test Case Scenarios Site Map
Mix and match, but all detailed deliverables should roll-up to a “list”
Prepare: Explore the System
12/09/09Clear Spring Business Analysis11
Learn everything you can before engaging your SMEs in detailed discussions
Consider a high-level demo to kick-start your exploration
As you explore, build a list of pages, functions, etc Keep a list of questions to ask Time Box
Force yourself to explore for a few hours Limit to 3-4 hours
Stop exploring any given page/function when you’re stuck
Prepare: Create a Plan
12/09/09Clear Spring Business Analysis12
Use your preliminary list as a planning tool Identify what you know about each item List the next step
Can you document a use case or test case? Do it. Do you not understand this at all? Ask someone to show you. Do you have the basic idea but need to fill in a few details? List what
you know and your questions.
Review your list with your sponsor, validate what you have learned.
Identify stakeholders for each item on your list. They will demo functionality, answer questions, and/or review your documentation.
Gather Information
12/09/09Clear Spring Business Analysis13
Start with business SMEs first, fill in the technical details later.
Establish trust—explain what you are doing and why you need their help.
Be prepared—have a defined agenda and set of questions whenever possible.
Let them talk. Ask them to show you how they use the system and explain their business process.
Meet them in their desk if possible. Ask why. Why. Why. (Well, don’t be
too annoying.)
Gather Information: Rooting Out Requirements
12/09/09Clear Spring Business Analysis14
People often speak about effects—what the system does for them.
Ask why, how, what questions to get at the cause….
…often you’ll find the hidden gems of system functionality or lost business rules.
Rooting Out Requirements
Happy Path only: Speak in Exceptions:
12/09/09Clear Spring Business Analysis15
Be wary if nothing diverges from the main path; you’re not getting the whole story
Drive out issues: Does every record move to
the next step? Are some records handled
specially? What kinds of issues happen
here? What are some of the things
you look for in this process?
It can be difficult to understand the happy path if your SME focuses on what goes wrong.
Refocus the conversation: If that doesn’t go wrong, what
happens? Does every record go through
that process? How often does that happen? Tell me about a “perfect”
record.
Rooting out Requirements
12/09/09Clear Spring Business Analysis16
Watch for unexplained specificities This happens every Tuesday I get an email from Barb in accounting I download this into Excel and then email it.
Take a position of curiosity Take a 10 minute break to review your notes. You’ll
often come up with more questions.
Synthesize and Validate
12/09/09Clear Spring Business Analysis17
Goal: Synthesize what you’ve learned and identify gaps. Useful analysis tips
Type up meeting notes with “what you heard” Coalesce notes into “what it means” – slot everything against your
list. Start drafting documents Diagram work-flows that are confusing. Create spreadsheets to visualize complex relationships. Step through a process with one record from beginning to end.
Be SELF-AWARE Stop if you are stuck, frame up what you know and what you don’t. Re-synthesize.
Synthesize and Validate
12/09/09Clear Spring Business Analysis18
Goal: Final output that can be consumed by others. Create clean, clear, extensible documentation Validate documents with SMEs by conducting a document
review Is it testable? Use it.
If test cases, can you run them against the system? If use cases, can you create meaningful test cases?
Maintain
12/09/09Clear Spring Business Analysis19
Without a maintenance process, the assessment will be out-of-date as soon as the next production release.
Integrate maintenance of documentation into your project process…usually a post-project deliverable.
Stick to it.
Re-Cap
12/09/09Clear Spring Business Analysis20
It’s easy to find yourself in this situation. Don’t fret. Link a Current Capabilities Assessment to business
objectives. Create a balance between preparation and gathering
information. Focus on analyzing everything you hear and “rooting out”
requirements. Engage the business, then the development team. Create clean, reusable documentation and validate it. Establish a maintenance process.
12/09/09Clear Spring Business Analysis21
Q& A
www.bridging-the-gap.com – read the entire “Current Capabilities Assessment” series