BSc CSIT (TU) Science Software Engineering (BSc CSIT, CSC364) Question Paper 2075 Nepal

Requirements Engineering

Requirements engineering (RE) is the process of discovering, analysing, documenting, validating and managing the services that a customer requires from a system and the constraints under which it operates. It produces an agreed Software Requirements Specification (SRS) that forms the basis for design and contractual agreement.

Requirements Elicitation and Analysis Process

This is an iterative activity whose goal is to understand the application domain, the services the system should provide and the constraints on its operation. It involves stakeholders such as end-users, managers, domain experts and engineers. The process is best shown as a spiral repeated until the requirements document is complete.

Diagram (described): A circular/spiral cycle with four connected activities; the cycle is repeated, with the output of Requirements specification feeding back into the next iteration of Requirements discovery.

   +-------------------------+
   | 1. Requirements         |
   |    discovery / elicit.  |
   +-----------+-------------+
               |
               v
   +-------------------------+
   | 2. Requirements         |
   |    classification &     |
   |    organisation         |
   +-----------+-------------+
               |
               v
   +-------------------------+
   | 3. Requirements         |
   |    prioritisation &     |
   |    negotiation          |
   +-----------+-------------+
               |
               v
   +-------------------------+
   | 4. Requirements         |
   |    specification (doc)  |
   +-----------+-------------+
               |
               +----> loop back to step 1

1. Requirements discovery (elicitation)

Interacting with stakeholders to gather their requirements and discover domain information. Techniques include interviews (open and closed), scenarios/use cases, ethnography (observing how people work), and prototyping.

2. Requirements classification and organisation

Grouping the unstructured collection of requirements into coherent clusters and relating them to subsystems of an architecture.

3. Requirements prioritisation and negotiation

Resolving conflicts between stakeholder requirements through discussion, and ranking requirements by importance (e.g. must-have vs. desirable).

4. Requirements specification

Documenting the agreed requirements (formally or informally) and adding them to the requirements document; this feeds the next iteration of the spiral.

Problems: stakeholders may not know what they want, express requirements in their own terms, give conflicting requirements, and requirements change during analysis.

Software Testing

Software testing is the process of executing a program with the intent of finding errors (defects) and demonstrating that the software meets its requirements. It is a verification and validation (V&V) activity that aims to show the software does what it is supposed to do and to discover situations where its behaviour is incorrect. Testing can show the presence of defects but never their absence.

Levels of Testing

• Unit testing: tests the smallest testable parts (functions, objects) using drivers and stubs.
• Integration testing: combines units and tests them as a group; can be top-down, bottom-up or big-bang.
• System testing: tests the system as a whole including performance, security and usability.
• Acceptance testing: performed by/for the customer to validate the system in the real environment.

Regression testing (re-running tests after changes) is applied across these levels.

Test-Driven Development (TDD)

TDD is an agile development practice in which tests are written before the code, interleaving testing and code development. The cycle is short and repeated:

1. Write a test for the next small piece of required functionality (it fails first — red).
2. Write just enough code to make the test pass (green).
3. Run all tests to confirm nothing is broken.
4. Refactor the code to improve structure while keeping tests passing.
5. Repeat for the next increment.

Benefits: code coverage is high (every code segment has a test), regression testing is automated, debugging is simplified (a failing test localises the new fault), and the tests serve as living documentation of the system.

Agile Development Methodology

Agile development is a group of incremental and iterative software development methods (e.g. Scrum, XP, Kanban) that focus on rapid delivery of working software, embrace changing requirements, and rely on close collaboration with the customer. They were created as a reaction to the heavyweight, document-driven plan-driven methods.

The Agile Manifesto values:

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

Key principles/practices: short iterations (sprints) producing working increments, continuous customer involvement, frequent delivery, embracing change, simplicity, self-organising teams, and regular reflection/improvement.

Plan-Driven vs. Agile Approaches

In a plan-driven approach all process activities are planned in advance and progress is measured against the plan. In an agile approach planning is incremental and it is easier to change the process to reflect changing customer requirements. Most real projects mix the two.

Conclusion: Plan-driven methods give predictability and are appropriate for critical systems with stable requirements; agile methods give flexibility and fast feedback, suiting projects where requirements evolve rapidly.

Black-box (functional) testing treats the program as a closed box: test cases are derived only from the specification without knowledge of the internal code. The tester provides inputs and checks outputs against expected results. Techniques include equivalence partitioning, boundary value analysis and use-case based testing. It checks what the software does.

White-box (structural / glass-box) testing uses knowledge of the internal structure and code to design tests. The goal is to exercise paths, branches and statements in the code. Techniques include statement coverage, branch/decision coverage and path testing. It checks how the software works internally.

Reuse-based software engineering is a software development strategy in which systems are built largely by reusing existing software assets rather than developing everything from scratch. Reusable assets include functions, objects, components, COTS (commercial off-the-shelf) products, software product lines, web services and design patterns. The standard process is requirements → component analysis → requirements modification → system design with reuse → development and integration.

Benefits:

• Increased reliability – reused components are already tested and used in working systems.
• Reduced process risk – the cost of existing components is known, reducing uncertainty.
• Effective use of specialists – expert knowledge is captured once in reusable components.
• Standards compliance – reusing components that embody standards (e.g. UI patterns) gives consistency.
• Accelerated development / lower cost – less code to write and test means faster time-to-market and reduced development and maintenance cost.

Design Patterns

