Joined-up Requirements: Business Goals to System Tests

Transcription

1 Joined-up Requirements: Business Goals to System s Case Study John Cheesman Strata Software john.cheesman@stratasoftware.com Strata Software Ltd

2 Strata Software Requirements specialists Requirements problems Causes of Requirements problems How to fix them Process and Tool specialists Processes and tools go hand in hand Process improvement solutions often involve a combination Pragmatic implementation and support Tool integration Customer-focused Every Customer is different Tailored solutions 2

3 Topics The Requirements problem Case study context Structured Requirements Joined-up processes Tool usage and standards Experiences and Benefits Opportunities and further work 3

4 Drivers for the focus on Requirements Business IT Alignment ( getting it right ) Language and process barrier between Business and IT now acknowledged as major barrier to software project success. IT increasingly considered as a service provider to the business. Business IT Agility ( getting it right quickly ) Quicker time to market / time to deliver value Delivering business value faster which requires clear links from IT activities to business via (structured) requirements & traceable business goals Audit & Compliance ( proving it s right ) Compliance regulations demand clear definitions, risk identification, visibility and traceability across IT projects 4

5 The Requirements Problem More than 60% of all Application Development Projects are seriously challenged or fail 1 #1 Reason for Failed Projects is Poor, Missed or Changing Requirements 30% Project Expenditure due to rework from requirements 2 Reqs Development Production 1 Giga Information Group 2002: Do the Math: Strong Requirements Practices Save Spiralling Project Costs, Margo Visitacion 2 Software copyright Engineering 2005 Institute Strata study, Software 2004 Ltd 5

6 Case Study Context Major UK Bank Early Defect Detection programme Risk-based ing Compuware Optimal Trace Requirements Definition and Management (RDM) tool HP / Mercury Director Strata Software providing best practice Generic requirements standards and processes Tool binding standards Customisation, training and implementation 6

7 Project Scope Define Requirements standards for Optimal Trace Define Requirements process integration with ing (using Director) Requirements Definition Definition 7

8 Structured Requirements Approach Owner Refinement Traceability Change Mgt change change refine refine Business Requirement System Requirement trace trace Business Business / Systems Analyst change Requirement Analyst 8

9 End-to-End Traceability Business Requirement Business Goal Business Process Domain Model System Requirement Business Scenario Requirement Use Case Business Rule Information Model UI NFR Use Case Scenario Data Condition Case Data Script 9

10 Example Structuring in Optimal Trace 10

11 Use Cases specify interactions A Use Case defines the set of interactions between users (actors) and a system to achieve a business goal Each interaction is a sequence of Steps called a Scenario Each Scenario defines a Condition 11

12 Use Case Components Name & ID Actors Goal Steps Main and Alternative Scenarios 12

13 Definition with Optimal Trace End-to-End Traceability Impact Analysis Baselining & Change Control Optimal Trace Requirements Definition Definition Director / Quality Center read-only Definition Planning Execution 13

14 Simplified Process Summary Optimal Trace Requirements Definition Create/Update Requirements High Level Definition Reqs Baseline Create/Update Conditions Case Prep / Planning Definition Baseline Publish To Director [Requirements] read-only Create/Update Cases & Coverage 14

15 Delivery Management Attributes System Requirements derive priority and risk from Business Requirements Development assign Architectural risk (e.g. for nonfunctional reqs) and development complexity Development scheduling applies these attributes within lifecycle methodology (Waterfall, Iterative, Agile,...) Requirements identify Data coverage targets (derived from Risk-based testing) Business Requirement Business Priority Business Risk System Requirement Architectural Risk Development Complexity Requirement Data Coverage Target 15

16 Experiences 1 analysts keen on Structured Requirements In some cases more than Business Analysts TAs are the Customers of requirements BAs are the Suppliers of requirements RDM tools allow practical end-to-end traceability Manual processes error prone Tool standards enforce consistent approach Main roll-out hurdles are cultural / organisational Standard standards Changing working practices for multiple stakeholders Different stakeholders get different benefits Time needed to bed down 16

17 Experiences 2 Pilot projects and incremental roll-out Best approach to new process / tool adoption More effective than big bang standards creation Although projects can have diverse characteristics Take care to avoid creating two tier workforce Ensure communication of business objectives and value Provides important high-level context when down in the weeds Standards provide valuable consistency Supports Requirements and Condition reuse Enables flexible resourcing between projects Enables automation efficiencies 17

18 Selected Benefits 1 Efficient test condition writing Previously manual in a spreadsheet Semi-automatic condition generation from scenarios Requirements & test script traceability Consistent process for change Better change management Easier to see changes to requirements and potential impact on testing Automated baseline comparisons Clearer interfaces between teams BA, Development, Outsourcing / off-shoring partners 18

19 Selected Benefits 2 Graphical visualisation of requirements flow aids understanding and improves quality Integrates story boarding within consistent framework Automatic population of Director saves ers re-keying Requirements reuse Already defined and reviewed double time saving Requirements churn (and quality) visible and quantifiable Facilitates justification of effort and progress Allows governance process to accommodate requirements status 19

20 Further Opportunities Gather concrete metrics over time Quantify benefits across multiple projects Automate (further): Requirements quality reporting Delivery management status Development prioritisation (phases, iteration plans) Requirements evolution reporting Requirements structure analysis 20

21 Questions / Discussion 21