1. © 2000 Technology Builders, Inc. All rights reserved. A Requirements-Based Approach To Delivering E-business and Enterprise Applications Scott Jefferies Technology Engineering Manager Technology Builders, Inc.

2. © 2000 Technology Builders, Inc. All rights reserved. Agenda  Gathering and defining requirements  Performing ambiguity reviews  Managing requirements  Designing test cases  Defining test completion criteria  Other steps in the process

3. © 2000 Technology Builders, Inc. All rights reserved. Gathering and Defining Requirements  Who should be involved:  Business analysts  Users  Other project stakeholders

4. © 2000 Technology Builders, Inc. All rights reserved. Gathering and Defining Requirements  How to gather requirements:  User interviews  Brainstorming  Facilitated sessions  Project specification

5. © 2000 Technology Builders, Inc. All rights reserved. Gathering and Defining Requirements  What to gather:  The requirement itself  “the system shall…”  Attributes  Priority, need, precedence, relationships with other requirements  Supporting information  Graphics, object models, regulations

6. © 2000 Technology Builders, Inc. All rights reserved. Performing Ambiguity Reviews  Who should be involved:  Newest member of the team  Business analysts  Users  Other project stakeholders

7. © 2000 Technology Builders, Inc. All rights reserved. Performing Ambiguity Reviews  Why we should perform ambiguity reviews:  Eliminate ambiguities  Identify conflicts and logic errors  Reorganize requirements for clarity

8. © 2000 Technology Builders, Inc. All rights reserved. Performing Ambiguity Reviews  What we are looking for and how to find them:  Traceability and inconsistency errors  Requirement traces to nothing  Use traceability matrix to identify  Terms used inconsistently

9. © 2000 Technology Builders, Inc. All rights reserved. Performing Ambiguity Reviews  What we are looking for and how to find them:  Imprecise terminology  Acronyms, company- or industry-specific jargon, non-explicit terms (“quickly,” “user-friendly”)  Use outside resource to help identify  Create project glossary to explain terms used

10. © 2000 Technology Builders, Inc. All rights reserved. Imprecise Terminology Exercise How many examples of imprecise terminology can you find in the following: The ATM shall respond quickly and in a user- friendly manner to any user action, and print a TR when the transaction is completed.

11. © 2000 Technology Builders, Inc. All rights reserved. Imprecise Terminology Exercise How many examples of imprecise terminology can you find in the following: The ATM shall respond quickly and in a user- friendly manner to any user action, and print a TR when the transaction is completed.

12. © 2000 Technology Builders, Inc. All rights reserved. Performing Ambiguity Reviews  What we are looking for and how to find them:  Ambiguities  “If the table is next to the chair, then move it.”  Look for exceptions, use outside resource  Logical errors  “If A and B then C” … “If A and B then Not C”  Use cause-effect graphs, rearrange requirements

13. © 2000 Technology Builders, Inc. All rights reserved. Performing Ambiguity Reviews  What we are looking for and how to find them:  Undocumented assumptions  “The system shall perform the calculation in the usual way.”  In-depth interview by business analyst, make inferences

14. © 2000 Technology Builders, Inc. All rights reserved. Performing Ambiguity Reviews  How the requirements are improved:  Become testable  Deterministic, unambiguous, complete, non- redundant, traceable, explicit and feasible  Become easier for developers to work with  Become easier to manage

15. © 2000 Technology Builders, Inc. All rights reserved. Transportation Device Example  Transport one person at a time  Over hard flat surfaces  At speeds not to exceed 20 miles per hour  For distances up to 2 miles  Using only person power for locomotion  Personal comfort is not important ???

16. © 2000 Technology Builders, Inc. All rights reserved. Managing Requirements  What is involved:  Manage changes (errors, new requirements and user requests)  Reduces scope creep due to unnecessary changes  Establish priorities  Focuses development on core set of requirements

17. © 2000 Technology Builders, Inc. All rights reserved. Managing Requirements  What is involved:  Assign responsibilities  Assists in communicating changes  Document rationale  Allows project team to understand why certain decisions were made or changes not made

18. © 2000 Technology Builders, Inc. All rights reserved. Managing Requirements  What is involved:  Trace requirement relationships  Allows impact analysis for more informed decisions  Communicate changes  Allows entire project team to understand current project status and scope

19. © 2000 Technology Builders, Inc. All rights reserved. Managing Requirements  What is involved:  Establish baselines  Tracks scope creep and changes for management  Track requirement histories  Ensures audit trail

20. © 2000 Technology Builders, Inc. All rights reserved. Designing Test Cases  What factors should be considered:  Test cases should be based on requirements  Test data should be designed to provide maximum coverage with minimum number of tests

21. © 2000 Technology Builders, Inc. All rights reserved. Designing Test Cases  What factors should be considered:  Use cause-effect graphing to clarify requirement relationships and testing needs  Group test cases into test sets for ease of execution/organization

22. © 2000 Technology Builders, Inc. All rights reserved. Cause-Effect Graph Example Criteria  If the person is under 18, and plays tennis, then send them a tennis club brochure.  If the person is 18 or older, or has a motorcycle license, then send them a motorcycle club brochure.  If the person was sent both brochures, then put them on the “A” mailing list. You must be 18 or older to have a motorcycle license. [Has License (T) requires 18 Or Older (T)] An d Or An d Under 18 Plays Tennis 18 Or Older Has License Send Tennis Brochure Send Motorcycle Brochure Place on “A” Mailing List E R

23. © 2000 Technology Builders, Inc. All rights reserved. Designing Test Cases  How testers are currently designing tests:  “Gut feel”  Live data  Brute force combinations

24. © 2000 Technology Builders, Inc. All rights reserved. Designing Test Cases  Why current methods fall short:  Too many tests, too little time  Varying skill levels and experience  Not enough coverage (functional or code) to ensure system integrity

25. © 2000 Technology Builders, Inc. All rights reserved. Designing Test Cases  The solution:  Use scientific methods to produce the minimum number of test cases that will validate all of the functional requirements  Result: 100% functionality coverage and 85%-90% code coverage on the first pass

26. © 2000 Technology Builders, Inc. All rights reserved. Reviewing Test Cases  Who should be involved:  Spec writer  User/domain experts  Developers  Why this is important:  Minimizes misunderstandings

27. © 2000 Technology Builders, Inc. All rights reserved. Defining Test Completion Criteria  Why this is important:  Sets policy for when software will be considered for release  What should be specified:  Which tests must have been performed  Which tests must have passed  How many iterations of the testing cycle need to be clean

28. © 2000 Technology Builders, Inc. All rights reserved. Other Steps in the Process  Build tests  Execute tests and verify results  Verify test and functional coverage  Track defects  Manage repositories

29. © 2000 Technology Builders, Inc. All rights reserved. Summary  Gather and define requirements  Analyze them to eliminate ambiguities, conflicts and other errors  Manage requirements and their evolution throughout the development cycle  Design and build test cases based upon the requirements  Review test cases with spec writer, user/domain experts, developers

30. © 2000 Technology Builders, Inc. All rights reserved. Summary  Define test completion criteria  Execute tests and verify results  Verify test coverage  Track defects  Manage the requirements, test, code and defect repositories

31. © 2000 Technology Builders, Inc. All rights reserved. Questions?