EContent_11_2024_04_24_08_30_24_Unit3_PPTpptx__2024_04_05_09_12_25.pptx

SE

1. Department of Computer Engineering Prof. Krishna nand Mishra Unit 3 Requirement Analysis and Design Concepts Subject Code: 01 CE 060 7

2. Contents Requirement Engineering Requirement Elicitation Requirement Analysis Requirement Documentation Requirement Validation Requirement Reviews Design Concepts Design Principles Design Model Architectural Design Component Level Design User Interface Design Web App Design Effective Modular Design Cohesion Coupling Design Documentation

3. Requirement Engineering

4. Requirement Engineering Requirement A function that the system must provide to fill the needs of the system’s intended user. Engineering Implies that systematic and repeatable techniques should be used. Requirement Engineering It is a systematic approach to define, manage and test requirements for a software.

5. Requirement Engineering Requirement engineering provides the appropriate mechanism for understanding What customer wants Analyzing needs Assessing feasibility Negotiating a reasonable solution Specifying solution unambiguously Validating the specification Managing requirements

6. Requirement Engineering Steps Requirements Elicitation (Requirement Gatherin g) Interviews Brainstorming Facilitated Application Specification Technique Quality Function Deployment 2. Requirements Analysis Data Flow Diagrams Data Dictionaries E-R Diagrams, Software Prototyping

7. Requirement Engineering Steps 3. Requirements Documentation SRS 4. Requirements Validation Requirements Reviews 5. Requirements Management

8. Functional requirements Functional Requirements Any requirement which specifies what the system should do. They are basically the requirements stated by the user which one can see directly in the final product, unlike the non-functional requirements. How the system should react to particular inputs

9. Functional requirements Example : Library Management System Registration Login Add/Delete/Update Books Search Books Issue Books Return Books Reserve Books Pay for Fine (if late returned) Add Books in inventory

10. Requirement Modeling and Analysis Any requirement which specifies how the system performs a certain function. A non-functional requirement will describe how a system should behave and what limits there are on its functionality.

11. Non-functional Requirements Any requirement which specifies how the system performs a certain function. A non-functional requirement will describe how a system should behave and what limits there are on its functionality. Example Response time Throughput Availability Reliability Security Maintainability Interoperability Scalability Capacity Manageability

12. What is D e s i gn ? Des ig n i s a mea n in g f u l eng i nee r in g repres e ntation of something that is to be built. It's a process by which requirements are translated into blueprint for constructing a software

13. Architectural Design Data/Class Design Procedural Design Interface Design • Swimlane diagrams Design Models Analysis Models Scenario-based elements Use cases - text Use-case diagrams Activity diagrams Flow-oriented elements Data flow diagrams Control-flow diagrams Processing narratives Behavioral elements State diagrams Sequence diagrams Class-based elements Class diagrams Analysis packages CRC models Collaboration diagrams Design Mo d e l s

14. Design Mo d e l s I n th e soft w are engi n eer i ng c ontex t , de s ig n fo c uses on four major areas of concern: data, architecture, interfaces, and components Soft w are des i gn c o ncepts can b e appli e d re g ardl e ss of the software process model that is used. Design task produces: Architectural design Data design Component design Interface design

15. Design Mo d e l s A r c h i t e c tur a l D e sign I t de f ine s th e relat io nship betw e en major stru c tu r al elements of the software. Architecture “constitutes a relatively small, intellectually graspable model of how the system is structured and how its components work together” Data Design It transforms the information domain model into the data structures. Data objects and relationships are defined using the entity relationship diagram.

16. Design Mo d e l s Component-level Design(Procedural Design) It transforms structural elements of the software architecture into a procedural description of software components. Interface Design It describes how the software communicates within itself, with systems that interoperate with it, and with humans who use it. An interface implies a flow of information and a specific type of behavior. Data and control flow diagrams provide much of the information required for interface design.

