Reverse Engineering Testable Requirements

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?


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?


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


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


Defined project requirements

Test case matrices

Scalable

methodologies

Developing a Current Capabilities Assessment


Initiate: Identify Business Sponsor


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


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


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


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


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


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


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:


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


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


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


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


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


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.


Q& A

www.bridging-the-gap.com – read the entire “Current Capabilities Assessment” series

[email protected]

http://www.bridging-the-gap.com/

mailto:[email protected]

Technology

Reverse Engineering Testable Requirements