BCA123 CU-BCA-SEM-II-Software Engineering-26.10.2020-converted

5. Which technique is applicable when other projects in the same analogy application domain have been completed? (a) Algorithmic cost modelling (b) Expert judgement (9) Estimation by analogy (d) Parkinson’s Law Answers 1. (d), 2. (c), 3. (a), 4. (a), 5. (c) REFERENCES • Pressman R.S. (2009). Software Engineering - A Practitioner’s Approach. New Delhi: MGH Publications. • Mall R. (2003). Fundamentals of Software Engineering. New Delhi: PHI • Jalote P. (2019). An Integrated Approach to Software Engineering. New Delhi: Narosa Publications. • Summerville I. (2013). Software Engineering. New Delhi: Pearson Education. • Software Engineering, Sixth Edition, 20~1, Ian Sommerville; Pearson Education. • Sommerville, Software Engineering. United States of America: Addison Wesley, 2001. • Szyperski, D. Gruntz, and S. Murer, Component Software Beyond Object Oriented Programming. New York: Adison Wesley, 2002. • http://www.chemuturi.com/Test%20Effort%20Estimation.pdf • http://scrummethodology.com/scrum-effort-estimation-and-story-points/ • //www.idt.mdh.se/kurser/cdt501/2008/lectures/book%20Basic%2 0Concepts%20of%20CBSE.pdf. 99 CU IDOL SELF LEARNING MATERIAL (SLM)

• Khan, Noor-ul-Qayyum, and U. A. Khan, “An improved model for component based software development,” Scientific & Academic Publishing, Software Engineering, vol. 2, pp. 138-146, 2012. • K. J. Shambhu and R. K. Mishra, “Accessing software quality for component-based software through trustworthiness and dependability analysis,” Internal Journal of Development Research, vol. 5, no. 4, pp. 4259-4261, Apr. 2015. • Software Project Management: Readings and Cases. A selection of papers and case studies on software project management that is particularly strong in its coverage of algorithmic cost modelling. (C. F. Kemerer (ed.), 1997, Irwin.) • ‘Cost models for future software life cycle processes: COCOMO II’. An introduction to the COCOMO II cost estimation model that includes rationale for the formulae used. Easier to read than the definitive book. (B. Boehm et al., Annals of Software Engineering, 1, Balzer Science Publishers, 1995.) 100 CU IDOL SELF LEARNING MATERIAL (SLM)

UNIT 6 SYSTEM ANALYSIS 1 Structure Learning Objectives Introduction Principles of Structured Analysis Requirement analysis Summary Key Words/Abbreviations Learning Activity Unit End Questions (MCQ and Descriptive) References LEARNING OBJECTIVES After studying this unit, you will be able to: • State principles of structured analysis. • Explain principles of requirement analysis. INTRODUCTION The Software Requirements Specification is developed as a consequence of analysis. Requirements analysis is a software engineering task that bridges the gap between system level engineering and software design. Requirements analysis allow software engineer to refine the software allocation and build models of data, function and behavioral domain that will be used by the software. It provides the information to the designer to be transformed into data, architectural, interface and component-level design. Finally, it also provides the 101 CU IDOL SELF LEARNING MATERIAL (SLM)

developer and the customer with the means to assess the quality of the software once it is built. Software requirements analysis can be divided into five areas of effort: Problem recognition, Evaluation and synthesis, Modeling, Specification, and Review. Initially, the analyst studies the system specification and the software project plan to understand the system as a whole in relation to the software and to review the scope of the software as per the planning estimates. After this the communication for analysis is established to ensure problem recognition. Structured Analysis is a development method that allows the analyst to understand the system and its activities in a logical way. • It is a systematic approach, which uses graphical tools that analyze and refine the objectives of an existing system and develop a new system specification which can be easily understandable by user. • It has following attributes − • It is graphic which specifies the presentation of application. • It divides the processes so that it gives a clear picture of system flow. • It is logical rather than physical i.e., the elements of system do not depend on vendor or hardware. • It is an approach that works from high-level overviews to lower-level details. Structured Analysis is a development method that allows the analyst to understand the system and its activities in a logical way. It is a systematic approach, which uses graphical tools that analyze and refine the objectives of an existing system and develop a new system specification which can be easily understandable by user. It has following attributes − • It is graphic which specifies the presentation of application. 102 CU IDOL SELF LEARNING MATERIAL (SLM)

• It divides the processes so that it gives a clear picture of system flow. • It is logical rather than physical i.e., the elements of system do not depend on vendor or hardware. • It is an approach that works from high-level overviews to lower-level details. PRINCIPLES OF STRUCTURED ANALYSIS Structured Analysis and Structured Design (SA/SD) is diagrammatic notation which is design to help people understand the system. The basic goal of SA/SD is to improve quality and reduce the risk of System failure. It establishes concrete management specification and documentation. It focuses on solidity, pliability and maintainability of system. Basically the approach of SA/SD is based on the Data Flow Diagram. It is easy to understand SA/SD but it focuses on well-defined system boundary whereas JSD approach is too complex and does not have any graphical representation. SA/SD is combined known as SAD and it mainly focuses on following 3 points: • System • Process • Technology Problem Analysis- The basic aim of problem analysis is to obtain a clear understanding of the needs of the clients and the users, what exactly is desired from the software, and what the constraints on the solution are. Frequently the client and the users do not understand or know all their needs, because the potential of the new system is often not fully appreciated. The analysts have to ensure that the real needs of the clients and the users are uncovered, even if they don’t know them clearly. That is, the analysts are not just collecting and organizing information about the client’s organization and its processes, but they also act as consultants who play an active role of helping the clients and users identify their needs. The basic principle used in analysis is the same as in any complex task: divide and conquer. That is, partition the problem into sub problems and then try to understand each sub problem and its 103 CU IDOL SELF LEARNING MATERIAL (SLM)

