1. Lecture 13

2.  Failure mode: when team understands requirements but is unable to meet them.  To ensure that you are building the right system Continually confirm that development is on track Confirm that the development results are correct Learn how to deal with change during development

3. Continually confirm that development is on track  Verification “The process of evaluating a system or component to determine whether the products of a given phase satisfy the conditions imposed at the start of that phase”  Thus we make a verification plan (to ensure that we have done the things we need to do) Tools to help execute this plan ○ Traceability ○ Process models ○ Analysis Inspection reviews

4. Confirm that the development results are correct  To check that the functionality that is developed works correctly and conforms to requirements.  Validating has two important aspects Show that product conforms to requirements To focus on customer acceptance of the final result.

5. Learn how to deal with change during development  Proper change management proper impact analysis ○ Traceability information Incorporate changes in a timely manner

6. From Requirements to Implementation  Proving that requirement is fulfilled in design and code is a non trivial effort.  For some requirements this can be easily tested e.g. “support up to an eight digit floating point input parameter”  Orthogonality Problem For requirements like “the system shall allow editing based on the security set up by the system administrator” No one to one mapping.

7. Orthogonality Problem Why ○ Requirements speak real world items, code speaks of stacks queues and algorithms. ○ Some requirements like performance requirements they have little to do with logical structures but more to do with process structures (how code pieces interact) ○ Implementation of requirement is distributed through code so have to look at whole rather than part. ○ Good design not due to does system map to requirements

8. Solution  Object Orientation Modeling with help of real time entities(objects)  Use Cases (user/system interaction in terms of scenarios)

9. Managing the Transition  Making Models Understanding versus oversimplification  Architecture of System (Shaw and Garlan) Description of elements from which systems are built, interaction amongst those elements, patterns that guide their composition and constraints on those patterns”

10. Architecture  Helps to Understand what the system does Understand how system works Be able to think and work on pieces of the system Extend the system Reuse parts of the system to build another one.

11. 4+1 Views of Architecture  Different views for different people  Philippe Kruchten

12. 4 Views  The logical view addresses the functionality of the system. This abstraction of the design model represents the logical structure of the system in terms of subsystems and classes, which in turn are the entities that deliver the functionality to the user.  The implementation view describes the bits and pieces that are relevant to the implementation of the system: source code, libraries, object classes, and so on. This view represents the static view of these pieces, not how they interact.  Process views, generally more useful to describe operations of the system, are extremely important for systems that have parallel tasks, interfaces with other systems, and other interactions that occur during execution. Since many modern systems exhibit high degrees of parallelism and multithreading, this view allows the reviewer to determine potential problems, such as race conditions or deadlocks. You should also use the process view to examine throughput issues and other performance issues that the user specified in the nonfunctional requirements.  Because the project modules rarely exist in a vacuum, the deployment view allocates the implementation elements to the supporting infrastructure, such as operating systems and computing platforms. This view is not especially concerned with what the interactions are but rather with the fact that there are interactions and constraints where the two systems meet.

13. Use Case Realization  Use case realization is used to achieve requirements to design transition.  Use cases are realized via collaboration Collaboration are societies classes, interfaces, subsystems or other elements that cooperate to achieve some behavior. Symbol of collaboration an ellipse with the name inside it. Collaboration has a ○ Structural part (class diagram) ○ Behavioral part (interaction diagram)

14. Role of Traceability in Requirement Verification  Vertical Versus Horizontal Traceability One to one, many to many, many to one relationship Implicit versus explicit traceability

15. Validation  “The process of evaluating a system or component during or at the end of the development process to determine whether it satisfies specified requirements”

16.  Acceptance Tests Alpha versus beta tests  Testing Your development process must plan testing activities Your development process must also provide time and resources to design the tests Your development must also provide time and resources to execute the test.  Maintain an Audit/Trail

17. Validation Traceability  Do we have enough tests to cover everything that needs to be tested?  Do we have any extra tests that serve no useful purpose

18. Requirement Based Testing  To test system against requirements Unit tests Integration tests  Table 32-1 page number 352

19. Managing Change  Why Do requirements Change External Factors ○ There was change to the problem ○ The user changed their mind ○ The external environment changed ○ The new system comes into existence Internal Factors ○ We failed to ask the right people the right questions at the right time. ○ We failed to create a practical process to manage change

20. We have met the enemy and They is Us  Official change  Unofficial change Enhancements mentioned by distributors Direct customer requests to programmers Mistakes that have been made and shipped and had to be supported Hardware features that didn’t work Knee jerk change of scope reactions to competitors Functionality inserted by developer, thinking what is best for customer Programmers “Easter eggs”

21. Process for Managing Change  Process Recognize that change is inevitable and plan for it. Baseline the requirements Establish a single channel to control change Use a change control system to capture changes Manage Change hierarchically  Requirement Configuration Management

22. THE END ANY QUESTIONS? THANK YOU