(b) Waterfall

The Waterfall model is the classic linear sequential model in which each phase (requirement analysis, design, coding, testing, maintenance) is completed fully before the next one begins, with no going back. Agile and Scrum are iterative/incremental, and Prototype is evolutionary.

Technical Feasibility

Technical feasibility is the study that determines whether the proposed system can actually be developed and operated with the available technology, hardware, software and technical manpower. It checks whether the required technology exists and whether the organisation has the skill to use it.

The main points examined in technical feasibility are:

• Availability of technology: Whether the hardware (computers, servers, networking devices) and software (operating system, DBMS, programming tools) needed for the system are available in the market.
• Technical skills of the staff: Whether the existing IT staff or newly hired personnel have the knowledge and experience to design, develop and maintain the system.
• Compatibility: Whether the new system can work together with the existing system and hardware without major conflicts.
• Scalability and reliability: Whether the system can handle the expected volume of data and users, and whether it gives correct and consistent results.
• Availability of technical support: Whether the vendor or developer provides training, updates and maintenance support after installation.

If the system is not technically feasible, it is either rejected or the technology and manpower are arranged before development begins.

Economic Feasibility

Economic feasibility is the study that determines whether the benefits obtained from the proposed system are greater than the cost of developing and operating it. It is also called cost–benefit analysis. A system is economically feasible only when its total benefits exceed its total costs.

The costs and benefits considered are:

• Development costs: Cost of hardware, software, salaries of analysts, programmers and testers, training cost and cost of data conversion.
• Operational costs: Cost of maintenance, repair, electricity, internet, consumables and salaries of operating staff.
• Tangible benefits: Directly measurable savings such as reduction in staff, saving of stationery, faster processing and increased sales.
• Intangible benefits: Benefits that cannot be measured in money, such as better customer service, improved accuracy, timely information and good goodwill of the organisation.

The common measures used in economic feasibility are:

• Net Benefit = Total Benefits − Total Costs
• Payback Period = Time required to recover the investment from the benefits
• Return on Investment (ROI) = $\dfrac{\text{Net Benefit}}{\text{Total Cost}} \times 100\%$

If the total benefits are more than the total costs and the payback period is acceptable to the management, the system is considered economically feasible and development is approved.

(c) Unit Testing

Unit testing tests the smallest functional units of code (individual modules or functions) in isolation, so option (c) is correct. Functional, method and system testing operate on larger parts of the software.

Agile Method of Software Development

Agile is an iterative and incremental software development methodology in which the software is built and delivered in small, working increments called iterations (or sprints), rather than being delivered all at once at the end of the project. It is based on the Agile Manifesto (2001), which values:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a fixed plan

Key Features

1. Iterative and incremental development: The whole project is divided into small cycles (usually 1–4 weeks). Each cycle produces a partially working, tested product.
2. Continuous customer involvement: The customer reviews each iteration and gives feedback, so requirements can be changed at any stage.
3. Working software as the main measure of progress: A usable version is delivered at the end of every iteration.
4. Adaptability to change: New or changed requirements are welcomed, even late in development.
5. Self-organizing teams: Small, cross-functional teams plan and manage their own work with daily short meetings (stand-up meetings).
6. Simple and continuous delivery: Features are delivered frequently, reducing risk and getting value to the user early.

Common Agile Frameworks

• Scrum: Work is done in fixed-length sprints with roles such as Product Owner, Scrum Master and Development Team.
• Extreme Programming (XP): Emphasises pair programming, test-driven development and frequent releases.
• Kanban: Uses a visual board to limit work-in-progress and manage flow.
• Lean, Crystal, Feature-Driven Development (FDD) etc.

Advantages

• Early and continuous delivery of useful software
• High customer satisfaction due to constant feedback
• Easy accommodation of changing requirements
• Early detection of defects and risks
• Better team communication and motivation

Disadvantages

• Difficult to estimate time and cost accurately
• Requires close and continuous customer involvement
• Less emphasis on documentation, which can cause problems in maintenance
• Not suitable for large, safety-critical projects with fixed requirements

In short, the Agile method develops software in short, repeated cycles with constant customer feedback, allowing the team to deliver working software quickly and adapt easily to changing needs.

(c) Technical feasibility

Technical feasibility checks whether the required hardware, software and technical skills are available to develop and run the proposed system.