relationship to other sub problems in an effort to understand the total problem. The concepts of state and projection can sometimes also be used effectively in the partitioning process. A state of a system represents some conditions about the system. Frequently, when using state, a system is first viewed as operating in one of the several possible states, and then a detailed analysis is performed for each state. In projection, a system is defined from multiple points of view. While using projection, different viewpoints of the system are defined and the system is then analyzed from these different perspectives. The different “projections” obtained are combined to form the analysis for the complete system. Analyzing the system from the different perspectives is often easier, as it limits and focuses the scope of the study. Problem Analysis consists of the following approaches: 1. Informal Approach: An informal approach is one where no defined methodology is used to analyze. The information about the system is attained by interaction with the questionnaires, client, end users, study of existing documents, brainstorming, etc. The informal approach is used extensively to analysis and can be relatively suitable as conceptual modeling-based approaches repeatedly do not model all facets of the problem and are not always suitable for all the problems. As the Software Requirements Specification (SRS) is to be authorized and the feedback from the validation activity may necessitate for further analysis or requirement. Selecting an informal approach to analysis is not very uncertain— the errors that could be presented are not essentially heading for slip by the prerequisites phase. Therefore such approaches might be the utmost useful approach to analysis in some conditions. 2. Shadowing: Shadowing provides an effective means to discover what is currently being done in a business. Shadowing is a good way to get an idea of what a person does on a day to-day basis. However, you might not be able to observe all the tasks during shadowing because more than likely the person will not, during that session, perform all the tasks he or she is assigned. For example, accounting people might create reports at the end of the month, developers might create status reports on a weekly basis, and management might schedule status meetings only biweekly. In addition, you can also learn the purpose of performing a specific task. To gather as much information as possible, you need to encourage the user to explain the reasons for performing a task in as much detail as possible. Shadowing can be 104 CU IDOL SELF LEARNING MATERIAL (SLM)

both passive and active. When performing passive shadowing, you observe the user and listen to any explanations that the user might provide. When performing active shadowing, you ask questions as the user explains events and activities. You might also be given the opportunity to perform some of the tasks, at the user’s discretion. 3. Interviews: In interview is a one-on-one meeting between a member of the project team and a user. The quality of the information a team gathers depends on the skills of both the interviewer and the interviewee. An interviewer can learn a great deal about the difficulties and limitations of the current solution. Interviews provide the opportunity to ask a wide range of questions about topics that you cannot observe by means of shadowing. Shadowing is not the best option for gathering information about tasks such as management-level activities; long-term activities those span weeks, months, or years; or processes that require little or no human intervention. An example of a process that requires no human intervention is the automatic bill paying service provided by financial institutions. For gathering information about such activities and processes, you need to conduct interviews. SA/SD involves 2 phases: Analysis Phase: It uses Data Flow Diagram, Data Dictionary, State Transition diagram and ER diagram. Design Phase: It uses Structure Chart and Pseudo Code. 1. Analysis Phase: Analysis Phase involves data flow diagram, data dictionary, state transition diagram and entity relationship diagram. 1. Data Flow Diagram: In the data flow diagram model describe how the data flows through the system. We can incorporate the Boolean operators and & or to link data flows when more than one data flow may be input or output from a process. For example, if we have to choose between two paths of a process we can add an operator or and if two data flows are necessary for a process we can add and operator. The input of the process “check-order” needs the credit information and order information whereas the output of the process would be a 105 CU IDOL SELF LEARNING MATERIAL (SLM)

cash-order or a good-credit-order. 2. Data Dictionary: The content that are not described in the DFD are described in data dictionary. It defines the data store and relevant meaning. A physical data dictionary for data elements which flow between processes, between entities, and between processes and entities may be included. This would also include descriptions of data elements that flow external to the data stores. A data dictionary is a structured repository of data elements in the system. It stores the descriptions of all DFD data elements that is, details and definitions of data flows, data stores, data stored in data stores, and the processes. A data dictionary improves the communication between the analyst and the user. It plays an important role in building a database. Most DBMSs have a data dictionary as a standard feature. For example, refer the following table – Table 6.1 Data Dictionary Sr.No. Data Name Description No. of Characters 1 ISBN ISBN Number 10 2 TITLE title 60 3 SUB Book Subjects 80 4 ANAME Author Name 15 A logical data dictionary may also be included for each such data element. All system names, whether they are names of entities, types, relations, attributes or services, should be entered in the dictionary. 3. State Transition Diagram: State transition diagram is similar to dynamic model. It 106 CU IDOL SELF LEARNING MATERIAL (SLM)

specifies how much time function will take to execute and data access triggered by events. It also describes all of the states that an object can have, the events under which an object changes state, the conditions that must be fulfilled before the transition will occur and the activities undertaken during the life of an object. State-transition diagrams describe all of the states that an object can have, the events under which an object changes state (transitions), the conditions that must be fulfilled before the transition will occur (guards), and the activities undertaken during the life of an object (actions). State-transition diagrams are very useful for describing the behavior of individual objects over the full set of use cases that affect those objects. State-transition diagrams are not useful for describing the collaboration between objects that cause the transitions. The UML notation for state-transition diagrams is shown below: Fig 6.1 State transition diagram • Notation-For those not familiar with the notation used for state-transition diagrams, some explanation is in order. 107 CU IDOL SELF LEARNING MATERIAL (SLM)

• State- A condition during the life of an object in which it satisfies some condition, performs some action, or waits for some event. • Event- An occurrence that may trigger a state transition. Event types include an explicit signal from outside the system, an invocation from inside the system, the passage of a designated period of time, or a designated condition becoming true. • Guard-A boolean expression which, if true, enables an event to cause a transition. • Transition-The change of state within an object • Action- One or more actions taken by an object in response to a state change. 3. ER Diagram: ER diagram specifies the relationship between data store. It is basically used in database design. It basically describes the relationship between different entities. It is a technique developed by Larry Constantine to express the requirements of system in a graphical form. It shows the flow of data between various functions of system and specifies how the current system is implemented. It is an initial stage of design phase that functionally divides the requirement specifications down to the lowest level of detail. Its graphical nature makes it a good communication tool between user and analyst or analyst and system designer. It gives an overview of what data a system processes, what transformations are performed, what data are stored, what results are produced and where they flow. 4. Design Phase: Design Phase involves structure chart and pseudo code. 5. Structure Chart: It is created by the data flow diagram. Structure Chart specifies how DFS’s processes are grouped into task and allocate to CPU. The structured chart does not show the working and internal structure of the processes or modules, and does not show the relationship between data or data-flows. Similar to other SASD tools, it is time and cost independent and there is no error-checking technique associated with this tool. The modules of a structured chart are arranged arbitrarily and any process from a DFD can be chosen as the central transform depending on the analysts’ own perception. The structured chart is difficult to amend, verify, maintain, and check for completeness and consistency. 108 CU IDOL SELF LEARNING MATERIAL (SLM)

7. Pseudo Code: It is actual implementation of system. It is an informal way of programming which doesn’t require any specific programming language or technology. A pseudocode does not conform to any programming language and expresses logic in plain English. o It may specify the physical programming logic without actual coding during and after the physical design. • It is used in conjunction with structured programming. • It replaces the flowcharts of a program. REQUIREMENT ANALYSIS Requirement analysis is significant and essential activity after elicitation. We analyze, refine, and scrutinize the gathered requirements to make consistent and unambiguous requirements. This activity reviews all requirements and may provide a graphical view of the entire system. After the completion of the analysis, it is expected that the understandability of the project may improve significantly. Here, we may also use the interaction with the customer to clarify points of confusion and to understand which requirements are more important than others. The various steps of requirement analysis are shown in fig:6.2 Fig 6.2 Requirement Analysis (i) Draw the context diagram: The context diagram is a simple model that defines the 109 CU IDOL SELF LEARNING MATERIAL (SLM)

