vu-re-lecture-45 requirement engineering.ppt
- 1. 1 Review of Lectures 23-44 Lecture # 45
- 3. 3 Writing Requirements • Requirements specification should establish an understanding between customers and suppliers about what a system is supposed to do, and provide a basis for validation and verification
- 4. 4 Writing Requirements • Typically, requirements documents are written in natural languages (like, English, Japanese, French, etc.) • Natural languages, by their nature, are ambiguous • Structured languages can be used with the natural languages to specify requirements
- 5. 5 Guidelines for Writing Requirements • Define standard templates for describing requirements • Use language simply, consistently, and concisely • Use diagrams appropriately
- 6. 6 Use of Standard Templates • Define a set of standard format for different types of requirements and ensure that all requirement definitions adhere to that format • Standardization means that omissions are less likely and makes requirements easier to read and check
- 8. 8 Requirements Document • The requirements document is a formal document used to communicate the requirements to customers, engineers and managers • It is also known as software requirements specifications or SRS
- 9. 9 Requirements Document • The services and functions which the system should provide • The constraints under which the system must operate • Overall properties of the system i.e., constraints on the system’s emergent properties
- 10. 10 Requirements Document • Definitions of other systems which the system must integrate with • Information about the application domain of the system, e.g., how to carry out particular types of computation • Constraints on the process used to develop the system
- 11. 11 Requirements Document • It should include both the user requirements for a system and a detailed specification of the system requirements • In some cases, the user and system requirements may be integrated into one description, while in other cases user requirements are described before (as introduction to) system requirements
- 12. 12 Requirements Document • Typically, requirements documents are written in natural languages (like, English, Japanese, French, etc.) • Natural languages, by their nature, are ambiguous • Structured languages can be used with the natural languages to specify requirements
- 13. 13 Requirements Document • For software systems, the requirements document may include a description of the hardware on which the system is to run • The document should always include an introductory chapter which provides an overview of the system and the business needs
- 14. 14 Requirements Document • A glossary should also be included to document technical terms • And because multiple stakeholders will be reading documents and they need to understand meanings of different terms • Also because stakeholders have different educational backgrounds
- 15. 15 Requirements Document • Structure of requirements document is also very important and is developed on the basis of following information – Type of the system – Level of detail included in requirements – Organizational practice – Budget and schedule for RE process
- 16. 16 Users of Requirements Documents • System customers • Managers • System engineers • System test engineers • System maintenance engineers
- 17. 17 Quality Attributes of Requirements Documents
- 18. 18 SRS Quality Attributes • Correct • Unambiguous • Complete • Verifiable • Consistent
- 19. 19 SRS Quality Attributes • Understandable by customer • Modifiable • Traced • Traceable • Design independent
- 20. 20 SRS Quality Attributes • Annotated • Concise • Organized
- 22. 22 Introduction • No system exists in isolation. Every interesting system interacts with human or automated actors that use that system for some purpose, and those actors expect that system to behave in predictable ways
- 23. 23 Introduction • A use case specifies the behavior of a system or part of a system • It is a description of a set of sequences of actions, including variants, that a system performs to yield an observable result of value to an actor
- 24. 24 Introduction • They are used in requirements elicitation process • Use cases are applied to capture the intended behavior of the system under development, without having to specify how the behavior is implemented • They provide a way for developers, end users, and domain experts to come to a common understanding
- 25. 25 Introduction • Use cases serve to help validate the architecture and to verify the system as it evolves during development • Use cases are realized by collaborations whose elements work together to carry out each use case
- 26. 26 Introduction • Well-structured use cases denote essential system or subsystem behaviors only • They are neither overly general nor too specific
- 28. 28 Documenting Use Cases • Name • Summary – Short description of use case • Dependency (on other use cases) • Actors • Preconditions – Conditions that are true at start of use case
- 29. 29 Documenting Use Cases • Flow of Events – Narrative description of basic path • Alternatives – Narrative description of alternative paths • Post-condition – Condition that is true at end of use case
- 30. 30 Case Study and Use Cases for Case Study
- 31. 31 A Well-Structured Use Case • Names a single, identifiable, and reasonably atomic behavior of the system or part of the system • Factors common behavior by pulling such behavior from other use cases • Factors variants by pushing such behavior into other use cases that extend it
- 32. 32 Banking System Case Study
- 33. 33 Problem Description - 1 • A bank has several automated teller machines (ATMs), which are geographically distributed and connected via a wide area network to a central server. Each ATM machine has a card reader, a cash dispenser, a keyboard/display, and a receipt printer. By using the ATM machine, a customer can withdraw cash from either checking or savings account, query the balance of an account, or transfer funds from one account to another. A transaction is initiated when a customer inserts an ATM card into the card reader. Encoded on the magnetic strip on the back of the ATM card are the card number, the start date, and the expiration date. Assuming the card is recognized, the system validates the ATM card to determine that the expiration date has not passed, that the user-entered PIN (personal identification number) matches the PIN maintained by the system, and that the card is not lost or stolen. The customer is allowed three attempts to enter the correct PIN; the card is confiscated if the third attempt fails. Cards that have been reported lost or stolen are also confiscated.
- 34. 34 Problem Description - 2 • If the PIN is validated satisfactorily, the customer is prompted for a withdrawal, query, or transfer transaction. Before withdrawal transaction can be approved, the system determines that sufficient funds exist in the requested account, that the maximum daily limit will not be exceeded, and that there are sufficient funds available at the local cash dispenser. If the transaction is approved, the requested amount of cash is dispensed, a receipt is printed containing information about the transaction, and the card is ejected. Before a transfer transaction can be approved, the system determines that the customer has at least two accounts and that there are sufficient funds in the account to be debited. For approved query and transfer requests, a receipt is printed and card ejected. A customer may cancel a transaction at any time; the transaction is terminated and the card is ejected. Customer records, account records, and debit card records are all maintained at the server.
- 35. 35 Problem Description - 3 • An ATM operator may start up and close down the ATM to replenish the ATM cash dispenser and for routine maintenance. It is assumed that functionality to open and close accounts and to create, update, and delete customer and debit card records is provided by an existing system and is not part of this problem. • ‘Designing Concurrent, Distributed, and Real-Time Applications with UML’ by H. Gomaa, Addison-Wesley, 2000
- 36. 36 Use Case Model • The use cases are described in the use case model • There are two actors of this system – ATM Customer – Operator
- 37. 37 Need for Modeling • Modeling is a central part of all activities that lead up to the development good software • We build models to communicate the desired structure and behavior of our system
- 38. 38 Need for Modeling • We build models to visualize and control the system’s architecture • We build models to better understand the system we are building, often exposing opportunities for simplification and reuse • We build models to minimize risk
- 39. 39 Need for Modeling • We build models so that we can better understand the system we are developing • We build models of complex systems because we cannot comprehend such a system in its entirety
- 40. 40 A model is a simplification of reality
- 41. 41 Four Aims of Modeling • Models help us to visualize a system as it is or as we want it to be • Models permit us to specify the structure or behavior of a system • Models give us a template that guides us in constructing a system • Models document the decisions we have made
- 42. 42 Principles of Modeling • The choice of what models to create has profound influence on how a problem is attacked and how a solution is shaped • Every model may be expressed at different levels of precision
- 43. 43 Principles of Modeling • The best models are connected to reality • No single model is sufficient. Every nontrivial system is best approached through a small set of nearly independent models
- 44. 44 Principles of Modeling • Partitioning • Abstraction • Projection
- 45. 45 Modeling Techniques • Object-oriented modeling – Static and dynamic modeling • Functional modeling • Dynamic modeling
- 47. 47 Static Structure • Any precise model must first define the universe of discourse, that is, the key concepts from the application, their internal properties, and their relationships to each other • This set of constructs is the static view
- 48. 48 Static Structure • The application concepts are modeled as classes, each of which describes a set of discrete objects that hold information and communicate to implement behavior • The information they hold is modeled as attributes; the behavior they perform is modeled as operations
- 49. 49 Object-Oriented Static Modeling of the Banking System
- 50. 50 Steps in Object-Oriented Analysis • Identify classes within the problem domain • Define the attributes and methods of these classes • Define the behavior of those classes • Model the relationship between those classes
- 51. 51 Object-Oriented Static Modeling of the Banking System
- 52. 52 Object-Oriented Static Modeling of the Banking System
- 54. 54 Function-oriented Modeling • In function-oriented modeling, a hierarchy of functions (also known as processes, transforms, transactions, bubbles, and activities) is created • At the root of the hierarchy is the most abstract function, while the leaf nodes of the hierarchy are least abstract
- 55. 55 Function-oriented Modeling • Function-oriented modeling is based on the concept of functions or processes, so they become the most important element in this approach • The functional model describes computations within a system, i.e., what happens
- 56. 56 Function-oriented Modeling • What is a function or a transform or process? • Each function is a sequential activity that potentially may execute concurrently with other functions • The functional model specifies the result of a computation without specifying how or when they are computed
- 57. 57 Types of Functions • Asynchronous Function • Asynchronous State Dependent Function • Periodic Function • Periodic State-Dependent Function
- 58. 58 Real-Time Structured Analysis and Design Technique (RSTAD) and Application of Banking Case Study
- 59. 59 Function-oriented Modeling Techniques • Structured requirements definition • Structured analysis and system specification • Modern structured analysis • Real-time structured analysis and structured design • Structured analysis and design technique • PSL/PSA
- 60. 60 Real-Time Structured Analysis and Structured Design (RSTAD) • Develop the system context diagram • Perform data flow/control flow decomposition • Develop control transformations or control specifications • Define mini-specifications (process specifications) • Develop data dictionary
- 61. 61 Structured Analysis and Design Technique
- 62. 62 Structured Analysis and Design Technique (SADT) • A model of the problem is constructed, which is composed of hierarchy of diagrams • Each diagram is composed of boxes and arrows • The topmost diagram, called the context diagram, defines the problem most abstractly
- 63. 63 Structured Analysis and Design Technique (SADT) • As the problem is refined into sub- problems, this refinement is documented into other diagrams • Boxes should be given unique names that should always be verb phrases, because they represent functions
- 64. 64 Structured Analysis and Design Technique (SADT) • All boxes should be numbered in the lower right corner, to reflect their relative dominance • Arrows may enter top, left, or bottom sides of the box, and can exit only from the right side of the box
- 65. 65 Structured Analysis and Design Technique (SADT) • An arrow pointing into the left side of a box represents things that will be transformed by the box. These are inputs • An arrow pointing down into the top of the box represents control that affects how the box transforms the things entering from left side
- 66. 66 Structured Analysis and Design Technique (SADT) • Arrows entering the bottom of a box represent mechanism and provide the analyst with the ability to document how the function will operate, who will perform it, or what physical resources are needed to perform the function
- 68. 68 Dynamic Modeling • Temporal relationships are difficult to understand • A system can first be understood by examining its static structure and the relationships that exist among different elements at single moment in time
- 69. 69 Dynamic Modeling • Then we examine changes in these elements and their relationships over time • Those aspects of a system that are concerned with time and changes are the dynamic model
- 70. 70 Dynamic Modeling • Control is an aspect of a system that describes the sequences of operations that occur in response to external stimuli, without consideration of what the operations do, what they operate on, or how they are implemented
- 71. 71 Dynamic Modeling • Dynamic modeling deals with flow of control, interactions, and sequencing of operations in a system of concurrently- active objects • Major dynamic modeling concepts are events, which represent external stimuli, and states, which represent values of objects
- 72. 72 Dynamic Modeling • There are two ways to model dynamic behavior • One is the life history of one object as it interacts with the rest of the world; the other is the communication patterns of a set of connected objects as they interact to implement behavior
- 73. 73 Dynamic Modeling • The view of an object in isolation is a state machine – a view of an object as it responds to events based on its current state, performs actions as part of its response, and transitions to a new state • This is displayed in state chart diagrams in UML
- 74. 74 Dynamic Modeling • The view of a system of interacting objects is a collaboration, a context-dependent view of objects and their links to each other, together with the flow of messages between objects across data links • Collaboration and sequence diagrams are used for this view in UML
- 75. 75 Techniques for Dynamic Modeling • Finite state machines (FSM) • Statecharts • Petri nets • Decision tables and decision trees • Collaboration diagrams • Sequence diagams
- 76. 76 Dynamic Modeling of Banking System Case Study
- 77. 77 Dynamic Modeling • There are two ways to model dynamic behavior • One is the life history of one object as it interacts with the rest of the world; the other is the communication patterns of a set of connected objects as they interact to implement behavior
- 78. 78 Dynamic Modeling • The view of an object in isolation is a state machine – a view of an object as it responds to events based on its current state, performs actions as part of its response, and transitions to a new state • This is displayed in state chart diagrams in UML
- 79. 79 Dynamic Modeling • The view of a system of interacting objects is a collaboration, a context-dependent view of objects and their links to each other, together with the flow of messages between objects across data links • Collaboration and sequence diagrams are used for this view in UML
- 80. 80 Dynamic Modeling • The dynamic model depicts the interaction among the objects that participate in each use case • The starting point for developing the dynamic model is the use case and the objects determined during object structuring
- 81. 81 Dynamic Modeling of Banking System Case Study
- 82. 82 Dynamic Modeling • There are two ways to model dynamic behavior • One is the life history of one object as it interacts with the rest of the world; the other is the communication patterns of a set of connected objects as they interact to implement behavior
- 83. 83 Dynamic Modeling • The view of an object in isolation is a state machine – a view of an object as it responds to events based on its current state, performs actions as part of its response, and transitions to a new state • This is displayed in state chart diagrams in UML
- 84. 84 Dynamic Modeling • The view of a system of interacting objects is a collaboration, a context-dependent view of objects and their links to each other, together with the flow of messages between objects across data links • Collaboration and sequence diagrams are used for this view in UML. Both of these combined are called interactive diagrams
- 85. 85 Dynamic Modeling • The dynamic model depicts the interaction among the objects that participate in each use case • The starting point for developing the dynamic model is the use case and the objects determined during object structuring
- 86. 86 Interaction Diagrams • Interaction diagrams are used to model the dynamic aspects a system. For the most part, this involves modeling concrete or prototypical instances of classes, interfaces, components, and nodes, along with messages that are dispatched among them, all in the context of a scenario that illustrates a behavior
- 87. 87 Interaction Diagrams • Interaction diagrams may stand alone to visualize, specify, construct, and document the dynamics of a particular society of objects, or they may be used to model one particular flow of control of a use case
- 88. 88 Types of Interaction Diagrams • Sequence diagrams • Collaboration diagrams
- 89. 89 Sequence Diagrams • A sequence diagram is an interaction diagram that emphasizes the time ordering of messages • Graphically, a sequence diagram is a table that shows objects arranged along the X axis and messages, ordered in increasing time, along the Y axis
- 90. 90 Collaboration Diagrams • A collaboration diagram is an interaction diagram that emphasizes the structural organization of the objects that send and receive messages • Graphically, a collaboration diagram is a collection of vertices and arcs
- 91. 91 Hints and Tips on Interaction Diagrams • Give it a name that communicates its purpose • Use a sequence diagram if you want to emphasize the time ordering of messages • Use a collaboration diagram if you want to emphasize the organization of the objects involved in the interaction
- 92. 92 Hints and Tips on Interaction Diagrams • Lay out its elements to minimize lines that cross • Use notes and color as visual cues to draw attention to important features of your diagram
- 93. 93 Requirements Document for the Banking System
- 94. 94 Requirements Document • The requirements document is a formal document used to communicate the requirements to customers, engineers and managers • It is also known as software requirements specifications or SRS
- 95. 95 Requirements Document • The services and functions which the system should provide • The constraints under which the system must operate • Overall properties of the system i.e., constraints on the system’s emergent properties
- 96. 96 SRS for the Banking System • Preface • Introduction • Glossary • Specific requirements • Appendices – Use-case model – Object model – Data-flow model
- 97. 97 Requirements Engineering for Agile Methods
- 98. 98 Introduction • Agile methods are a family of software development processes • Their aim is to deliver products faster, with high quality, and satisfy customer needs through the application of the principles of lean production to software development
- 99. 99 Introduction • Agile methods have become popular during the last few years • Lean production has been conceived during the ’50s in Toyota. It involves several practices that are now part of most manufacturing processes, such as just-in- time development, total quality management, and continuous process improvement
- 100. 100 Introduction • The principle of lean production is the constant identification and removal of waste, that is, anything that does not add value for the customer to the final product
- 101. 101 Introduction • Agile methods focus on – Delivering value for the customer – Ensuring that the customer understand such value and be satisfied by the project
- 102. 102 Introduction • Agile methods pose a lot of emphasis in producing and delivering to the customer only those features that are useful • Producing anything that is not required is considered a mistake
- 103. 103 Introduction • Adding a feature that is not needed not only consumes effort without adding customer value but also creates extra code, which may contain errors and make code longer and more complex to maintain, to correct and improve
- 104. 104 Introduction • The waste includes general architectures that are used only partially or reusable components with functionalities that are likely to be never used
- 105. 105 Introduction • To achieve such elimination of waste, agile methods claim to be – Adaptive rather than predictive – People-oriented rather than process- oriented
- 106. 106 Introduction • A close collaboration between the development team and the customer is a must, so that – Requirements are fully identified and correctly understood – Final products reflects what the customer needs, no more no less
- 107. 107 Requirements Engineering for Web-Based Information Systems
- 108. 108 Web-Based Information Systems • What makes web systems so different from the traditional software systems that their planning and construction requires a unique development process? • First, we need to understand different types of web-based information systems
- 109. 109 Types of WBIS Models • Those that deliver advertising and promotion • Those that assist business workflow • Those that facilitate inter- organizational interaction • Those that support multi-participant trading
- 110. 110 Requirements Engineering for Product Lines
- 111. 111 Introduction • The interest in software product lines emerged from the field of software reuse when developers realized that they could obtain much greater reuse benefits by reusing software architectures instead of reusing individual software components
- 112. 112 Software Reuse • Software reuse has been a goal in software engineering since 1968 • Goal is to maximize productivity, minimize cost of developing software and to improve profits for the software vendors • This has been an research area in software engineering
- 113. 113 Software Reuse Manifestos • Code reuse – Mathematical libraries • Design reuse • Requirements reuse • Knowledge reuse • Product line approach
- 114. 114 Software Product Lines • A software product line is also referred to as a software product family, a family of systems, or an application domain • The terms used most in the early days of this field were domain analysis and domain engineering
- 116. 116 Introduction • In everyday life, we make decisions, e.g., when buying a DVD-player, food, a telephone, etc • Usually, we do not have more than a couple of choices to consider. Even with just a couple of choices, decisions can be difficult to make
- 117. 117 Introduction • When having tens, hundreds or even thousands of alternatives, decision-making becomes much more difficult • One of the keys to making the right decision is to prioritize between different alternatives. It is often not obvious which choice is better, because several aspects must be taken into consideration
- 118. 118 Introduction • When developing software systems, similar trade-offs must be made • The functionality that is most important for the customers might not be as important when other aspects (e.g. price) are factored in • We need to develop the functionality that is most desired by the customers, as well as least risky, least costly, and so forth
- 119. 119 Introduction • The quality of software products is often determined by the ability to satisfy the needs of the customers and users • So, it is very important to include those requirements in the product, which are really needed by the customers
- 120. 120 Introduction • Most software projects have more candidate requirements than can be realized within the time and cost constraints • Prioritization helps to identify the most valuable requirements from this set by distinguishing the critical few from the trivial many
- 121. 121 Requirements Prioritization • Act of giving precedence or priority to one item over another item • Requirements prioritization means giving precedence to some requirements over other requirements based on feedback from system stakeholders
- 122. 122 Benefits of Requirements Prioritization • Stakeholders can decide on the core requirements for the system • Planning and selection of ordered, optimal set of software requirements for implementation in successive releases • Helps in trade-offs of conflicting constraints such as schedule, budget, resources, time to market, and quality
- 123. 123 Benefits of Requirements Prioritization • Balances the business benefit of each requirement against its cost • Balances the implications of requirements on the software architecture and future evolution of the product and its associated cost • Selects only a subset of the requirements and still produce a system that will satisfy the customers
- 124. 124 Benefits of Requirements Prioritization • Get technical advantage and optimize market opportunity • Minimize rework and schedule slippage (plan stability) • Handle contradictory requirements, focus the negotiation process, and resolve disagreements between stakeholders
- 125. 125 Benefits of Requirements Prioritization • Establish relative importance of each requirement to provide the greatest value at the lowest cost
- 126. 126 Research Areas in Requirements Engineering
- 127. 127 Topics in Requirement Engineering • Requirements elicitation techniques • Requirements validation techniques • Requirements management and traceability • Requirements evolution • Requirements and software architectures
- 128. 128 Topics in Requirement Engineering • Requirements and business architectures • Requirements prioritizing and negotiation • Specification of quality attributes • Requirements metrics • Tool support for RE
- 129. 129 Topics in Requirement Engineering • Cognitive, social and cultural factors in RE
- 130. 130 Thank you