Requirement Gathering is the process of collecting the needs, expectations and constraints of the users and other stakeholders of a software system, so that the developers can clearly understand what the system must do before design and coding begin. It is the first and most important phase of the System Development Life Cycle (SDLC); errors left here become very costly to fix later.

Requirement Gathering Methods

1. Interview — The analyst meets users and managers face to face (or online) and asks questions. It allows follow-up questions and clarification of unclear points. It is best for a small number of key users, but it is time-consuming and the answers may be biased.

2. Questionnaire / Survey — A set of written questions is distributed to many users, who fill it in and return it. It is cheap, quick and reaches a large, scattered group, but there is no chance to explain questions, so answers may be vague or incomplete.

3. Observation (Site Visit) — The analyst watches users actually doing their work in their own environment. It reveals real practices and problems that users themselves may not report. However, users may behave differently when they know they are being watched, and it takes a lot of time.

4. Document Analysis — Existing forms, reports, manuals, files and procedure manuals are studied. These give reliable facts about the present system and its data. The limitation is that documents may be outdated or may not describe what really happens.

5. Prototyping — A small working model of the system is built and shown to users, who give feedback and suggest changes. Requirements become clear through iteration. It needs extra time and tools, and users may expect the final system too early.

6. Brainstorming / JAD (Joint Application Development) — Users, managers and developers meet together in a focused workshop to list and discuss requirements. It produces agreed requirements quickly, but needs careful planning and a skilled facilitator.

7. Prototyping by Use-Case / Scenario Discussion — Users describe typical tasks step by step and the analyst records them as use cases. This is useful for understanding workflows and exceptions.

Usually a combination of these methods is used, because each one covers the weakness of the others.

(a) Waterfall model

The waterfall model is the classic sequential SDLC model in which each phase — requirements gathering, design, implementation, testing, deployment and maintenance — is completed before the next begins, giving a strictly linear downward progression like a waterfall.

Requirement gathering (also called requirement elicitation) is the first and most critical activity of the analysis phase of the SDLC. Its purpose is to discover what the users actually need and what the system must do, before any design or coding begins. Because different users have different viewpoints and different ways of expressing themselves, no single technique is sufficient. A combination of techniques gives a more complete, accurate and verifiable picture of the requirements. The main techniques and how each helps are described below.

1. Interviews A systems analyst meets users and stakeholders face to face (or online) and asks questions. Open-ended questions bring out opinions, feelings and problems; closed questions confirm specific facts. Interviews help because the analyst can probe deeper, clarify doubts immediately, and read body language. They are useful for getting the views of top management and for understanding the real problem behind a stated request. Their limitation is that they are time-consuming and the information may be biased by the views of the few people interviewed.

2. Questionnaires A set of written questions is distributed to many users, who fill it in and return it. This technique helps when the users are large in number and geographically scattered (for example, all branch staff of a bank). It is cheap, quick and gives uniform, quantifiable data that is easy to tabulate. It helps in confirming whether the needs found in interviews are common to all users. Its weakness is that questions cannot be explained and unclear answers cannot be followed up.

3. Observation (on-site observation) The analyst personally watches users performing their daily work in their own environment. This helps because users often cannot describe what they do, or they describe the ideal procedure rather than the actual one. Observation reveals real work practices, bottlenecks, delays, manual shortcuts and exceptions. It is especially useful for understanding operational-level tasks. Its drawback is that people may behave differently when they know they are being watched (the Hawthorne effect), and it takes a lot of time.

4. Document analysis / record review The analyst studies existing documents such as forms, invoices, reports, manuals, organization charts, procedure books and past system documentation. This helps in understanding the present system, the data items used, the volume of transactions, the rules followed and the outputs expected. It gives factual evidence rather than opinions, and it is a good starting point before interviewing users.

5. Prototyping A small working model (throwaway or evolutionary) of the proposed system is built quickly and shown to users. Users can see and try the system, so they can point out what is missing or wrong. This helps because users often cannot state requirements in the abstract but can react well to something concrete. It reduces misunderstanding and rework, and it clarifies the user interface requirements.

6. Joint Application Development (JAD) / group techniques In JAD, users, managers and developers meet in structured workshops led by a facilitator to define requirements together. This helps by resolving conflicts between departments on the spot, building consensus, and shortening the time needed for requirement collection. Brainstorming and focus groups work in a similar way.

