Unit ii
- 1. FSD-Unit-II
- 2. Customer Requirements • User ( Customer requirement) : Customer requirements are high level abstract statements of the system requirement for the customer and end user of the system. This requirement describes what services the system is expected to provide to customers and the situations under which it must operate. • So The user requirement or customer requirement is requirement that specifies what the user expects the software to be able to do.
- 3. List of Customer requirements • Operational distribution or deployment: Where will the system be used? • Performance and related parameters: What are the critical system parameters required. • Utilization environments: How are the various system components to be used? • Effectiveness requirements: How effective or efficient must the system be in performing the task. • Operational life cycle: How long will the system be in use by the user? • Environment: What environments will the system be expected to operate in an effective manner?
- 5. Organization of SRS • Organization of SRS document depends on the system analyst and the policies of company and it also depends on the product being developed. • Different project may require their requirement to be organized differently means there is no one method that is suitable for all projects. • However there are three basic issue that must be included in all SRS document that is Functional requirement ,non functional requirement and guidelines of system implementation.
- 6. Continue… • Here is the sample of SRS document which can be used as a guideline to organize the document. 1 Introduction 1.1 Purpose 1.2 Scope 1.3 Definitions, Acronyms, and Abbreviations 1.4 References 1.5 Overview
- 7. 2 Overall Description 2.1 Product perspective 2.1.1 System interfaces 2.1.2 User interfaces 2.1.3 Hardware interfaces 2.1.4 Software interfaces 2.1.5 Communication interfaces 2.1.6 Memory constraints 2.1.7 Operations 2.2 Product functions 2.3 User characteristics 2.4 Constraints 2.5 Assumptions and dependencies 3 Specific requirements 3.1 External interfaces 3.2 Functions requirements 3.3 Performance requirements 3.4 Logical database requirements 3.5 Design constraints 3.6 Software system attributes 3.7 Organizing the specific requirements 3.8 Additional Comments 4 Supporting information
- 8. Shortcomings of a DFD model • In the DFD model, the function performed by a bubble is judged from its label. However, a short label may not capture the entire functionality of a bubble. For example, a bubble named find-book-position has only intuitive meaning and does not specify several things, e.g. what happens when some input information are missing or are incorrect. Further, the find-book position bubble may not convey anything regarding what happens when the required book is missing. • Control aspects are not defined by a DFD. For instance, the order in which inputs are consumed and outputs are produced by a bubble is not specified.
- 9. Continue… • There is no any particular method or guideline for decomposition of function into sub-functions. it is highly subjective and depend on the choice and judgment of the analyst. Due to this reason, even for the same problem, Many alternative DFD representations are possible.
- 10. Architectural Design • s/w architecture design is a description of how a system is organized. • You can identify the overall structure of the system, sub-systems, modules and their relationships. • It is derived from the DFD of the system. • The out put of architecture design is architectural model. • Architecture should be of individual programs or it should be included of different sub-systems. Architecture Design decisions • Decisions are made by system architects. • Decisions are purely based on the type of the system. • Also depend on the functional and non-functional requirements. • Functional reqn contain the functions or the features supproted by the system. 10
- 11. • Non-functional reqn are: Architectural views • Architectural design should be documented so that it can be used in future. • s/w architectures may be documented form different views listed below: • Conceptual view – It is an abstract view of the system. – It shows detailed decompositions of the system. • Logical view – It shows key concepts of the system as objects and classes. 11 -Performance -Security -Availability -Safety -Maintainability - Reliability
- 12. • Process view – This shows how the system is composed of interacting process at run time. • Development view – It shows the breakdown structure of s/w into modules. • Physical view – It shows the system hardware and how s/w components are distributed across them. Architectural Patterns • Architectural patterns are a means of reusing knowledge about generic (સામાન્ય) system architectures. • It is the description of a system organization. • Commonly used architectural patterns includes. 12 1. Layered architecture 2. Repository architecture 3. Client-Server architecture 4. Pipe and filter architecture
- 13. 1. Layered architecture • Layered architecture pattern describe separation and independence. • It allows to change the view independently. • In it the system is organized into separate layers and each layer can use the services offered by the layer under it. • Example is shown in the fig. 13
- 14. • Advantages – adding a new view or changing an existing view can be done without changing in the base model. – This architecture is portable. – Changes in one layer do not affect another. – Authentication be provided in each layer. • Disadvantages – Clean separation between each layer is difficult. – Due to multiple layers, performance should be degrade. • Application – Required when need of multilevel security. – Where development is spread across several teams. 14
- 15. 2. Repository(a place to store information or storage) architecture • In it, all data in a system is managed in a central repository. • Repository is accessible to all the components which do not interact directly, but only through repository. • Example of this architecture is : Management Information System (MIS). • It provides an efficient way to share large amount of data. No need to transmit data explicitly. • Application – Used where large amount of information are generated or required storage capacity is high. • Advantages – Components can be independent, they do not need to know the existence of other components. – Changes made by one component can be circulated to all. 15
- 16. – Data managed consistently. • Disadvantages – Single point failure can affect the whole system. – It is difficult to communicate through repository in a system. – Distributing the repository among several computers are quite difficult. 3. Client-Server architecture. • In this architecture, each service delivered from a separate server. • Clients are users of these services and they access servers to use services. • Client must have the knowledge of the available servers. • While servers do not need to know how many clients are accessing its services. • Clients use RPC (Remote Procedure Call) to access services of servers. 16
- 17. • Clients makes a request to server and waits until it receives a reply. • Fig is shown here. • Application – Applicable when data in a shared database has to be accessed from different locations. – Used when the load on a system is variable. • Advantages – It is a distributed architecture across a network. – Functionality of the servers can be accessible by all the clients without implementing them. 17
- 18. • Disadvantages – At server level, a single point failure may cause the whole system fail. – Performance may be unpredictable as it depends on the network type. 4. Pipe and Filter architecture • In which functional transformations process their inputs and produce outputs. • Data flows from one component to other (as in a pipe) for processing. • Processing components are called filters, which are provided as inputs and processed until converted to outputs. • Transformation may be executed sequentially or parallel. • Application – Used in both batch and transaction based data processing system. 18