1. 1 Text Layout Introduction (1-4) Team Skill 1 – Analyzing the problem (5-7) Team Skill 2 – Understanding User and Stakeholder Needs (8-13) Team Skill 3 – Defining the System (14-17) Team Skill 4 – Managing Scope (18-19) Team Skill 5 – Refining the System Definition ( 20-24) Team Skill 6 – Building the Right System (25-31)

2. 2 From Use Cases to Implementation Chapter 25

3. 3 Use Cases to Implementation For 40 years, we have built complex software systems  Not all failures – Internet, online trading, desktop productivity tools, lifesaving medical equipment, safe power plants, and communications Some systems conform to their requirements, but others that require a high degree of safety or reliability do not Requirements do not lend themselves to being exposed for inspection within implementation Proving that any particular requirement is fulfilled in the code is a nontrivial matter

4. 4 Mapping Requirements to Design and Code Trace requirements to Design Code modules  Test modules for requirement satisfaction Some traces are straight-forward and easy to do…  Support up to an eight-digit floating-point parameter  Indicate compilation progress to the user Requirement √ Design Progress Monitor ID header Implementation Progress1 = True ElseIf (WminSc <> WMAXSc) Then ProgressBar1.Max = WMaxSc

5. 5 The Orthogonality Problem There is little correlation between the requirement, the design, and the implementation, they are orthogonal The form of our requirements and the form of our design and implementation are different There is no one-to-one mapping to make implementation and verification easier  Requirements speak in real-world terms, code speaks in stacks, queues, and algorithms  Some requirements, performance, have little to do with the logical structure of the code, but a lot to do with the process structure  Some functional requirements require that a number of system elements interact to achieve the functionality  Most importantly, good system design is not driven optimizing the ease of proving requirement satisfaction

6. 6 Object Orientation Applying OO concepts, we build code entities that are a better match to the problem domain, and this improved the mapping  People still get paychecks today, but they may be electronically  With OO, we started to find paycheck objects However, requirements are still functional in nature, not object oriented, so some degree of orthogonality will still exist

7. 7 Use Case as a Requirement Use cases provide a sequence of actions between the system and the user  This improves the mapping significantly  Now the requirements do a better job of providing the behavior of the system in a sequential fashion Using OO and use cases increase the parallels between requirements and code A better understanding of the requirements should help to drive a better design

8. 8 Modeling Software System Modeling aids in our understanding and communicating that understanding of the system Purpose: to simplify the details down to an understandable “essence” but not to oversimplify to the point that the model does not adequately represent the system Model is a powerful way to reason about a complex problem and to derive useful thought The Model is not reality; it must evolve Many different aspects of the system can be modeled  Application concurrency  Logical structure  Process structure

9. 9 Architecture of Software Systems Shaw and Garlan definition  Description of elements from which systems are built, interactions amongst those elements, patterns that guide their composition, and constraints on those patterns  Components and connectors According to Krutchen, we use architecture to…  Understand what the system does  Understand how the system works  Think and work on pieces of the system  Extend the system  Reuse part(s) of the system to build another one 4+1 View of Architecture  Logical View, Implementation View, Process View, and Deployment View are all tied together with the Use-case View

10. 10 HOLIS Use-Case Initiate Emergency Sequence Impacts the design in all four views Feature: The system has a built-in security feature that provides a one-button, panic alarm emergency sequence activation from any control switch in the house. The security sequence sets the lights to a predetermined scene setting and will also flash the lights, activate an alarm, make a dial-up call, and deliver a voice-based message  Logical view would describe the various classes and subsystems that implement the behaviors called for by the emergency sequence functionality  Implementation view would describe the various code artifacts for HOLIS, including source and executable files  Process view would demonstrate how the multitasking capability of HOLIS was always available to initiate an emergency sequence  Deployment view would show that we distrubuted the functionality of HOLIS across the 3 HOLIS nodes or subsystems: Control Switch, Central Control Unit, and Homeowner’s PC

11. 11 Use Case Driven Design Use cases are realized via collaborations  Collaborations represents the way in which the use case is implemented in the design  Societies of classes, interfaces, subsystems or other elements that cooperate to achieve some behavior  We can trace from the requirements to the design Emergency Messaging Use case Collaboration «trace» Participating classes

12. 12 Structural and Behavioral Aspects of Collaboration Structure specifies the static structure of the system  Classes  Elements  Interfaces  Subsystems Behavioral specifies the dynamics of how the elements interact to accomplish the result Collaboration is not a physical thing Collaboration is a description of how cooperating elements of the system work together

