Ch-3 Software Requirements and Feasibility Analysis.pptx

jjfgukyfyk

1. Chapter : 3 Software Requirements and Feasibility Analysis DATA AND INFORMATION

2. FACT FINDING TECHNIQUES Fact-finding techniques are the methods used to collect information about a system, process, or problem to be solved—especially during the system analysis phase of the Software Development Life Cycle (SDLC). These techniques help analysts understand the current system, user needs, and any existing issues, so they can propose effective improvements or new systems. It includes: Interview Questionnaire Record Review Observation

3. Interview:- The analyst use interviews to collect information from individuals or from groups. The respondents are generally current users of the existing system or managers. The interview can either be structured or unstructured type. Example : Interviewing a bank employee to understand how they process loan applications manually.  

4. 2. Structured Interview Ensures uniform wording of questions for all respondents. Results in shorter interviews Easy to administer and evaluate. Limited interviewer training is needed. Cost of preparation is high. Respondent may not accept high level of structure and mechanical posing of question.

5. 3. Unstructured Interview Interviewer has greater flexibility in wording questions to suit respondent. May produce information about the areas that were overlooked or not thought to be important. Takes extra time to collect essential facts. Analysis and interpretation of results may be lengthy. The success of an interview depends on the skill of the interviewer and on his or her preparation for the Interview.

6. 4.Questionnaire The use of Questionnaire allows analyst to collect information about various aspects of a system from large number of a system from a large number of persons. The use of standardized question formats can yield more reliable data than other fact-finding techniques. Questionnaires should also be tested and if necessary, modified before being printed and distributed. The analyst should ensure that the respondents‟ background and experiences qualify them to answer the question. Example : Sending a Google Form to students to find out how they use the college’s learning management system (LMS).

7. 5.Record Review Analysts examine the information that has been recorded about the system and users. Record inspection can be performed at the beginning of the study, as an introduction, or later in the study, as a basis for comparing actual operations with what the records indicate should be happening. It includes written policy manuals, regulations and standard operating procedures used by most organizations as a guide for managers and employees. Example : Reviewing previous year’s sales reports and customer feedback forms.

8. 6.Observation   Through observation, analyst can obtain firsthand information about how activities are carried. This method is useful when analyst need to actually observe how documents are handled, how process are carried out and whether specified steps are actually followed. Experience observer knows what to look for and how to assess the significance of what they observe. Example : Observing a receptionist booking appointments to see how they interact with the software.

9. Feasibility study Whenever any user request is clarified, then it is very much important to determine whether the system request is feasible or not. There are three aspects in the feasibility study Technical feasibility: Can the work for the project be done with current equipment, existing software technology and available person? Economic feasibility: Are there sufficient benefits in creating the system to make the cost acceptable? Operational feasibility: will the system be used if it is developed and implemented? The feasibility study is carried out by a small group of people who are familiar with information system techniques as well as the routine and detail activities of the organization.

10. Requirements Engineering Tasks The process of collecting the software requirement from the client then understand, evaluate and document it is called as requirement engineering. Requirement engineering constructs a bridge for design and construction . It ensures that the software being developed meets the needs of users, customers, and other stakeholders. Requirement engineering consists of seven different tasks as follow:

11. Inception Elicitation Elaboration Negotiation Specification Validation Requirements Management

12. 1 Inception: Inception is the first step in requirements engineering. Here, developers and customers discuss the problem and decide what the software should do . The main goal is to understand the project scope (what to build, what not to build) and build trust between customer and developer. Developers ask basic questions like: Who will use the system? What should the system do? What problems are we solving? What will be the benefits? Example : Asking hospital staff what features they need in a patient management system.

13. 2. Elicitation: Elicitation means finding out the requirements from customers, users, or stakeholders. This step is tricky because customers may not always know exactly what they want or may change their minds. Common Problems in Elicitation: Problem of Scope Customers sometimes give too much technical detail instead of explaining the main goals . This makes it hard to see the overall purpose of the system. Example : Instead of saying “We need an attendance app,” the customer says “Use Java and MySQL” —but doesn’t clearly explain the actual need.

14. Problem of Understanding Sometimes, there is a gap in understanding between customer and developer. The customer may not know the system’s technical limits, and the developer may not fully understand the customer’s business needs. Example : The customer thinks the app will work offline everywhere, but the developer knows it needs internet for some features. Problem of Volatility Requirements may change frequently as the project goes on. This creates difficulty in development and planning. Example : At first, the customer wants attendance only for students, later they ask to also track teachers, and then add parent notifications.