boundaries and interfaces of the proposed systems with the external world. It identifies the entities outside the proposed system that interact with the system. The context diagram of student result management system is given below: Fig 6.3 Context Diagram (ii) Development of a Prototype (optional): One effective way to find out what the customer wants is to construct a prototype, something that looks and preferably acts as part of the system they say they want. We can use their feedback to modify the prototype until the customer is satisfied continuously. Hence, the prototype helps the client to visualize the proposed system and increase the understanding of the requirements. When developers and users are not sure about some of the elements, a prototype may help both the parties to take a final decision. Some projects are developed for the general market. In such cases, the prototype should be shown to some representative sample of the population of potential purchasers. Even though a person who tries out a prototype may not buy the final system, but their feedback may allow us to make the product more attractive to others. The prototype should be built quickly and at a relatively low cost. Hence it will always have limitations and would not be acceptable in the final system. This is an optional activity. (iii) Model the requirements: This process usually consists of various graphical representations of the functions, data entities, external entities, and the relationships between them. The graphical view may help to find incorrect, inconsistent, missing, and superfluous requirements. Such models include the Data Flow diagram, Entity-Relationship diagram, 110 CU IDOL SELF LEARNING MATERIAL (SLM)

Data Dictionaries, State-transition diagrams, etc. (iv) Finalize the requirements: After modeling the requirements, we will have a better understanding of the system behavior. The inconsistencies and ambiguities have been identified and corrected. The flow of data amongst various modules has been analyzed. Elicitation and analyze activities have provided better insight into the system. Now we finalize the analyzed requirements, and the next step is to document these requirements in a prescribed format. Requirement Analysis, also known as Requirement Engineering, is the process of defining user expectations for a new software being built or modified. In software engineering, it is sometimes referred to loosely by names such as requirements gathering or requirements capturing. Requirements analysis encompasses those tasks that go into determining the needs or conditions to meet for a new or altered product or project, taking account of the possibly conflicting requirements of the various stakeholders, analyzing, documenting, validating and managing software or system requirements. Here are the objectives for performing requirement analysis in the early stage of a software project: From What to How: Software engineering task bridging the gap between system requirements engineering and software design. Orthogonal Views: Provides software designer with a model of: • system information (static view) • function (functional view) • behavior (dynamic view) Software Architecture: Model can be translated to data, architectural, and component-level designs. Iterative and Incremental Process: Expect to do a little bit of design during analysis and a little bit of analysis during design. Activities for Requirement Analysis Requirements analysis is critical to the success or failure of a systems or software project. 111 CU IDOL SELF LEARNING MATERIAL (SLM)

The requirements should be documented, actionable, measurable, testable, traceable, related to identified business needs or opportunities, and defined to a level of detail sufficient for system design. Conceptually, requirements analysis includes four types of activity: • Eliciting requirements: the task of communicating with customers and users to determine what their requirements are. This is sometimes also called requirements gathering. • Analyzing requirements: determining whether the stated requirements are unclear, incomplete, ambiguous, or contradictory, and then resolving these issues. • Requirements modeling: Requirements might be documented in various forms, such as natural-language documents, use cases, user stories, or process specifications. • Review and retrospective: Team members reflect on what happened in the iteration and identifies actions for improvement going forward. • Requirements analysis is a team effort that demands a combination of hardware, software and human factors engineering expertise as well as skills in dealing with people. Here are the main activities involve in requirement analysis: Identify customer's needs. • Evaluate system for feasibility. • Perform economic and technical analysis. • Allocate functions to system elements. • Establish schedule and constraints. • Create system definitions. Requirement Analysis Techniques Requirement analysis helps organizations to determine the actual needs of stakeholders. At the same time, it enables the development team to communicate with stakeholders in a 112 CU IDOL SELF LEARNING MATERIAL (SLM)

language they understand (like charts, models, flow-charts,) instead of pages of text. Once the requirements are gathered, we document the requirements in a Software Requirements Specification (SRS) document, use cases or as User Stories, which are shared with the stakeholders for approval. This document is easy to understand for both normal users and developers. Any changes in the requirements are also documented and go through a change control procedure and finalized on approval. Business Requirement vs Software Requirements A business plan or project requires a variety of requirements to help define goals and establish a scope for the work that will be undertaken. Requirements also provide context and objective ways to measure progress and success. Once business requirements are established, software requirements are defined and developed in order to move a project forward. Business Requirements Business requirements relate to a business' objectives, vision and goals. They also provide the scope of a business need or problem that needs to be addressed through a specific activity or project. For example, if a trade association has an objective to promote the services offered by its members, the business requirements for a project might include creating a member directory that increases awareness of members. Good business requirements must be: • Clear and are typically defined at a very high level. • Provide enough information and guidance to help ensure that the project fulfils the identified need. • Understanding an organization's mandate, objectives or goals, a specific business need or problem that is being tackled Should be clearly defined and understood before developing business requirements. The need or problem can relate to the organization or business in general or focus on a 113 CU IDOL SELF LEARNING MATERIAL (SLM)

stakeholder group, such as customers, clients, suppliers, employees or another group. Software Requirements Software requirements break-down the steps needed to meet the business requirement or requirements. Whereas a business requirement states the 'why' for a project, a software requirement outline the 'what'. For example, if the business requirement is to create a member directory for a trade association, the software requirements will outline who has access to the directory, how member register with the directory, who will have ownership of the data, what vehicle or vehicle will be used such as a website or paper-based directory, and so on. Techniques for Discovering Business Needs There are various requirement analyzing techniques that can be used as per the business improvement and software development process. Listed below are some of these techniques. Gap Analysis Using BPMN or ArchiMate A gap is often said to be \"the space between where you are and where you want to be\". Gap analysis is a comparison process between baseline and target business scenario. In other words, gap analysis is the study of what a business is doing currently and where it wants to go in the future, and is undertaken as a means of bridging the space between them. The goal of the gap analysis is to identify gaps in optimizing performance. This provides a business with insight into potential improvement. It answers questions like what is the current state of the project? Where do we want to be? etc. ArchiMate - Gap Analysis ArchiMate is an open and independent enterprise architecture modeling language to support the description, analysis and visualization of architecture within and across business domains in an unambiguous way. It's a perfect modeling tool and with the required notation to perform gap analysis. 114 CU IDOL SELF LEARNING MATERIAL (SLM)