17. Software Design C o nc e p t s Software engineer is to recognize the difference between getting program to work and getting it right Eac h de s i gn c o ncept he l ps t o answer t he fo l low i ng questions What c r it e ria can b e used t o parti t io n s oft w are in t o individual components? How is function or data structure detail separated from a conceptual representation of the software? What u n if o rm c r iteri a define t h e technica l qua l it y o f a software design? Fundamental software design concepts provide the necessary framework for “getting it right.”

18. Software Design C o nc e p t s Abstraction Refinement Modularity S o f t ware A r c hitect u re Control Hierarchy Structural Partitioning Data Structure S o f t wa r e P r o c e d u re Information Hiding

19. Abstraction At the highest level of abstraction , a solution is stated in broad terms. A t lowe r level s o f a bst r a c ti o n , a mo re detail e d description of the solution is provided. At the lowest level of abstraction, the solution is stated in a manner that can be directly implemented.

20. Abstraction Two types of abstraction: 1. P r oce d ural abstr a cti o n : S e q u ence o f instr u ctions that have a specific and limited function. Ex. Open a door Open implies long sequence of activities (e.g. walk to the door, grasp knob, turn knob and pull the door, etc). 2. Data abstraction: collection of data that describes a data object. Ex. Open a door. – door is data object. Data abstraction for door would encompass a set of attributes that describe the door. (E.g. door type, swing direction, opening mechanism, etc.)

21. Refinement Refinement is actually a process of elaboration. It’s begin with a statement of function (or description of information) that is defined at a high level of abstraction. That is, the statement describes function or information c o ncept u al l y but pr o v id e s n o i n fo r mat io n abo u t the internal workings of the function or the internal structure of the information. Refinement causes the designer to elaborate on the original statement, providing more and more detail as each successive refinement (elaboration) occurs.

22. Refinement Abst r action and r e finement are c o mpl e men t ary concepts. Abstraction enables a designer to specify procedure and data and yet suppress low-level details. Refin e ment helps th e des i gner t o expo s e lo w - le v e l details as design progresses.

23. Mo d u l arit y Software i s d i v ide d into sep arat e l y n a m e d a n d ad d ressa b l e c o m p onents, sometimes c a lle d mo d ules, which are integrated to satisfy problem requirement. Modularity is the single attribute of software that allows a pro g ram t o b e intel le c tu a ll y man a geabl e . I t lead s t o a “ d iv i de a n d c o nque r ” st r ategy, in w h ic h a c o mp le x problem when you break into a manageable pieces. Unde r mo d u l a r it y a n d ove r mod u l a r it y should be avoided.

24. Mo d u l arit y Modular decomposability: If a design method provides a systematic mechanism for decomposing the problem into sub-problems, it will reduce the complexity of the overall problem, thereby achieving an effective modular solution. Modular composability: If a design method enables existing (reusable) design components to be assembled into a new system, it will yield a modular solution that does not reinvent the wheel. Modular understandability: If a module can be understood as a standalone unit (without reference to other modules), it will be easier to build and easier to change.

25. Software Ar c hite c tur e Software architecture alludes to “the overall structure of the software and the ways in which that structure provides conceptual integrity for a system. Call and return Architecture.

26. Structural Partitio n i n g Two types of Structure partitioning: Horizontal Partitioning Vertical Partitioning

27. Horizontal Partitio n i n g It defines separate branches of the modular hierarchy for each major program function. Control modules, represented in a darker shade are used t o coo r dinate c o mm u nicat io n & executi o n bet w een its functions. Horizontal partitioning parti t ions — in p ut, data t r ans f o r ma t ion de f ines ( o ften thr e e call e d processing) and output. Benefits of horizontal partitioning: software that is easier to test software that is easier to maintain propagation of fewer side effects software that is easier to extend

28. Horizontal Partitio n i n g On the negative side (Drawback), horizontal partitioning often causes more data to be passed across module interfaces and can complicate the overall control of program flow.

29. Vertical Partitio n i n g It is often referred as factoring . This suggests that control (decision making) and work should be distributed top- down in the program structure. Top-level modules should perform control functions and do little actual processing work. Modules that reside low in the structure should be the workers, performing all input, computation, and output tasks. A change in a control module (high in the structure) will have a higher probability of propagating side effects to modules that are subordinate to it. Vertically partitioned structures are less likely to be susceptible to side effects when changes are made and will therefore be more maintainable.