15. 3.Elaboration: In Elaboration , the information collected from the user during Inception is expanded and refined . The goal is to make the requirements clearer and more detailed . Here, developers create a model of the software that shows: Functions (what the system will do) Features (special characteristics) Constraints (rules or limits, like speed, security, or budget).

16. Example Suppose the customer wants a student attendance app . In Inception : The requirement is “an app to manage student attendance.” In Elaboration : The developer refines this into detailed features: The app will allow teachers to mark attendance daily . Parents will get SMS notifications if a student is absent. 4. Negotiation: In Negotiation , the developer and customer discuss and agree on which requirements are possible with the available time, budget, and resources . Not all requirements can always be included, so both sides must prioritize what is most important. The software engineer also makes rough estimates of cost, effort, and delivery time.

17. Example: Customer wants a school app with attendance, fees, exams, and transport tracking. Developer explains the budget is limited, so in negotiation they agree to build attendance + fees first, and add the rest later.

18. 5.Specification: Specification means writing down the final set of requirements clearly and completely. The result is a document called Software Requirement Specification (SRS) . It describes: Informative requirements → general details of the system Functional requirements → what the system should do Behavioral requirements → how the system should behave in different situations Requirements can be written in text (sentences, tables) and diagrams (flowcharts, use case diagrams, etc.). Example For a library management system, the SRS might include: Functional: “The system shall allow users to search books by title, author, or ISBN.” Behavioral: “If a book is not available, the system shall show a waitlist option.” Graphical: A use case diagram showing how students interact with the system.

19. 6.Validation: Validation means checking if the written requirements are correct and complete . The goal is to make sure the software being planned is really what the customer needs . This is usually done through reviews, meetings, or prototypes with the customer, developers, and other stakeholders. Example For a hospital management system , the requirement says: “The system shall allow doctors to view patient history.” During validation , the doctor reviews it and says: “Yes, but we also need nurses to view patient history.”

20. 7. Requirement Management: Requirement Management means handling and tracking requirements throughout the project. Since requirements can change anytime, the project team needs to identify, control, and update them properly . Each requirement is given a unique ID so it can be tracked easily. A Requirement Traceability Table (RTT) is created to connect each requirement with: its feature , its source (who requested it), its dependencies , related subsystems , and interfaces .

21. Example: For a shopping app : Requirement ID: R1 → “User can add items to cart” (Feature) Source: Customer request Dependency: Needs user login Subsystem: Cart Module Interface: Works with payment system If later the customer changes “cart” to “ wishlist + cart,” the team updates the requirement using this ID and traceability table.

22. I ntroduction Data flow diagrams Data Flow Diagram  is a  visual representation  of the flow of data within the system. It help to understand the flow of data throughout the system, from input to output, and how it gets transformed along the way. The models enable  software engineers , customers, and users to work together effectively during the analysis and  specification of requirements . Characteristics of DFD Shows data movement – It explains how data flows from input to output in a system. Uses simple symbols – Circles (process), arrows (data flow), rectangles (external entities), and open boxes (data storage). Easy to understand – Non-technical people can also read it because it is visual, not programming. Different levels – Level 0 (Context diagram): shows the system as a whole. Level 1, 2, …: shows more detailed breakdowns of processes. Focuses on functions, not code – It tells what the system does , not how it is coded. No control flow – Unlike flowcharts, it doesn’t show decision-making or loops, only data flow .

23. DFD Symbol

24. Levelling of DFD Levelling means breaking down a complex system into multiple layers (levels) of Data Flow Diagrams. It starts with a big picture and then moves to detailed views . Levels: Level 0 (Context Diagram) – Shows the whole system as one single process with inputs/outputs. Level 1 DFD – Breaks the single process into main sub-processes and shows how data flows between them. Level 2 (and further) – Gives even more detailed breakdowns of Level 1 processes until requirements are clear. Levelling of DFD

25. 0th level DFD (Context Diagram) shows the whole system as one single process with its inputs (from external entities) and outputs (to external entities) , without internal details. Levelling of DFD

26. 1st Level DFD

27. 2nd Level DFD