A design pattern is a general, reusable solution to a commonly occurring problem in software design within a given context. It is not finished code but a description or template showing how to solve a problem that can be reused in many situations. Patterns capture proven design experience and improve communication among developers using a common vocabulary. The classic catalogue (Gang of Four) groups them into creational, structural and behavioural patterns. A pattern is usually described by four elements: name, problem, solution, and consequences.

Example: Observer Pattern (behavioural)

Problem: When the state of one object (the subject) changes, a number of dependent objects (observers) must be updated automatically, without the subject being tightly coupled to them.

Solution: The subject keeps a list of observers and notifies them by calling an update method whenever its state changes.

interface Observer { void update(int state); }

class Subject {
  private List<Observer> observers = new ArrayList<>();
  private int state;
  void attach(Observer o) { observers.add(o); }
  void setState(int s) {
    state = s;
    for (Observer o : observers) o.update(state); // notify all
  }
}

Use: Implementing the Model-View-Controller architecture, where multiple views update automatically when the model changes.

Software Quality Assurance (SQA)

Software Quality Assurance is the planned and systematic set of activities that ensures software processes and products conform to requirements, standards and procedures. It is process-oriented: rather than only testing the final product, SQA monitors and improves the whole development process so that quality is built in. Activities include defining standards, performing reviews/audits and inspections, configuration management, process monitoring and reporting.

Importance:

• Detects defects early, when they are cheaper to fix, reducing rework and cost.
• Ensures the product meets requirements and agreed quality standards (ISO 9001, CMMI).
• Improves reliability, maintainability and customer satisfaction by delivering consistent quality.
• Provides confidence and accountability through documented processes, reviews and metrics.
• Reduces overall project risk and long-term maintenance cost.

Verification answers the question "Are we building the product right?" — it checks whether the software conforms to its specification at each stage. It is typically done without executing the code through reviews, inspections, walkthroughs and static analysis of documents and code.

Validation answers the question "Are we building the right product?" — it checks whether the software meets the customer's actual needs and expectations. It is usually dynamic, performed by executing the software through testing (system testing, acceptance testing).

Waterfall Model

The waterfall model is a classic plan-driven, sequential software process in which the development is divided into distinct phases that flow downward like a waterfall. Each phase must be completed and its output approved before the next begins, with documentation produced at every stage.

Phases:

1. Requirements analysis and definition
2. System and software design
3. Implementation and unit testing
4. Integration and system testing
5. Operation and maintenance

In principle one phase feeds the next; in practice limited feedback (overlap) between adjacent phases is allowed.

Limitations

• Inflexible to change – requirements are frozen early, so accommodating changing customer needs is difficult and expensive once a later phase has started.
• Late working software – a working product is available only late in the life cycle, so errors are discovered late and are costly to fix.
• Hard to anticipate all requirements up front, which rarely matches real projects.
• No overlap/iteration – the rigid sequential structure causes delays if one phase is blocked.
• High risk for large/long projects, but suitable mainly for projects with stable, well-understood requirements (e.g. safety-critical or embedded systems).

Software Re-engineering

Software re-engineering is the process of examining and modifying an existing (legacy) software system to reconstitute it in a new form, improving its structure, quality and maintainability without changing its functionality. It is applied when a system is still business-critical but has become difficult and costly to maintain, instead of replacing it entirely.

Typical activities in the re-engineering process:

1. Source code translation – convert code to a newer language/version.
2. Reverse engineering – analyse the program to recover its design and documentation.
3. Program structure improvement – restructure control flow for readability.
4. Program modularisation – reorganise related parts into coherent modules.
5. Data re-engineering – clean up and restructure the system's data.

Advantages: reduced risk and lower cost compared with redeveloping from scratch, while improving maintainability, structure and quality of the legacy system.

Requirements for a Library Management System

Functional requirements describe the services/functions the system must provide — what the system does:

• The system shall allow a librarian to add, update and remove book records.
• The system shall let members search the catalogue by title, author or ISBN.
• The system shall allow a member to issue (borrow) and return books and shall update availability.
• The system shall register new members and manage member accounts.
• The system shall calculate fines for books returned after the due date.
• The system shall generate reports (e.g. issued books, overdue list, stock).

Non-functional requirements describe quality attributes and constraints on how the system performs its functions:

• Performance: a catalogue search shall return results within 2 seconds.
• Security: only authenticated librarians shall modify records; passwords shall be encrypted.
• Usability: the interface shall be simple enough for a new member to issue a book without training.
• Reliability/Availability: the system shall be available 99% of working hours.
• Scalability: the system shall support at least 10,000 book records and 500 concurrent users.
• Portability: the system shall run on standard web browsers.

Role of CASE Tools

CASE (Computer-Aided Software Engineering) tools are software tools that support and automate software engineering activities across the development life cycle, improving productivity and quality and reducing manual effort and errors.

Classification:

• Upper-CASE tools support early phases — requirements analysis and design (e.g. diagramming, data dictionaries).
• Lower-CASE tools support later phases — implementation, testing and maintenance (e.g. code generators, debuggers, test tools).
• Integrated (I-CASE) tools provide support across the whole life cycle through a shared repository.

Roles / contributions:

• Analysis & design: drawing DFDs, ER diagrams, UML models and maintaining a data dictionary.
• Code generation: automatically generating code skeletons from design models.
• Documentation: producing and keeping documentation consistent with the design.
• Project management: estimation, scheduling and configuration/version management.
• Testing and maintenance: automated test generation, debugging and reverse engineering.

Benefits: higher productivity, fewer errors, consistency between design and code, easier maintenance and better project control.