Fig 6.4 Gap Analysis BPMN - As-is and To-be Analysis As-is Process The example that we are going to demonstrate about current situation (as-is process) is of an online shop that sells goods. The process begins with the sales representative receives a purchase order from a customer and proceeds to check the stock level. If there is enough stock on hand to meet with the order, the sales representative will pack them. The process ends with shipping them along with an invoice. In case of insufficient stock, the sales representative will suggest the customer to amend the purchase order. 115 CU IDOL SELF LEARNING MATERIAL (SLM)

Fig 6.5 Example As-is Process To-be Process Let's just say that our business has grown so much that we now have a warehouse to keep our stocks. So we are looking for ways to improve our current (as-is) process to better allocate the new resources. Furthermore, we will show an example of modeling the enhancement below in a to-be process diagram. Fig 6.6 Example To-be Process 116 Business Motivation Model CU IDOL SELF LEARNING MATERIAL (SLM)

If an enterprise prescribes a certain approach for its business activity, it ought to be able to say why and what result(s) is the approach meant to achieve. The Business Motivation Model (Bmm) Is an Omg Modeling Notation for Support of Business Decisions about how to react to a changing world. An enterprise would use it by acquiring a BMM modeling tool and then creating its own BMM - populating the model with business information specific to the enterprise. There are two broad purposes: ➢ To capture decisions about reaction to change and the rationale for making them, with the intent of making them shareable, increasing clarity and improving decision- making by learning from experience. ➢ To reference the outcomes of the decisions to their effect on the operational business (e.g. changes made to business processes and organization responsibilities), providing traceability from influencer to operational change 117 CU IDOL SELF LEARNING MATERIAL (SLM)

Fig 6.7 Business motivational model • End - define what an enterprise wants to be - the states it desires to be in. • Means - define what an enterprise has decided it needs to do to achieve its ends. • Influencer - is something that an enterprise decides might affect it. • Assessment - When an influencer causes a significant change, the enterprise makes an assessment of its impact, identifying risks and potential rewards. There may be multiple assessments, perhaps from different stakeholders. 118 CU IDOL SELF LEARNING MATERIAL (SLM)

Customer Journey Mapping • Customer Journey Map is a powerful technique for understanding what motivates your customers - what their needs are, their hesitations, and concerns. Although most organizations are reasonably good at gathering data about their customers, data alone fails to communicate the frustrations and experiences the customer experienced. A story can do that, and one of the best storytelling tools in business is the customer journey map. • Customer journey map uses storytelling and visuals to illustrate the relationship a customer has with a business over a period of time. The story is being told from the perspective of customer, which provides insight into the total experience of the customer. It helps your team better understand and address customer needs and pain points as they experience your product or service. In other words, mapping out the customer journey offers your business the chance to see how your brand first engages a potential customer, and then moves through the touchpoints of the entire sales process. • Finally, the team can propose the improvement or actions to be taken against each of the touchpoints. These proposed actions can be potential source of software requirements. 119 CU IDOL SELF LEARNING MATERIAL (SLM)

Fig 6.8 Example customer journey mapping SUMMARY • Analysis Model is a technical representation of the system. It acts as a link between system description and design model. In Analysis Modeling, information, behavior and functions of the system is defined and translated into the architecture, component and interface level design in the design modeling. • The basic aim of problem analysis is to obtain a clear understanding of the needs of the clients and the users, what exactly is desired from the software, and what the constraints on the solution are. • Data flow diagrams (also called data flow graphs) are commonly used during problem analysis. • Object-Oriented Software Engineering (OOSE) is a software design technique that is used in software design in object-oriented programming. Prototyping is the techniques of constructing a partial implementation of a system so that the users, 120 CU IDOL SELF LEARNING MATERIAL (SLM)

customers and developers can have a better knowledge of the system. • It must establish a way of creation of software design. • It must describe requirements of customer. • It must define set of requirements which can be validated, once the software is built. • Requirements analysis is critical to the success or failure of a systems or software project. The requirements should be documented, actionable, measurable, testable, traceable, related to identified business needs or opportunities, and defined to a level of detail sufficient for system design. Conceptually, requirements analysis includes four types of activity: • Eliciting requirements: the task of communicating with customers and users to determine what their requirements are. This is sometimes also called requirements gathering. • Analyzing requirements: determining whether the stated requirements are unclear, incomplete, ambiguous, or contradictory, and then resolving these issues. • Requirements modeling: Requirements might be documented in various forms, such as natural-language documents, use cases, user stories, or process specifications. • Review and retrospective: Team members reflect on what happened in the iteration and identifies actions for improvement going forward. • Requirement analysis helps organizations to determine the actual needs of stakeholders. At the same time, it enables the development team to communicate with stakeholders in a language they understand (like charts, models, flow-charts,) instead of pages of text. • Once the requirements are gathered, we document the requirements in a Software Requirements Specification (SRS) document, use cases or as User Stories, which are shared with the stakeholders for approval. This document is easy to understand for both normal users and developers. Any changes in the requirements are also 121 CU IDOL SELF LEARNING MATERIAL (SLM)

documented and go through a change control procedure and finalized on approval. • In systems engineering and software engineering, requirements analysis focuses on the tasks that determine the needs or conditions to meet the new or altered product or project, taking account of the possibly conflicting requirements of the various stakeholders, analyzing, documenting, validating and managing software KEY WORDS/ABBREVIATIONS • Software development plan: the project plan for the development of a software product. Contrast with software development process, software life cycle. • Software documentation: technical data or information, including computer listings and printouts, in human readable form, that describe or specify the design or details, explain the capabilities, or provide operating instructions for using the software to obtain desired results from a software system. See: specification; specification, requirements; specification, design; software design description; test plan, test report, user's guide. • Software item: source code, object code, job control code, control data, or a collection of these items. Contrast with software element. • Specification analysis. : evaluation of each safety-critical software requirement with respect to a list of qualities such as completeness, correctness, consistency, testability, robustness, integrity, reliability, usability, flexibility, maintainability, portability, interoperability, accuracy, auditability, performance, internal instrumentation, security and training. • Specification, product: (IEEE) A document which describes the as built version of the software • UML: The Unified Modeling Language (UML) is a general-purpose, developmental, modeling language in the field of software engineering that is intended to provide a standard way to visualize the design of a system. • DFD: A DFD shows the flow of data through a system. Evolutionary Prototyping: It 122 CU IDOL SELF LEARNING MATERIAL (SLM)