7. Use cases and scenario analysis The analyst describes how an actor interacts with the system to achieve a goal. This helps in capturing functional requirements in the user's own language and in identifying normal and exceptional flows.

How these techniques together give a careful grasp of user needs

• Cross-checking (triangulation): Facts collected by one method are verified by another. For example, what a user says in an interview is checked against what is observed and what the documents show. This reduces errors and bias.
• Covering all stakeholders: Interviews and JAD reach management and key users; questionnaires reach the mass of users; observation reaches operators. Thus needs at every level are captured.
• Revealing both stated and hidden requirements: Interviews and questionnaires give stated needs; observation and document analysis uncover unstated and implicit needs.
• Clarifying and validating: Prototypes and use cases let users confirm that the analyst has understood them correctly, so requirements become clear, complete, consistent and testable.
• Reducing risk and cost: Careful requirement gathering prevents missing or wrong requirements, which are the most expensive defects to fix later in the SDLC.

Conclusion Each technique has its own strengths and weaknesses. A good analyst therefore uses a mix of techniques — interviews and JAD for depth, questionnaires for breadth, observation and document analysis for reality, and prototyping and use cases for validation. This combination produces a careful, accurate and agreed-upon statement of user needs and system requirements, which becomes the foundation for all later phases of the SDLC.

(a) Planning

Feasibility analysis is carried out in the planning (preliminary investigation) phase of the SDLC, where the project's technical, economic, operational and schedule viability is assessed before any design or coding begins.

Requirement Collection Methods in Software Development

Requirement collection (also called requirement elicitation or gathering) is the first and most important phase of the System Development Life Cycle (SDLC). In this phase, the analyst collects the needs and demands of the users and the system. If requirements are collected wrongly, the whole software may fail. The main methods used for requirement collection are described below.

1. Interview

In this method the system analyst meets the users, managers and other stakeholders face to face and asks them questions about the existing system and the required system. It may be structured (fixed questions asked in a set order) or unstructured (open discussion). It is useful for collecting detailed and confidential information, and the analyst can also observe the body language of the users. Its main drawback is that it is time-consuming and costly, and the information collected may be biased by the views of a few persons only.

2. Questionnaire

Here a set of questions is prepared and distributed to many users, who fill it in and return it. The questions may be open-ended (free answers) or closed-ended (fixed choices such as yes/no or multiple choice). This method is cheap, quick and can cover a large number of users situated far apart. However, the questions may be misunderstood, and the users cannot be asked to explain their answers, so the information may be incomplete.

3. Observation

In this method the analyst personally visits the workplace and watches how the users actually do their work. It may be passive (the analyst only watches) or active (the analyst also takes part in the work). It helps to find out the real problems and the actual working procedure, which users may forget to tell in an interview. Its limitation is that it is time-consuming, and users may behave differently when they know they are being watched.

4. Document Analysis

The analyst studies the existing documents of the organization such as forms, reports, invoices, manuals, files and records. This gives a clear picture of the present system, its data and its outputs. It is a cheap method and useful for understanding the rules and formats of the organization. But the documents may be outdated or incomplete, so this method is usually used together with other methods.

5. Prototyping

In this method a small working model (prototype) of the software is built quickly and shown to the users. The users give their feedback, and the prototype is improved again and again until the users are satisfied. It is very useful when the users are not clear about their requirements. The main drawback is that building prototypes again and again takes more time and cost.

6. Joint Application Development (JAD)

In JAD, all the stakeholders — users, managers and developers — meet together in a workshop session guided by a facilitator to discuss and finalize the requirements. It saves time, reduces misunderstanding and takes quick decisions. However, it needs a skilled facilitator, and it may be difficult to gather all the members at one place and time.

7. Brainstorming

In this method a group of users and experts sit together and put forward their ideas freely about the new system. All ideas are noted without criticism and later evaluated. It helps to generate new and creative ideas for the system. But it may produce many impractical ideas, so proper screening is needed.

Conclusion: Each method has its own advantages and limitations. Therefore, a good system analyst does not depend on only one method; he/she uses a combination of methods such as interview, questionnaire and observation to collect complete and correct requirements.