28. Data Dictionary (DD) A Data Dictionary is like a catalog or glossary of all the data used in a system. It gives details about each data item , such as: Name Type (text, number, date, etc.) Size (how many characters/digits) Description (what it means) Where it is used (process, data store, etc.) If data dictionary is developed properly, then any data related questions – answer can be extracted from data dictionary. It is developed during data flow analysis and assists the analysts.

29. Importance of Data dictionary: To manage the detail in large system To communicate a common meaning for all system elements To document the features of the system To facilitate analysis of the details in order to evaluate characteristics and determination when system changes should be made.

30. Data Item Type Size Description Used In Student_ID Number 6 Unique ID of student Database, Reports Name Text 30 Full name of student Admission Form DOB Date — Date of birth of student Student Profile Attendance Number 3 Total days present Attendance Module For a Student Management System , the Data Dictionary may contain: Example

31. A Decision Tree is a diagram that shows decisions and their possible outcomes in a tree-like structure . Each branch represents a choice or condition , and each leaf (end) represents the result . Helps in step-by-step decision-making . A Decision tree is diagram that presents conditions and actions sequentially and thus shows which conditions to consider first, which second and so on. It is also a method of showing the relationship of each condition and its permissible actions. The diagram resembles branches on a tree. Decision Tree

32. Example

33. A Decision Table is a tabular form of decisions, showing conditions and the corresponding actions . Useful when there are multiple conditions that lead to different results. A decision table is a matrix of rows and columns, rather than a tree that shows conditions and actions. The decision table is made up of four sections: Condition statements, condition entry, action statements, and actions entries. Condition Decision rules Condition statements Condition entry Action statements Action entry Decision Table

34. Advantages of Decision Tables   Good documentation of rules used in data processing . Easy to understand by non-computer literate users and managers  Simple representation of complex decision rules . Tabular representation allows systematic validation of specification detection of redundancy , incompleteness & inconsistency of rules Algorithms exist to automatically convert decision tables to equivalent computer programs. Allows systematic creation of test data

35. Components of a Decision Table In  software testing , the decision table has 4 parts which are divided into portions and are given below :

36. Condition Stubs :  The conditions are listed in this first upper left part of the decision table that is used to determine a particular action or set of actions. Action Stubs :  All the possible actions are given in the first lower left portion ( i.e , below condition stub) of the decision table. Condition Entries :  In the condition entry, the values are inputted in the upper right portion of the decision table.   In the condition entries part of the table, there are multiple rows and columns which are known as Rule. Action Entries :   In the action entry, every entry has some associated action or set of actions in the lower right portion of the decision table and these values are called outputs.

37. For example, refer the following table – RULE 1 : If advance payment made                   then give 5% discount RULE 2 : If no advance payment is made and if the purchase amount ≥10,000 and the customer  is a regular customer                 then give 5% discount RULE 3 : If no advance payment is made and if the purchase amount is not ≥ 10,000 and customer is not give a regular customer               then give no discount RULE 4 : If no advance payment is made and if the purchase amount is not ≥ 10,000                    then give no discount observe that these lengthy rules are beautifully summarized by the decision table .

38. Decision Table - Example Same structured English procedure given as decision table CONDITIONS RULE1 RULE2 RULE3 RULE4 Advance Payment Made? Y N N N Purchase Amt>=10,000 - Y N N Regular Customer? - Y N - ACTIONS Give 5% Discount X X - - Give No Discount - - X X

39. Decision Table Explanation Conditions are questions to be asked ‘Y’ is Yes, ’N’ is No & ‘-’ is irrelevant A ‘X’ against the action says the action must be taken A ‘-’ against the action says the action need not be taken A ‘-’ against the action says the action need not be taken Rule 2 in decision table DISCOUNT states: if no advance payment and purchase amount >=10000 and regular customer then give 5% discount

40. Condition / Action Stop Wait Go Light = Red Yes No No Light = Yellow No Yes No Light = Green No No Yes Traffic Light Decision Table

41. Decision Tree Used when sequence of testing condition is important It is more procedural compared to Decision tables

42. Decision Tree - Example

43. Explanation C1: Advance payment made C2: Purchase amount >=10,000 C3: Regular Customer Y = Yes N = No Decision trees are drawn left to right Circles used for conditions

44. When to use Decision Table or Decision Tree?   Use Decision tables when there are a large number of conditions to check and logic is complex  Use Decision trees when sequencing of conditions is important and if there are not many conditions to be tested.