uses the prototype as the first part of an analysis activity that will be continued into design and construction. • Object-Oriented Software Engineering (OOSE): It is a software design technique that is used in software design in object-oriented programming. • Problem Analysis: The basic aim of problem analysis is to obtain a clear understanding of the needs of the clients and the users, what exactly is desired from the software, and what the constraints on the solution are. Prototyping: It is the technique of constructing a partial implementation of a system so that the users, customers and developers can have a better knowledge of the system. Requirements Analysis: It is a software engineering task that bridges the gap between system level engineering and software design. LEARNING ACTIVITY 1. What are objectives of analysis modeling? 2. Explain importance of software requirements specification. UNIT END QUESTIONS (MCQ AND DESCRIPTIVE) A. Descriptive Types Questions 1. State and describe the data flows through the system. 2. Identify with an example which analysis phase improves the communication between the analyst and the user? 3. Identify phase which demonstrates the relationship between data store database design? 4. Justify simple model that defines the boundaries and interfaces of the proposed systems 123 CU IDOL SELF LEARNING MATERIAL (SLM)

with the external world. 5. Discuss an element to understand effectively when the required design is not clear and the user wants a notational language for communication. B. Multiple Choice Questions 1. The requirements that result from requirements analysis are typically expressed from one of three perspectives or views. What is that perspective or view? (a) Developer (b) User (c) Non-Functional (d) Physical 2. Which of the following property does not correspond to a good Software Requirements Specification (SRS)? (a) Verifiable (b) Ambiguous (c) Complete (d) Traceable 3. Which of the following property of SRS is depicted by the statement: “Conformity to a standard is maintained”? (a) Correct (b) Complete (c) Consistent (d) Modifiable 4. The SRS is said to be consistent if and only if (a) its structure and style are such that any changes to the requirements can be made easily while retaining the style and structure (b) every requirement stated therein is one that the software shall meet (c) every requirement stated therein is verifiable 124 CU IDOL SELF LEARNING MATERIAL (SLM)

(d) no subset of individual requirements described in it conflict with each other 5. Which of the following is included in SRS? (a) Cost (b) Design Constraints (c) Staffing d) Delivery Schedule Answers 1. (d), 2. (b), 3. (d), 4. (b), 5. (b) REFERENCES • Pressman R.S. (2009). Software Engineering - A Practitioner’s Approach. New Delhi: MGH Publications. • Mall R. (2003). Fundamentals of Software Engineering. New Delhi: PHI • Jalote P. (2019). An Integrated Approach to Software Engineering. New Delhi: Narosa Publications. • Summerville I. (2013). Software Engineering. New Delhi: Pearson Education. • Software Engineering, Sixth Edition, 20~1, Ian Sommerville; Pearson Education. • http://softwareengineeringhub.blogspot.in/2010/03/system- • requirementsspecification.html • http://computersciencesource.wordpress.com/2010/03/14/softwareengineering- object-oriented-modelling/ • http://www.software-requirements.tuffley.com/sample.pdf • Shambhu and R. K. Mishra, “Accessing software quality for component-based software through trustworthiness and dependability analysis,” Internal Journal of Development Research, vol. 5, no. 4, pp. 4259-4261, Apr. 2015. 125 CU IDOL SELF LEARNING MATERIAL (SLM)

• Jedlitschka, M. Ciolkowski, and D. Pfahl, “Reporting experiments in software engineering,” in Guide to Advanced Empirical Software Engineering, F. Shull, J. Singer, and D. I. K. Sjoberg, Eds. London: Springer, 2008, pp. 201-228. • G. Cardino, F. Baruchelli, and A. Valerio, “The evaluation of framework reusability,” ACM SIGAPP Applied Computing Review - Special Issue on Frameworks and Patterns in Software Reuse, vol. 5, no. 2, pp. 21-27, 1997. • H. Washizaki, H. Yamamoto, and Y. Fukazawa, “A metrics suite for measuring reusability of software components,” in Proc. Software Metrics Symposium, 2003, pp. 211-223. • M. McIlory, Mass Produced Software Components, in NATO Conference Software Engineering. 1969, Petrocelli/Charter: New York, 1969. • T. Biggerstaff and C. Richter, “Reusability framework, assessment, and directions,” IEEE Software, vol. 4, no. 2, pp. 41-49, 1989. 126 CU IDOL SELF LEARNING MATERIAL (SLM)

UNIT 7 SYSTEM ANALYSIS 2 Structure Learning Objectives Introduction Data flow diagrams Entity Relationship diagram Data dictionary Summary Key Words/Abbreviations Learning Activity Unit End Questions (MCQ and Descriptive) References LEARNING OBJECTIVES After studying this unit, you will be able to: ⚫ Discuss the Data flow diagrams. ⚫ Describe Entity relationship diagram. ⚫ Explain data dictionary. INTRODUCTION Data modeling (data modeling) is the process of creating a data model for the data to be stored in a database. This data model is a conceptual representation of Data objects, the associations between different data objects, and the rules. Data modeling helps in the visual representation of data and enforces business rules, regulatory compliances, and government 127 CU IDOL SELF LEARNING MATERIAL (SLM)

policies on the data. Data Models ensure consistency in naming conventions, default values, semantics, and security while ensuring quality of the data DATA FLOW DIAGRAMS In the Functional Model, software converts information. And to accomplish this, it must perform at least three common tasks- input, processing and output. When functional models of an application are created, the software engineer emphasizes problem specific tasks. The functional model begins with a single reference level model (i.e., be manufactured). In a series of iterations, more and more functional detail is given, until all system functionality is fully represented. Information is converted because it flows from a computer-based system. The system takes input in various forms; Hardware, software, and human elements are applied to replace it; and produce in various forms. The transformation (s) or function may be composed of a single logical comparison, a complex numerical method, or a rule- the invention approach of an expert system. The output can light an LED or provide a 200 page report. Instead, we can create a model or flow model for any computer- based system, regardless of size and complexity. Structural analysis started as an Information Flow Modeling technique. A computer-based system can be modeled as an information transform function as shown in figure. A rectangle represents an external unit. That is, a system element, such as a hardware, a person or another system that provides information for transformation by the software or receives information provided by the software. A circle is used to represent a process or transform or a function that is applied to data and changes it in some way. An arrow is used to represent one or more data items. 128 CU IDOL SELF LEARNING MATERIAL (SLM)

