Lecture 6 & 7.pdf
- 1. Lecture No 6 & 7 1 SOFTWARE REQUIREMENTS ENGINEERING
- 2. SOFTWARE REQUIREMENTS IN CONTEXT OF SYSTEM ENGINEERING Stable and Volatile Requirements Requirements changes occur while the requirements are being elicited, analyzed and validated and after the system has gone into service. Some requirements are more stable, while others may be more subject to change than others Stable requirements are concerned with the essence of a system and its application domain. They change more slowly than volatile requirements. Volatile requirements are specific to the instantiation of the system in a particular environment and for a particular customer. 2
- 3. SOFTWARE REQUIREMENTS IN CONTEXT OF SYSTEM ENGINEERING System A system is a group of interacting or interrelated entities that from a unified whole. A system, surrounded and influenced by its environment, is described by its boundaries, structure and propose and expressed in its functioning. Systems are the subjects of study of systems theory. 3
- 4. SOFTWARE REQUIREMENTS IN CONTEXT OF SYSTEM ENGINEERING System Engineering System engineering is an interdisciplinary field of engineering and engineering management that focus on how to design, integrate, and manage complex system over their life cycles. Systems engineering ensure that all likely aspects of a project or system are considered and integrated into a whole. 4
- 5. SOFTWARE REQUIREMENTS IN CONTEXT OF SYSTEM ENGINEERING System Engineering Process The systems engineering process involves the top-down development of a system’s functional and physical requirements from a basic set of mission objectives. The system’s physical requirements lead to the specific hardware components that must be acquired or developed to perform the identified functions. 5
- 6. SOFTWARE REQUIREMENTS IN CONTEXT OF SYSTEM ENGINEERING Real Time System A real-time system is any information-processing activity or system which has to respond to externally generated input stimuli within a finite end specified period. Typically example of real-time systems include Air Traffic control systems, transport systems, solar systems, telephone systems, ecological systems, weather forecast system and space systems etc 6
- 7. SOFTWARE REQUIREMENTS IN CONTEXT OF SYSTEM ENGINEERING Embedded System System refers to a product that contains multiple, integrated software and hardware subsystems. The software that control a real-time system can be embedded in the device in the form of a dedicated computer, or it can reside in a host computer separate from the hardware it controls. Embedded and other real-time systems have sensors, controllers, motors, powers supplies, integrated circuits, and other mechanical, electrical and electronic components that operate under software control. 7
- 8. SOFTWARE REQUIREMENTS IN CONTEXT OF SYSTEM ENGINEERING Requirement Derivation System requirements are decomposed into software, hardware and manual requirements, then allocated to appropriate components. 8 System Requirements Software Requirements Manual Requirements Hardware Requirements Decomposition and derivation Component A Component B People Component C Component D allocation allocation allocation
- 9. SOFTWARE REQUIREMENTS IN CONTEXT OF SYSTEM ENGINEERING Diagrams to model real Tim Systems Visual modeling is a powerful analysis technique for specifying real- time systems. -State chart diagrams -State machine diagrams -State tables and decision tables -Context diagrams -Architectural diagrams 9
- 10. SOFTWARE REQUIREMENTS IN CONTEXT OF SYSTEM ENGINEERING Example Diagrams to model Systems 10
- 11. SOFTWARE REQUIREMENTS IN CONTEXT OF SYSTEM ENGINEERING Prototyping and Simulation Prototyping and simulation are other powerful technique for eliciting and validating requirements for embedded systems. Because of the costs and time needed to build hardware, you can use prototypes to test operational concepts and to explore both requirement and design options for the device. Simulations can help you better understand user interface displays and controls, network interactions, and hardware software interface. 11
- 12. SOFTWARE REQUIREMENTS IN CONTEXT OF SYSTEM ENGINEERING Timing Requirements Timing requirements lie at the heart of real-time control systems. Undesirable outcome can result if signals are not received from sensors as scheduled, if the software cannot send control signals to the hardware when anticipated, or if the physical devices don’t perform their action on time. Timing requirements involves multiple dimensions: Execution Time Latency Predictability 12
- 13. SOFTWARE REQUIREMENTS IN CONTEXT OF SYSTEM ENGINEERING Challenges of Embedded Systems 1. Stability 2. Safety 3. Security 4. Launch Phase 5. Design Limitations 6. Compatibility 13
- 14. RISK ANALYSIS Risk Analysis Risk analysis has been also shown important in the software design phase to evaluate critically of the system, where risk are analyzed and necessary countermeasures are introduced. Usually, countermeasure correspond to a design/system fine-tuning and then with a limited margin of change. However, it may happen that the risk reduction results in the revision of the entire design and possibly of the initial requirements, introducing thus extra costs for the project. 14
- 15. RISK ANALYSIS Risk Analysis Considering risk since the early phase of the software development process can be useful to prevent such problems and as effect, to contain costs. Particularly, analyzing risk along stakeholder’s needs and objectives, namely before requirements elicitation, can introduce good and valuable criteria to evaluate and choose among different alternative requirements. 15
- 16. RISK ANALYSIS Risk Management A risk management strategy can be defined as a software project plan or the risk management step. It can be organized into a separate Risk Mitigation, Monitoring and Management (RMMM) plan. The RMMM plan documents all work performed as part of risk analysis and is used by the project manager as part of the overall project plan. Teams do not develop a formal RMMM document. Rather, each risk is documented individually using a risk information sheet. In most cases the risk is maintained using a database system, so that creation and information entry, priority ordering, searches and other analysis may be accomplished easily. 16
- 17. RISK ANALYSIS Risk Management Risk Mitigation, Monitoring and Management plan (RMMM)- documents all work performed as part of risk analysis and is used by the project manager as part of the overall project plan. Risk is maintained using a database system, so that creation and information entry, priority ordering, searches and other analysis may be accomplished easily, risk monitoring is a project tracking activity. 17
- 18. RISK ANALYSIS Risk Management Once RMMM has been documented and the project has begun, risk mitigation and monitoring steps commence. Risk monitoring is a project tracking activity with three primary objective. Three primary objectives: 1. Assess whether predicted risks do, in fact, occur 2. Ensure that risk management steps defined for the risk are being properly applied 3. Collect information that can be used for future risk analysis. 18
- 19. REQUIREMENT TRACEABILITY MATRIX (RTM) Requirement Traceability Requirements traceability is the ability to connect requirements to other artifacts such as different types of software tests or bugs. It’s used to track requirements and prove that requirements have been fulfilled. You should have Bidirectional Traceability Bidirectional traceability is the ability to trace forward (e.g, from requirement to test case) and backward (e.g, from test case to environment.) Traceability should be bidirectional. It establish a relationship between two artifacts. And it’s important to be able to trace from one item to the next and back again. 19
- 20. REQUIREMENT TRACEABILITY MATRIX (RTM) You should have Bidirectional Traceability That mean tracing forward from requirements to source code to test case to test runs to issues. And from issues back to requirements. You should also be able to trace back from requirements to business goals or objectives. Requirement Traceability Matrix Is a document that maps and traces user requirement with test cases. It captures all requirements proposed by the client and requirement traceability in a single documents, delivered at the conclusion of the software development life cycle. The main purpose of requirement traceability matrix is to validate that all requirements are checked via test cases such that no functionality is unchecked during software testing. 20
- 21. REQUIREMENT TRACEABILITY MATRIX (RTM) How to create a RTM You can create a RTM in Microsoft Excel or you can use specialized tools to accelerate the process. There are three basic steps-no matter which tool you use. Define your goals. Establish relationship Fill in the traceability matrix 21
- 22. REQUIREMENT TRACEABILITY MATRIX (RTM) 1. Requirement ID 2. Requirements Description 3. Test cases with Status 22 Which Parameters to include in requirement traceability Matrix? Req No Req Des Testcase ID Status 123 Login to the application TC01, TC02, TC03 TC01-Pass TC02-Pass 345 Ticket creation TC04,TC05,TC06,TC07, TC08,TC09, TC10 TC04-Pass TC05-Pass TC06-Fail TC07-No Run 456 Search Ticket TC011, TC012, TC013, TC014 TC011-Pass TC012-Pass TC013-Fail
- 23. REQUIREMENT TRACEABILITY MATRIX (RTM) Types of Traceability Test Matrix In Software Engineering, traceability matric can be divided into three major components mentioned below. Forward traceability: This matrix is used to check whether the project progresses in the desired direction and for the right product. It makes sure that each requirement is applied to the product and that each requirement is tested thoroughly. It maps requirements to test cases. Backward Traceability: It is used to ensure whether the current product remains on the right track. The purpose behind this type of traceability is to verify that we are not expanding the scope of the project by adding code, design elements, test or other work that is not specified in the requirements. It maps test case to requirements. 23
- 24. REQUIREMENT TRACEABILITY MATRIX (RTM) Types of Traceability Test Matrix Continue… Bi-directional Traceability (Forward+Backword): This traceability matrix ensures that all requirements are covered by test case. It analyzes the impact of a change in requirements affected by the defect in a work product and vice versa. 24
- 25. REQUIREMENT ERRORS Requirement Error/Defect A deficiency in the requirements quality that can hamper software development Errors and omissions find their way in different requirements documents If not removed, requirements errors usually flow downstream into design, code, and user manuals It is difficult to detect requirements errors once they flow downstream Requirements errors are most expensive to eliminate 25
- 26. Types of Requirement Error/Defect There are for types of Requirements errors 1. Errors of omission 2. Errors of clarity and ambiguity 3. Errors of commission 4. Errors of speed and capacity 26
- 27. Types of Requirement Error/Defect Errors of omission: Errors of omission are most common among requirements errors Domain experts easily forget to convey domain knowledge to requirements engineers, because they consider that to be obviously and implicit. Errors clarity and ambiguity: Second most common errors are those of clarity and ambiguity Primarily, because natural languages (like English) are used to state requirements, while such languages are themselves ambiguous. 27
- 28. Types of Requirement Error/Defect Errors of commission: Errors of commission can also find their way into the requirements documents Errors of Speed and capacity: Performance, that is errors of speed and capacity, are also found requirements Primarily, these occur due to conflicting understanding or competing needs of different stakeholders 28
- 29. Addressing Requirements Errors Defect Prevention Defect Removal Prevention VS Removal For requirements errors, prevention is usually more effective than removal Joint application development (JAD), quality function development (QFD), and prototyping are more effective in error prevention. Requirements inspection and prototyping play an important role in error removal. 29
- 30. Addressing Requirements Errors Defect Prevention Don’t let defects/errors become part of the requirements documents or requirements model in the first place Understanding application domain and business area is the first step in defect prevention Training in different requirements engineering activities (elicitation, analysis, and negotiation and validation) is also very important for defect prevention Allocating enough time to conduct requirements engineering activities also is very important in this regard 30
- 31. Addressing Requirements Errors Defect Prevention continue… Willing and active participation of stakeholders in different activities of requirements engineering. That is why JAD is very useful in defect prevention as far as requirements errors are concerned An overall commitment to quality and emphasis on using documented processes is also a very important An overall commitment to process improvement 31
- 32. Addressing Requirements Errors Defect Removal 1.Inspection 2.Observation Inspection Inspections are conducted by a group of people working on the project, with the objective to remove defects or errors Every member of the inspection team has to read and evaluate requirements documents before coming to the meeting and a formal meeting is conducted to discuss requirements errors 32
- 33. Defect Removal Inspection continue… Requirements errors detected during this inspection save lot of budget and time as requirements error don’t flow into the design and development phases of software development process. A complete description of inspection must address five dimensions: -Technical -Managerial -Organizational -Assessment -Tool support 33
- 34. Defect Removal 1. Inspection continue… 1.1 Defect Detection with Inspection Defect Origins Requirements Design Coding Documentation Testing Maintenance Requirements Design Coding Documentation Testing Maintenance Defect Discovery 34
- 35. Defect Removal 1. Inspection continue… 1.1 Defect Detection without Inspection Defect Origins Requirements Design Coding Documentation Testing Maintenance Requirements Design Coding Documentation Testing Maintenance Defect Discovery Chaos Zone 35
- 36. Defect Removal 2. Observation Requirements engineers are trained to write requirements documents, but have no training on reading/reviewing requirements documents Reviewers typically rely on a ad hoc reading techniques, with no well-defined procedure, learning largely by observations 36
- 37. Technique for Reading Requirements Documents There are four Techniques how to read requirements documents Ad hoc review Checklist review Defect-based reading Perspective-based reading 37
- 38. Technique for Reading Requirements Documents Ad hoc review A review with no formal, systematic procedure, based only individual experience Checklist review A list of item is provided to reviewers, which makes this inspection process more focused Defect-based reading Provides a set of systematic procedures that reviewers can follow, which are tailored to the formal software cost reduction notation Perspective-based reading A group of experimental software engineering at the university of Maryland, college park, have created perspective-based reading to provide a set of software reading techniques for finding defects in requirements documents. 38
- 39. Perspective-Based Reading (PBR) What is perspective Based Reading? Perspective-based reading (PBR) focuses on the point of view or needs of the customers or consumers of a document. For example, one reader may read from the point of view of the tester, another from the point of view of the developer, and yet another from the point of view of the user of the system. Different Perspective PBR operates under the premise that different information in the requirements is more or less important for the different uses of the document. Each user of the requirements document find different aspects of the requirements important for accomplish a particular task. 39
- 40. Perspective-Based Reading (PBR) Different Perspective Continue… PBR provides a set of individuals reviews, each from a particular requirements user’s point of view, that collectively cover the documents relevant aspect, this process is similar to constructing system use cases, which require identifying who will use the system and in what way 40
- 41. Perspective-Based Reading (PBR) Steps in PBR Selecting a set of perspectives for reviewing the requirements documents Creating or tailoring procedures for each perspective usable for building a model of the relevant requirements information Enhance/supplement each procedure with questions for finding defects while creating the model Applying procedure to review the documents 41
- 42. Perspective-Based Reading (PBR) Benefits of Different Perspectives Systematic -Explicitly identifying the different uses for the requirements gives reviewers a definite procedure for verifying whether those uses are achievable Focused -PBR helps reviewers concentrate more effectives on certain types of defects, rather then having to look for all types. Goal-Oriented and Customizable -Reviewers can tailor perspectives based on the current goals of the organization Transferable via Training -PBR works follow a procedure, not the reviewer’s own experience with recognizing defects. New reviewers can receive training in the procedure's steps. 42