COURSE 3325 | 2-DAY SESSION
Developing and Writing Testable Business Requirements for Software Development and Software Testing

---

Course Outline

I. Why Are Good Business Requirements Needed?

Over ninety percent of the black box test cases should be designed to prove that the business requirements have been met. If business requirements are vague, incorrect or incomplete, then the product will be the same. Regardless of how experienced the development group is, vague or incorrect requirements will lead to a bad product.

a. Vagueness of customer specifications
b. Inability to understand customer’s needs
c. Error in specifications
d. Lack of communication between client and development team
e. Reduce maintenance costs
f. Guidelines for project manager
g. Defining project life cycle

II. How to extract Good Business Requirements from the Specification

Specifications are normally written by the Business Analysts for the client in the clients language. Neither the development group nor the testing group speaks the client’s language. Processes need to be defined that will ensure understanding of the client’s needs from the beginning.

a. Getting a better understanding of user’s needs
b. Need for Functional Requirements (Developers)
c. Need for Business Requirements (Testers)
d. Bringing the two together
e. Needs analysis
f. Requirements walk-thru’s
g. Learn to conduct productive meetings
h. Team organization
i. Questioning techniques
j. Probing for additional information
k. Challenges to be met and overcome
l. Understanding business rules

III. Sources of Information

Where can we find the information we need and how do we go about gathering this information and converting it to usable requirements definitions? Many of the contributors don’t understand how important their knowledge is and what contributions they have to offer and need to be made aware of their specific contributions. The process of getting information and cooperation from these various people will be discussed and demonstrated.

a. Who has information?
b. How do we get these people involved?
c. Defining the gathering process
d. Managing the process
e. Extracting “needs” from & “wants”
f. Defining Critical Success Factors
g. Prioritizing importance

IV. Gathering Information

Setting up and scheduling meetings to create useful information for the rest of the project team to use requires more effective meetings. Inviting people does not guarantee the sharing of information. Processes have to be defined that will create a proactive environment where people will more likely to contribute to the overall success of the project.

a. Scheduling
b. Managing effective meetings
c. Educing required information
d. Developing understanding between client and company
e. Speaking the listener’s language
f. Using templates and checklists

V. Analyzing Information

Once information is available, special processes need to be in place to make this information clear and available to the necessary parties. Schedules, milestones and goals need to be identified and objectives clearly stated. Repeatable processes will ensure the same results each time the process is repeated.

a. Extracting useful business requirements
b. Understanding constraints
c. Designing reasonable and achievable goals
d. Identifying limits
e. Setting milestones

VI. Use Cases

Designing use cases early in the project will help identify for the development team as well as the testing team exactly how the client intends to use the product. A better understanding by the development team at the beginning will prevent a lot of the rework that is often associated with a project that is not clearly understood from the beginning. Vagueness invites rework.

a. Prototypes
b. Models
c. Existing applications
d. Designing regression test cases
e. Traceability matrix
f. Merging white and black box testing

VII. Company Buy-In

Management needs to be a part of this process. Many times management does not understand the significance of clearly stated needs from the beginning and will allow clients to change their minds during the project life cycle (Scope Creep.) This process will invariably add cost and time to the project and almost ensure late delivery. If management can see a better return on investment (ROI), they are more likely to support the process.

a. Presenting process to management
b. Achieving corporate buy-in
c. Project schedules
d. Measuring progress
e. Standards

VIII. Measuring Progress

Metrics need to be collected throughout this entire process to measure how well the project is progressing. Proactive management of this information will help prevent problems from getting out of hand and fixing them while the cost is relatively inexpensive. Metrics also help to identify what areas are weak and need additional resources.

a. Capturing metrics
b. Measuring to manage
c. Reduction in rework
d. Test planning
e. Decreased maintenance costs
f. Status reviews
g. Signoffs

IX. Putting It All Together to Improve Productivity

By instituting better processes from the start we can avoid most of the time and cost of redoing what we have already done. Improved Testable Requirements will produce a better product, decrease maintenance costs, shorten the time to delivery and produce a product that will achieve greater customer satisfaction.

a. Better business requirements will lower development and maintenance costs
b. Improved involvement from other groups will enhance product
c. Decrease project life cycle
d. Closer involvement with Quality Assurance throughout the project
e. Improved documentation make product easier to maintain
f. Developers will have improved understanding of customer’s needs
g. Testers will reduce number of test cases
h. Decrease in maintenance costs
i. Saving the company money