Fig 7.1 Information flow model All arrows should be labeled in a DFD. The double line is used to represent data store. There may be implicit procedure or sequence in the diagram but explicit logical details are generally delayed until software design. Data Flow Diagrams Functional Modeling is represented through a hierarchy of DFDs. The DFD is a graphical representation of a system that shows the inputs to the system, the processing upon the inputs, the outputs of the system as well as the internal data stores. DFDs illustrate the series of transformations or computations performed on the objects or the system, and the external controls and objects that affect the transformation. Rumbaugh et al. have defined DFD as, “A data flow diagram is a graph which shows the flow of data values from their sources in objects through processes that transform them to their destinations on other objects.” The four main parts of a DFD are − • Processes, • Data Flows, 129 CU IDOL SELF LEARNING MATERIAL (SLM)

• Actors, and • Data Stores. The other parts of a DFD are − • Constraints, and • Control Flows. Features of a DFD • Processes-Processes are the computational activities that transform data values. A whole system can be visualized as a high-level process. A process may be further divided into smaller components. The lowest-level process may be a simple function. Representation in DFD − A process is represented as an ellipse with its name written inside it and contains a fixed number of input and output data values. Example − The following figure shows a process Compute_HCF_LCM that accepts two integers as inputs and outputs their HCF (highest common factor) and LCM (least common multiple). Fig 7.2 DFD representation Data Flows Data flow represents the flow of data between two processes. It could be between an actor and a process, or between a data store and a process. A data flow denotes the value of a data item at some point of the computation. This value is not changed by the data flow. 130 CU IDOL SELF LEARNING MATERIAL (SLM)

Representation in DFD − A data flow is represented by a directed arc or an arrow, labeled with the name of the data item that it carries. In the above figure, Integer_a and Integer_b represent the input data flows to the process, while L.C.M. and H.C.F. are the output data flows. A data flow may be forked in the following cases − • The output value is sent to several places as shown in the following figure. Here, the output arrows are unlabelled as they denote the same value. • The data flow contains an aggregate value, and each of the components is sent to different places as shown in the following figure. Here, each of the forked components is labelled. Fig 7.3 DFD component representation Data flow diagramming rules: 1. Processes cannot have only outputs, cannot have only inputs, and must have a verb phrase label. 2. Data can only move to a data store from a process, not from another data store or an outside source. 3. Similarly, data can only be moved to an outside sink or to another data store by a process. 4. Data to and from external sources and sinks can only be moved by processes. 5. Data flows move in one direction only. 6. Both branches of a forked or a joined data flow must represent the same type of data. 131 CU IDOL SELF LEARNING MATERIAL (SLM)

7. A data flow cannot return to the process from which it originated ENTITY RELATIONSHIP DIAGRAM Structured Analysis is a development method that allows the analyst to understand the system and its activities in a logical way. It is a systematic approach, which uses graphical tools that analyze and refine the objectives of an existing system and develop a new system specification which can be easily understandable by user. It has following attributes − • It is graphic which specifies the presentation of application. • It divides the processes so that it gives a clear picture of system flow. • It is logical rather than physical i.e., the elements of system do not depend on vendor or hardware. • It is an approach that works from high-level overviews to lower-level details. ER-modeling is a data modeling method used in software engineering to produce a conceptual data model of an information system. Diagrams created using this ER-modeling method are called Entity-Relationship Diagrams or ER diagrams or ERDs. Purpose of ERD • The database analyst gains a better understanding of the data to be contained in the database through the step of constructing the ERD. • The ERD serves as a documentation tool. • Finally, the ERD is used to connect the logical structure of the database to users. In particular, the ERD effectively communicates the logic of the database to users. • Components of an ER Diagrams 132 CU IDOL SELF LEARNING MATERIAL (SLM)

Fig 7.4 Components of ER diagram DATA DICTIONARY A data dictionary contains metadata i.e. data about the database. The data dictionary is very important as it contains information such as what is in the database, who is allowed to access it, where is the database physically stored etc. The users of the database normally don't interact with the data dictionary, it is only handled by the database administrators. The data dictionary in general contains information about the following − • Names of all the database tables and their schemas. • Details about all the tables in the database, such as their owners, their security constraints, when they were created etc. • Physical information about the tables such as where they are stored and how. • Table constraints such as primary key attributes, foreign key information etc. • Information about the database views that is visible. This is a data dictionary describing a table that contains employee details. Table 7.1 employee detail 133 CU IDOL SELF LEARNING MATERIAL (SLM)

Field Name Data Field Size for Description Example Type display Employee Integer 10 Unique ID of each 1645000001 Number employee Name Text 20 Name of the employee David Heston Date of Birth Date/Time 10 DOB of Employee 08/03/1995 Phone Integer 10 Phone number of 6583648648 Number employee The different types of data dictionary are − • Active Data Dictionary If the structure of the database or its specifications changes at any point of time, it should be reflected in the data dictionary. This is the responsibility of the database management system in which the data dictionary resides. So, the data dictionary is automatically updated by the database management system when any changes are made in the database. This is known as an active data dictionary as it is self-updating. • Passive Data Dictionary This is not as useful or easy to handle as an active data dictionary. A passive data dictionary is maintained separately to the database whose contents are stored in the dictionary. That means that if the database is modified the database dictionary is not automatically updated as in the case of Active Data Dictionary 134 CU IDOL SELF LEARNING MATERIAL (SLM)

So, the passive data dictionary has to be manually updated to match the database. This needs careful handling or else the database and data dictionary are out of sync. Data Model Pros and Cons Now that we understand what data modeling means and why it’s important, let’s check out the pros and cons. Pros • Lower costs • Data models help in lowering the cost of development. Generally, companies spend a lot of funds on coding and testing. Data modeling reduces the company’s coding budget. Not only that, the best part is that data models don’t use a lot from the budget. A data model also catches errors at an earlier stage. Don’t you think that’s a lot better than correcting mistakes when coding is complete? Or worse, imagine if the customers use your app only to find unfixed errors! How would that affect your business’s reputation? Better management of data as a resource You can normalize your data with data modeling. You can also define the data in terms of what it is. Not only that, you can even define data in terms of the properties it can have. Querying the database and generating reports are important processes of any business. Data modeling provides the tools for the same. As a result, you can manage the data as a resource in a better way. Just think of it this way—suppose you hire a developer to create your database. What will the developer find easier: developing from an excel sheet with multiple entities, or from a diagram that explains how all the entities connect with each other? Designing repositories and databases Having a smooth-functioning database is a must for every firm. For that, data modeling is an important process. It also helps in driving better decisions about archives and data warehouses. Apart from that, a data model describes the data clearly. As a result, a company 135 CU IDOL SELF LEARNING MATERIAL (SLM)