13. 13 Class Diagram for HOLIS Emergency Message Sequence Collaboration Notification Agent Sender Received sendMessage() Queue addMessage() removeMessage() Count() Message ID Header Body IRemote 1 * * *

14. 14 Sequence Diagram for the HOLIS Emergency Message Sequence :Message:OutgoingQueue:NotificationAgent create addMessage removeMessage

15. 15 Using Collaborations to Realize Sets of Individual Requirements Just as we traced use cases to collaboration, we can also trace requirement statements Collaboration «trace» Participating classes Requirements The system shall … Every 24 hours … Synchronization occurs …

16. 16 Key Points Some requirements map well from design to implementation in code Other requirements have little correlation to design and implementation; the form of the requirements differs from the form of the design and implementation (the problem of orthogonality) Object orientation and use cases can help alleviate the problem of orthogonality Use cases drive design by allowing all stakeholders to examine the proposed system implementation against a backdrop of system uses and requirements Good system design is not necessarily optimized to make it easy to see how and where the requirements are implemented

17. 17 From Use Cases to Test Cases Chapter 26

18. 18 Common Testing Terms Test Plan – contains information about the purpose and goals of testing within the project, and identifies the test strategy Test Case – set of test inputs, execution conditions, and expect results developed for a particular objective Test Procedure – set of detailed instructions for the setup, execution, and evaluation of results for a test case Test Script – software script that automates the execution of a test procedure Test Coverage – defines the degree to which a given test or set of test addresses all specific test cases Test Item – a build that is an object of testing Test Results – data captured during the execution of a test

19. 19 Role of Test Cases Constitute the bulk of the testing activity The quality and thoroughness with which they are designed determine the quality of the final result  Test cases form the foundation on which to design and develop test procedures  The “depth” of the testing is proportional to the number of test cases  The scale of the test effort is proportional to the number of test cases  Test design and development, and the resources needed, are largely governed by the required test cases Use cases serve directly as an input to this process

20. 20 Use Case Scenarios A scenario, or instance of a use case, is a use-case execution wherein a specific user executes the use case in a specific way Think in terms of specific scenarios that occur for each use case Even with a limited number of use cases, a large number of specific scenarios must be tested

21. 21 Deriving Test Cases From Use Cases 1. Identify the use-case scenarios Not all scenarios may be described in the original use case 2. For each scenario, identify one or more test cases Test case contains the parameters of the test, including the conditions and expected results 3. For each test case, identify the conditions that will cause it to execute 4. Complete the test case by adding data values Infinite combination, use boundary conditions

22. 22 Key Points One of the greatest benefits of the use-case technique is that it builds a set of assets that can be used to drive the testing process Use cases can directly drive, or seed, the development of test cases The scenarios of a use case create templates for individual test cases Adding data values completes the test cases Testing nonfunctional requirements completes the testing process

23. 23 Tracing Requirements Chapter 27

24. 24 Role of Traceability in Systems Development Experience has shown that tracing requirements is a significant factor in assuring quality It is also significant in analyzing the impacts of changes IEEE definition  The degree to which a relationship can be established between two or more products of the development process, especially products having a predecessor-successor or master-subordinate relationship to one another (IEEE 610.12-1990 §3) e.g. – degree to which the requirements and design of a given software component match  The degree to which each element in a software development product establishes its reason for existing (IEEE 610.12-1990 §3) e.g. – the degree to which each element in a bubble chart references the requirement it satisfies

25. 25 Requirement to Requirement Traceability User Needs to Features  Typically a one-to-many mapping Features to Use Cases  Typically a many-to-many mapping Features to Supplementary Requirements  Typically a many-to-many mapping Check that every element is traced to something  This ensures that all needs and features are in the requirements  This ensures that there is not a requirement not needed by the user – gold plating

26. 26 Requirement to Implementation Traceability Use cases to use-case realizations (collaborations)  Typically a one-to-one mapping Use-case realizations to implementation  Mapping collaborations to their parts, classes Supplementary requirements to implementation  Trace individual requirements to a collaboration Collaboration «trace» Participating classes Requirements The system shall … Every 24 hours … Synchronization occurs …

27. 27 Requirement to Testing Traceability Use case to scenario  Typically a one-to-many mapping Scenario to test case  Typically a one-to-many mapping Supplementary requirements to test cases  Requirements traced individually to scenarios and test cases or grouped into packages