(c) testing

Testing is the SDLC phase in which the developed software is checked against the requirements to find errors and defects, so it is the phase that ensures the software meets the required quality before delivery.

System testing is the phase of the SDLC in which the completely integrated software system is tested as a whole against the requirements gathered during analysis. Its importance lies in the fact that it is the first level of testing performed on the entire system rather than on individual modules, so it verifies that all units work together correctly and that the final product meets the user's needs before it is delivered.

Importance of system testing in the SDLC:

1. Verifies the complete system — It checks the integrated system as a whole, confirming that all modules, databases, interfaces and hardware work together as one unit, which unit and integration testing cannot guarantee.

2. Validates against requirements — It compares the actual behaviour of the system with the functional and non-functional requirements in the SRS, ensuring the software does what the user asked for.

3. Detects integration and interface errors — Errors that appear only when modules are combined (data passing, API calls, database connectivity) are found and fixed at this stage.

4. Tests non-functional aspects — Performance, load, stress, security, usability and compatibility are evaluated here, which are not covered by lower-level testing.

5. Reduces cost and risk of failure — Finding and correcting defects before deployment is far cheaper than fixing them after the system goes live; it prevents costly post-release failures and damage to the organization's reputation.

6. Ensures quality and reliability — It gives confidence that the system is reliable, meets quality standards and satisfies acceptance criteria, paving the way for user acceptance testing and final delivery.

7. Verifies end-to-end business processes — It confirms that complete workflows (e.g., order → billing → delivery) behave correctly from start to finish.

In short, system testing acts as the final quality gate of the SDLC: without it, defects would reach the user, causing loss of money, time and trust.

(b) Requirement Elicitation

Requirement elicitation is the step in the requirement collection process where the analyst directly interacts with users and stakeholders to discover and gather their needs. The other options deal with checking feasibility, documenting the requirements, or confirming them.

The major activities performed to design the software are collectively called software design, and they are carried out after the software requirements have been gathered and analysed. The goal is to translate "what the system should do" (requirements) into "how the system will do it" (a blueprint for construction). The main activities are:

1. Architectural Design The overall structure of the software is defined. The system is decomposed into major subsystems or modules, and the relationships and interactions between them are established. Decisions such as whether to use a layered architecture, client–server model, or modular structure are made here. This gives a high-level view of the whole system.

2. Interface Design The interfaces between the software and the outside world are designed. This includes:

• User interface design – how screens, menus, forms, and dialogues will look and behave for the end user.
• External/system interface design – how the software will interact with other systems, hardware, or networks.
• Internal interface design – how different modules of the software will communicate with each other.

3. Component-Level (Detailed) Design Each module or component identified in the architectural design is designed in detail. The internal logic, data structures, and algorithms of each module are specified. Tools such as flowcharts, pseudocode, structure charts, and decision tables are used to describe the processing logic precisely.

4. Data Design The data structures and database schema required by the software are designed. This includes defining tables, fields, relationships, keys, and the format in which data will be stored, retrieved, and validated. Good data design ensures data integrity and efficient access.

5. Interface and Procedure Design The step-by-step procedures or methods for carrying out each function are specified. This defines the sequence of operations, input/output formats, and the rules the software must follow while processing.

6. Design Review and Documentation The design is reviewed against the requirements to check completeness, consistency, and correctness. Design documents such as structure charts, data dictionaries, and interface specifications are prepared. These documents serve as the blueprint for the programmers during the coding phase and for testers during testing.

Conclusion In short, software design involves architectural design, interface design, component-level design, data design, procedure design, and design review/documentation. These activities produce a complete design model that bridges the gap between requirements analysis and coding, making the software easier to build, test, and maintain.

(b) Economic

Economic feasibility compares the expected costs of developing and running the system with the benefits it will bring, to decide whether the project is financially worthwhile.

Five qualities of good software are:

1. Correctness: it does exactly what the user requirements specify and gives accurate results.
2. Reliability: it works consistently without failure for a long period and handles errors gracefully.
3. Usability: it is easy to learn and use, with a clear, friendly interface.
4. Efficiency: it uses processor time, memory and other resources economically and responds quickly.
5. Maintainability: it can be easily modified to fix bugs, add features or adapt to new needs.

Other desirable qualities are portability, security and scalability.