Lecture 05
Download as PPTX, PDF0 likes179 views
The document discusses business requirements for a booth product that will be sold to retailers and used by customers. The requirements from different stakeholders like the developer and retailer may conflict over priorities like establishing high-tech features versus a simple solution. Developing a vision statement requires balancing these diverse objectives. Effective communication between developers and customers is important to build a good relationship and capture requirements properly. Use case modeling is a technique used to structure requirements in a way that is intuitive for both developers and customers.
Lecture 05
- 1. Lecture 05
- 2. Business requirements collected from multiple sources might conflict. For example, consider a booth product with embedded software that will be sold to retail stores and used by the store’s customers. Business Requirements
- 3. leasing or selling the booth to the retailers selling consumables through the booth to the customer attracting customer to the brand modifying the nature of the historical developer- customer relationship Business Requirements Developer’s View
- 4. making money from customer use of booth attracting more customers to the store saving money if the booth replaces manual operations Business Requirements Retailer’s View
- 5. The developer might want to establish a high-tech and exciting new direction for customers, while the retailer wants a simple solution and the customer wants convenience and features. Conflicting Objectives
- 6. The vision statement should reflect a balanced view that will satisfy the need of diverse customers. It can be somewhat idealistic but should be grounded in the realities of existing or anticipated customer markets, enterprise architectures, organizational strategic directions, and resource limitations. The Vision Statement
- 7. The chemical tracking system will allow scientists to request containers of chemicals to be supplied by chemical stockroom or by vendors. The location of every chemical container within the company, the quantity of the material remaining in it, and the complete history of each container’s location and usage will be known by the system at all times. The company will save 25% on chemical costs by fully exploiting chemicals already available within the company, by disposing of fewer partially used or expired containers, and by using a standard chemical purchasing process. The chemical tracking system will also generate all reports required to comply with federal and state government regulations that require the reporting of chemical usage, storage, and disposal. Vision Statement Chemical Tracking System
- 8. The scope description establishes the boundary between the system we are developing and everything else in the universe. The context diagram graphically illustrates this boundary by showing the connections between the system being developed or the problem being addressed, and the outside world. The context diagram identifies the entities outside the system that interface to it in some way (called terminators or external entities), as well as the flow of data and material between each external entity and the system. The context diagram is used as the top level abstraction in a dataflow diagram developed according to principles of structured analysis. The context diagram can be included in the vision and scope document, in the SRS, or as part of a dataflow model of the system. The Context Diagram
- 10. excellent software products are the result of a well- executed design based on excellent requirements and high quality requirements result from effective communication and coordination between developers and customers. That is, good customer-developer relationship and effective communication between these two entities is a must for a successful software project. In order to build this relationship and capture the requirements properly, it is essential for the requirement engineer to learn about the business that is to be automated. Customer-Developer Relationship
- 11. It is important to recognize that a software engineer is typically not hired to solve a computer science problem – most often than not, the problem lies in a different domain than computer science and the software engineer must understand it before it can be solved. In order to improve the communication level between the vendor and the client, the software engineer should learn the domain related terminology and use that terminology in documenting the requirements. Document should be structured and written in a way that the customer finds it easy to read and understand so that there are no ambiguities and false assumption. Building a Relationship
- 12. One tool used to organize and structure the requirements is such a fashion is called use case modeling. It is modeling technique developed by Ivar Jacobson to describe what a new system should do or what an existing system already does. It is now part of a standard software modeling language known as the Unified Modeling Language (UML). It captures a discussion process between the system developer and the customer. It is widely used because it is comparatively easy to understand intuitively – even without knowing the notation. Because of its intuitive nature, it can be easily discussed with the customer who may not be familiar with UML, resulting in a requirement specification on which all agree. Use Cases
- 13. A use case model has two components Use Case Boundaries of the system are defined by functionality that is handled by the system. Each use case specifies a complete functionality (from its initiation by an actor until it has performed the requested functionality). Actor An entity that has an interest in interacting with the system. An actor can be a human or some other device or system. Use Case Model
- 14. Use Diagram for a Library System
- 15. Creating a use case model is an iterative activity. The iteration starts with the identification of actors. Creating a Use Case Model