knows the business needs for storing data. When you have a clear view of data, it becomes easier to decide what you need. Do you need data marts or a global data warehouse? Accurate representation of objects Data modeling provides an accurate description of data objects by creating a flow or diagram. This diagram shows how the entities and their properties connect with each other or with other elements in the database. You can use the information to define the relationship between tables, primary, and foreign keys. Better performance Most people think that a database runs slow because of some problem in the database design. But in reality, without a data model, the database development is poor. Also, data modeling ensures better performance by easing the database tuning. When the concepts in a data model are clear, the developer can design a database that runs faster. Cons Like all other new technologies, with so many pros, there’s bound to be some cons as well. You can’t perform data modeling without knowing the features of the physical data stored. Even if you make only a minor change in the structure later, you’ll need to modify the entire structure. SUMMARY • In the Functional Model, software converts information. and to accomplish this, it must perform at least three common tasks- input, processing and output. When functional models of an application are created, the software engineer emphasizes problem specific tasks. The functional model begins with a single reference level model (i.e., be manufactured). In a series of iterations, more and more functional detail is given, until all system functionality is fully represented. • Data modeling, sometimes also called information modeling, is the process of 136 CU IDOL SELF LEARNING MATERIAL (SLM)

visually representing what data the application or system will use, and how it will flow. The resulting diagram or other visual representation is meant to be designed in a way that is as easy to understand as possible. The fundamental elements that a data model needs to include and describe are the data objects, more frequently called 'entities', the attributes of those objects/entities, and the relationships between the objects/entities. • Entities, attributes and relationships are reviewed in greater detail in the example use case that follows. We won't be going into diagrams in this lesson; however, it is worth noting that several methods can be used to create the diagrams in data modeling. The two most widely used are UML (Unified Modeling Language), and ERD (Entity-Relationship Diagrams). • Traditionally, data modeling is comprised of three stages: conceptual, logical, and physical modeling. These stages begin at the most abstract, or general, representation of the data (conceptual modeling). Then they proceed systematically to the most detailed representation using physical modeling. • Conceptual modeling primarily identifies the entities (data objects) that the application will deal with, and traditionally does not describe the attributes of those entities. This stage is deliberately abstract, to avoid becoming 'bogged down in details'. This way it allows all of the stakeholders to participate at this stage, without requiring them to have any specific technical knowledge. For example, the representatives of the company who have commissioned the application (who are not necessarily technically-minded) can contribute meaningfully alongside the software engineers (who are necessarily technically-minded) in designing the application. • Logical modeling uses the entities identified during the conceptual modeling stage, and then identifies the attributes these entities should have, along with the relationships between the entities. • Physical modeling is the most detailed stage of data modeling. The previously defined entities, attributes, and relationships are used to design the database structure, 137 CU IDOL SELF LEARNING MATERIAL (SLM)

including all of the necessary details (like the number of tables, columns, and data types needed). • You need a data model to ensure that the developer has a structure of data objects and their flow. Data models help in designing a database at a physical and logical level. A data model also defines primary keys, foreign keys, relational tables, and stored procedures. Once the developers have an idea of how the data flows, they can create a physical database. • When you sort data in the correct order, you can find out which data is unclear. You can also look for missing information and take action. In the long run, this helps in upgrading the base of your project or com KEY WORDS/ABBREVIATION • JCL: Job control language. • Functional requirement: a requirement that specifies a function that a system or system component must be able to perform. • Flowchart or flow diagram: a graphical representation in which symbols are used to represent such things as operations, data, flow direction, and equipment, for the definition, analysis, or solution of a problem. • Directed graph: a graph in which direction is implied in the internode connections. Syn: digraph. • Change tracker: a software tool which documents all changes made to a program • DFD: A DFD shows the flow of data through a system. LEARNING ACTIVITY 1. Write down Data flow Graph of example given below if A = 10 then 138 CU IDOL SELF LEARNING MATERIAL (SLM)

if B > C A=B else A = C endif endif print A, B, C 2. What is E-R diagram? Explain with suitable examples. UNIT END QUESTIONS (MCQ AND DESCRIPTIVE) A. Descriptive Types Questions 1. Convert the ER diagram into a relational database schema. Be certain to indicate primary keys and referential integrity constraints. 2. Suppose you are given the following requirements for a simple database for the National Hockey League (NHL): the NHL has many teams, each team has a name, a city, a coach, a captain, and a set of players, · each player belongs to only one team, each player has a name, a position (such as left wing or goalie), a skill level, and a set of injury records, · a team captain is also a player, · a game is played between two teams (referred to as host_team and guest_team) and has a date (such as May 11th, 1999) and a score (such as 4 to 2). Construct a clean and concise ER diagram for the NHL database using the Chen notation as in your textbook. List your assumptions and clearly indicate the cardinality mappings as well as any role indicators in your ER diagram. 3. State and analyze under which conditions would you decompose a process on a Data- 139 CU IDOL SELF LEARNING MATERIAL (SLM)

Flow Diagram? 4. Identify data-flows by listing the major documents and information flows associated with the system explain with an example. 5. Write data flow graph for: ifA = 50then ifB > C A =B elseA =C endif endif printA,B,C B. Multiple Choice Questions 1. The Unified Modeling Language (UML) has become an effective standard for software modelling. How many different notations does it have? (a) Three (b) Four (c) Six (d) Nine 2. Which model in system modelling depicts the dynamic behavior of the system? (a) Context Model (b) Behavioral Model (c) Data Model (d) Object Model 3. Which model in system modelling depicts the static nature of the system? (a) Behavioral Model (b) Context Model 140 CU IDOL SELF LEARNING MATERIAL (SLM)

(c) Data Model (d) Structural Model 4. Which perspective in system modelling shows the system or data architecture. (a) Structural perspective (b) Behavioral perspective (c) External perspective (d) All of the mentioned 5. The UML supports event-based modeling using diagrams. (a) Deployment (b) Collaboration (c) State chart (d) All of the mentioned Answers 1. (d), 2. (b), 3. (d), 4. (a), 5. (c) SUGGESTED READING • Pressman R.S. (2009). Software Engineering - A Practitioner’s Approach. New Delhi: MGH Publications. • Mall R. (2003). Fundamentals of Software Engineering. New Delhi: PHI • Jalote P. (2019). An Integrated Approach to Software Engineering. New Delhi: Narosa Publications. • Summerville I. (2013). Software Engineering. New Delhi: Pearson Education. • Software Engineering, Sixth Edition, 20~1, Ian Sommerville; Pearson Education. • http://softwareengineeringhub.blogspot.in/2010/03/systemrequirementsspecification. • html http://computersciencesource.wordpress.com/2010/03/14/softwareengineering- 141 CU IDOL SELF LEARNING MATERIAL (SLM)