30. Control Hierar c h y , Software Procedure Control pro g ram Hierarc h y – Con t r o l h ie r archy, a ls o cal l e d s t ruct u re, represent t he o r gani z a t io n of program components and implies a hierarchy of control. It does not represent procedural aspects of software such as sequence of processes, occurrence or order of decision or repetition of operations Software Procedure: Program structure defines control hierarchy without regard to the sequence of processing and decisions. Software procedure focuses on the processing details of each module individually. P r ocedure m ust pr o v id e a pre c is e specific a tion of processing, including sequence of events, exact decision points, repetitive operations, and even data organization and structure.

31. I n f or m atio n Hiding M o d u les s hou l d b e spec i f ie d a nd design e d so that inf o r ma t io n ( a lgo r ithm and data) c o ntained within a mo d u l e is i n accessible t o o t her mo d u les t h at have no need for such information. The intent of information hiding is to hide the details of data st r uc t u r e a nd p ro cedu r al pr o cessing behin d a module interface. It gives benefits when modifications are required during testing and maintenance because data and procedure are hiding from other parts of software, unintentional errors introduced during modification are less.

32. Data S tru c tur e D a t a stru c tu r e is a representation of the logical relationship among individual elements of data. Linked list Two-dimensional matrix Sequential vector

33. Design Pri nc i p l e s

34. Design Pri nc i p l e s 1. Should not suffer from “Tunnel Vision” – It should not only focus on completing or achieving the aim but on other effects also Traceable to analysis model – It should satisfy all the requirements that software requires to develop a high- quality product. Should not “Reinvent The Wheel” – It should not waste time or effort in creating things that already exist. Due to this, the overall development will get increased. Minimize Intellectual distance – The design process should reduce the gap between real-world problems and software solutions for that problem meaning it should simply minimize intellectual distance.

35. Design Pri nc i p l e s 5. Exh i b i t u n if o r m it y a nd in t egr ation – I t should be uniform throughout the process without any change. Integration means it should mix or combine all parts of software i.e. subsystems into one system. Accommodate change – The software should adjust to the change that is required to be done as per the user’s need. Degrade gently – The software should be designed in such a way that it degrades gracefully which means it should work properly even if an error occurs during the execution

36. Design Pri nc i p l e s 8. Assessed or quality – The design should be assessed or evaluated for the quality meaning that during the evaluation, the quality of the design needs to be checked and focused on. Review to discover errors – The overall evaluation should be done to check if there is any error present or if it can be minimized. Design is not coding and coding is not design – Design means describing the logic of the program to solve any problem and coding is a type of language that is used for the implementation of a design.

37. E ff e ct i v e M odula r D e s i g n Functional Independence Cohesion Coupling

38. Co h es i o n & Coupling A good software design implies clean decomposition of the problem into modules, and the neat arrangement of these modules in a hierarchy Cohesion is a measure of the degree to which the elements of the module are functionally related. A cohesive module performs a single task within a software pro c edure, req u i r in g littl e inte r a ction with pr o cedu r es bein g performed in other parts o f a program. Coupling is an indication of the relative interdependence among modules. If two modules interchange large amounts of data, then they are highly interdependent. The prima r y c h ara c teris t ics o f neat mo d ule decomposition are high cohesion and low coupling

39. C la ss i f i c a t i o n o f Coh e si o n Cohesion is an indication of the relative functional s t rength o f a m o d ul e .

40. C la ss i f i c a t i o n o f Coh e si o n Coincidental cohesion A module is said to have coincidental cohesion, if it performs a set of tasks that relate to each other very loosely. The module contains a random collection of functions. It is likely that the functions have been put in the module out of pure coincidence without any thought or design. Ex- in a transaction processing system (TPS), the get- input, print-error, and summarize-members functions are grouped into one module.