28. 28 Key Points Requirements traceability is a proven technique that can increase the quality and reliability of software Traceability is mandated in certain high-assurance software development environments Traceability extends from user needs to product features to use cases and supplementary requirements, and from there to implementation and testing The value and cost of traceability varies with project context and available tooling

29. 29 Managing Change Chapter 28

30. 30 Why Do Requirements Change External factors  The problem changes – regulations, economy, consumer preferences  Users change their minds or perceptions on what they want – identity of users change, perceptions of market change  External environment changes – ongoing improvements in hardware, Internet  New system comes into existence – behavior evolves around the new system, new types of information emerge, new interfaces

31. 31 Why Do Requirements Change Internal factors  Failed to ask the right questions at the right time to the right people  Failed to create a practical change management process – changes pile up and create pressure that leads to an explosion  Iterating from requirements to design begets new requirements – process of designing the system exposes new requirements

32. 32 Requirements Leakage or Creep Unofficial changes creep into the system  Enhancements mentioned by distributors who had been overheard by programmers at a sales convention  Direct customer request to programmers  Mistakes that had been made and shipped and had to be supported  Hardware features that didn’t get in or didn’t work  Knee-jerk change-of-scope reactions to competitors  Functionality inserted by programmers with “careful consideration” of what’s good for the customer  Programmers’ “Easter Eggs” – hidden behavior built into system for debugging

33. 33 Process for Managing Change 1. Recognize that change is in inevitable, and plan for it Good changes come from all sources 2. Baseline the requirements Baseline for each iteration or release – version control Publish the baseline for the team Once baselined, new requirements are more easily identified 3. Establish a single channel to control change Change can cause unanticipated consequences Analyze impacts for budget, schedule and technical impacts 4. Use a change control system to capture changes A needed change can turn into a feature – 16 character names Change control board (CCB)

34. 34 Process for Managing Change Change control board (CCB) must consider the following: The impact of the change on the cost and functionality of the system The impact of the change on customers and other external stakeholders not well represented on the CCB The potential for the change to destabilize the system When to implement the change CCB must notify everyone of the change 5. Manage change hierarchically A change to one requirement can have a ripple effect in other related requirements Change the needs, then requirements, then design, then code, this helps manage the ripple effect A programmer never has the authority to introduce new features and requirements directly into the code, no matter how well intentioned

35. 35 Requirements Configuration Management Benefits  Prevents unauthorized and potentially destructive or frivolous changes  Preserve the revisions to requirements documents  Facilitates the retrieval and/or reconstruction of previous versions of documents  Supports a managed, organized baseline “release strategy” for incremental improvements  Prevents simultaneous update of documents or conflicting and uncoordinated updates to different documents at the same time Elements Impacted by Change  Use traceability linkages to help identify impacts

36. 36 Requirements Configuration Management Audit trail of change history  Document why the change was made Configuration Management and Change Management  Change history should exist at 3 levels 1. Finest level of detail – for all use cases and requirements 2. At a middle level of detail – for all project documents 3. At the general level – for the project Configuration management always means versioning of the software and checking out the code Configuration management is sometimes called change management when versioning the project documents like the requirements No matter what you call it, you should do both

37. 37 Key Points A process to manage requirements can be useful only if it recognizes and addresses the issue of change Internal change factors include failing to ask the right people the right questions at the right time and failing to create a practical process to help manage changes to requirements In order to have a reasonable probability of success, requirements leakage must be stopped or at least reduced to a manageable level

38. 38 Assessing Requirements Quality in Iterative Development Chapter 29

39. 39 Software Project Quality Definition by Rational  The characteristic of having demonstrated the achievement of producing a product that meets or exceeds agreed-on requirements—as measured by agreed-on measure and criteria—and that is produced by an agreed-on process  Additional aspects (besides requirements) include Time to market Budget adherence Scope of team Project Company investment  Quality has two major dimensions End result of application Business impact on the producer and consumer

40. 40 Quality Assessment Checklists Quality assessment checklists are very common practice Checklists can be used by independent auditors or the team itself Those conducting the assessment must take into account the level of specificity and completeness expected for that iteration Checklists are provided on pgs. 361-368

41. 41 Key Points In iterative development, the primary quality check is the objective evidence provided by the availability and suitability of intermediate iterations Assessment of requirements process quality and requirements artifacts can also occur at these checkpoints Assessments must take into consideration the point in the lifecycle at which the assessment occurs Successive refinement, rather than absolute completeness or specificity, is the goal