• object-oriented-modelling/ http://www.software-requirements.tuffley.com/sample.pd • J.H. ter Bekke (1991). Semantic Data Modeling in Relational Environments • John Vincent Carlis, Joseph D. Maguire (2001). Mastering Data Modeling: A User- driven Approach. • Alan Chmura, J. Mark Heumann (2005). Logical Data Modeling: What it is and how to Do it. • Martin E. Modell (1992). Data Analysis, Data Modeling, and Classification. • M. Papazoglou, Stefano Spaccapietra, Zahir Tari (2000). Advances in Object- oriented Data Modeling. • Len Silverston, W.H.Inmon, Kent Graziano (2007). The Data Model Resource Book. Wiley, 1997. ISBN 0-471-15364-8. Reviewed by Van Scott on tdan.com. Accessed November1,2008. • Semantic data modeling\" In: Metaclasses and Their Application. Book Series Lecture Notes in Computer Science. Publisher Springer Berlin / Heidelberg. Volume Series Lecture 943/1995. • Paul R. Smith & Richard Sarfaty (1993). Creating a strategic plan for configuration management using Computer Aided Software Engineering (CASE) tools. Paper For 1993 National DOE/Contractors and Facilities CAD/CAE User's Group. • The European Process Industries STEP Technical Liaison Executive (EPISTLE) by Matthew West and Julian Fowler (1999). Developing High Quality Data 142 CU IDOL SELF LEARNING MATERIAL (SLM)

UNIT 8 SOFTWARE DESIGN 1 Structure Learning Objectives Introduction Objectives, Principles and Concepts Design methodologies Summary Key Words/Abbreviations Learning Activity Unit End Questions (MCQ and Descriptive) References LEARNING OBJECTIVES After studying this unit, you will be able to: • Explain the objectives of system design. • State principles and concepts of system design. • Discuss design methodologies. INTRODUCTION In industrial practices, the term design is often used to mean both architecture and design. In the recent past, professionals used the term design when they dealt with simpler technological products - ones that do not include several different and interconnected technological components such as hardware, software, operators, services, etc. In the 143 CU IDOL SELF LEARNING MATERIAL (SLM)

development of new multi-technology products and services, professionals have recognized the usefulness of the notion of system in dealing with complexity (interconnections level, multi-techno, emergence, etc.).It was due to complexity that structuring the elements that comprise a system became necessary. This structure explains the functional, behavioral, temporal, physical, and other aspects of a system as described in System Architecture. Practitioners found the term structure inadequate to describe all these aspects of a system. The terms architecture and architectural design have been used for approximately 30 years, especially in software intensive systems and other domains, such as the space industry. The set of different types and interrelated structures can be understood as the architecture of the system. The trend today is to consider system architecture and system design as different and separate sets of activities, but concurrent and strongly intertwined. System design includes activities to conceive a set of system elements that answers a specific, intended purpose, using principles and concepts; it includes assessments and decisions to select system elements that compose the system, fit the architecture of the system, and comply with traded- off system requirements. It is the complete set of detailed models, properties, and/or characteristics described into a form suitable for implementation. OBJECTIVES, PRINCIPLES AND CONCEPTS Software design principles are concerned with providing means to handle the complexity of the design process effectively. Effectively managing the complexity will not only reduce the effort needed for design but can also reduce the scope of introducing errors during design. Following are the principles of Software Design 144 CU IDOL SELF LEARNING MATERIAL (SLM)

Fig 8.1 Software Design Problem Partitioning-For small problem, we can handle the entire problem at once but for the significant problem, divide the problems and conquer the problem it means to divide the problem into smaller pieces so that each piece can be captured separately. For software design, the goal is to divide the problem into manageable pieces. Software Design Principles Software design principles are concerned with providing means to handle the complexity of the design process effectively. Effectively managing the complexity will not only reduce the effort needed for design but can also reduce the scope of introducing errors during design. Following are the principles of Software Design Benefits of Problem Partitioning • Software is easy to understand • Software becomes simple • Software is easy to test • Software is easy to modify 145 CU IDOL SELF LEARNING MATERIAL (SLM)

• Software is easy to maintain • Software is easy to expand These pieces cannot be entirely independent of each other as they together form the system. They have to cooperate and communicate to solve the problem. This communication adds complexity. The design phase of software development deals with transforming the customer requirements as described in the SRS documents into a form implementable using a programming language. The software design process can be divided into the following three levels of phases of design: • Interface Design • Architectural Design • Detailed Design Fig 8.2 Phases of design Interface Design: Interface design is the specification of the interaction between a system and its environment. this phase proceeds at a high level of abstraction with respect to the 146 CU IDOL SELF LEARNING MATERIAL (SLM)

inner workings of the system i.e., during interface design, the internal of the systems are completely ignored and the system is treated as a black box. Attention is focused on the dialogue between the target system and the users, devices, and other systems with which it interacts. The design problem statement produced during the problem analysis step should identify the people, other systems, and devices which are collectively called agents. Interface design should include the following details: • Precise description of events in the environment, or messages from agents to which the system must respond. Precise description of the events or messages that the system must produce. • Specification on the data, and the formats of the data coming into and going out of the system. • Specification of the ordering and timing relationships between incoming events or messages, and outgoing events or outputs. Architectural Design: Architectural design is the specification of the major components of a system, their responsibilities, properties, interfaces, and the relationships and interactions between them. In architectural design, the overall structure of the system is chosen, but the internal details of major components are ignored. Issues in architectural design include: • Gross decomposition of the systems into major components. • Allocation of functional responsibilities to components. • Component Interfaces • Component scaling and performance properties, resource consumption properties, reliability properties, and so forth. • Communication and interaction between components. The architectural design adds important details ignored during the interface design. Design 147 CU IDOL SELF LEARNING MATERIAL (SLM)

of the internals of the major components is ignored until the last phase of the design. Detailed Design-Design is the specification of the internal elements of all major system components, their properties, relationships, processing, and often their algorithms and the data structures. The detailed design may include: • Decomposition of major system components into program units. • Allocation of functional responsibilities to units. • User interfaces • Unit states and state changes • Data and control interaction between units • Data packaging and implementation, including issues of scope and visibility of program elements • Algorithms and data structures Objectives of Software Design: • Correctness: A good design should be correct i.e. it should correctly implement all the functionalities of the system. • Efficiency: A good software design should address the resources, time and cost optimization issues. • Understandability: A good design should be easily understandable, for which it should be modular and all the modules are arranged in layers. • Completeness: The design should have all the components like data structures, modules, and external interfaces, etc. • Maintainability: A good software design should be easily amenable to change 148 CU IDOL SELF LEARNING MATERIAL (SLM)