41. C la ss i f i c a t i o n o f Coh e si o n L o g i c a l c o h e sion A module is said to be logically cohesive, if all elements of the module perform similar operations. Ex- error handling, data input, data output, etc. Temporal cohesion When a module contains functions that are related by the fact that all the functions must be executed in the same time span. Ex: the set of functions responsible for initialization, start-up, shutdown of some process, etc. P r o c edural c o h e si o n If the set of functions of the module are all part of a procedure (algorithm) in which certain sequence of steps have to be carried out for achieving an objective For Ex., the algorithm for decoding a message.

42. C la ss i f i c a t i o n o f Coh e si o n Communicational cohesion If all functions of the module refer to the same data structure Ex: the set of functions defined on an array or a stack. Sequential cohesion If the elements of a module form the parts of sequence, where the output from one element of the sequence is input to the next. Ex- In a TPS, the get-input, validate-input, sort-input functions are grouped into one module.

43. C la ss i f i c a t i o n o f Coh e si o n Functional cohesion If different elements of a module cooperate to achieve a single function. Ex- A module containing all the functions required to manage employees’ pay-roll exhibits functional cohesion.

44. C la ss i f i c a t i o n o f Cou p lin g Coup l in g be t ween two mod u les is a measure o f the degree of interdependence or interaction between the two m o d ule s . If two modules interchange large amounts of data, then the y are h ighly interdependent. High Coupling Low Coupling

45. C la ss i f i c a t i o n o f Cou p lin g D a t a c o u pli n g Two modules are data coupled, if they communicate through a parameter. Ex-an elementary data item passed as a parameter between two modules, e.g. an integer, a float, a character, etc. S t a m p c o u p l ing If they communicate using a composite data item Ex- if data is passed using structure(array) in C. Control coupling If data from one module is used to direct the order of instructions execution in another. Ex - f l ag set i n one mo d u l e a n d tested i n another module.

46. C la ss i f i c a t i o n o f Cou p lin g E x t ernal C o u pl i n g : In external coupling, the modules depend on other modules, external to the software being developed or to a particular type of hardware. Ex- protocol, external file, device format, etc Common coupling Two modules are common coupled, if they share data through some global data items. Content coupling C o ntent cou p lin g e x ist s bet w een tw o modu l es, if they share code. Con t ent coup l in g o c cu r s when o n e c o m p on e nt secretly modifies data that is internal to another component. This violets information hiding – a basic design concept

47. U se r I n t er f a c e Design User int erface communication computer. design creates med i u m betwee n a an eff e ct i v e h u man a nd a By following a set of interface design principles, Designer identifies interface objects and actions and then creates a screen layout that forms the basis for a user interface prototype.

48. Design Rules fo r U se r I n t er f ace - Th e Golden Rules 1. Place the User in Control During a requirements-gathering session for a major new information system, a key user was asked about. Following are the design principles that allow the user to maintain control: D e fine i n t eraction m o des in a w ay tha t d o es n o t force a user into unnecessary or undesired actions. Provide for flexible interaction . A l lo w user interac t i o n t o b e inter r upt i ble a n d undoable . Streamli n e interacti o n as sk i l l level s a dv a nce and allow the interaction to be customized . Hide technical internals from the casual user. Design for direct interaction with objects that appear on the screen.

49. Design Rules fo r U se r I n t er f ace - Th e Golden Rules 2. Reduce the User’s Memory Load The mo re a user has t o remembe r , th e mo re er r o r - prone the interaction with the system will be. Fo l lowin g are th e des i gn p r in c iple s t h at enab l e an interface to reduce the user’s memory load: Reduce demand on short-term memory. Establish meaningful defaults. Define shortcuts that are intuitive. The visual layout of the interface should be based on a real-world metaphor. Disclose information in a progressive fashion.

50. Design Rules fo r U se r I n t er f ace - Th e Golden Rules 3. Make the Interface Consistent The interface should present and acquire information in a consistent fashion. Fo l lowin g a re th e d esign p r inci p les tha t he l p make t h e interface consistent: Maintain consistency across a family of applications. If pa s t int eractive models h ave c r eated user expectations, do not make changes unless there is a convincing reason to do so.

51. T H A N K Y O U