BSc CSIT (TU) Science BIT Software Engineering (BIT302) – 5th Semester (Model) Question Paper 2079 Nepal

Requirement Engineering Process (6 marks)

Requirement engineering (RE) is the systematic process of discovering, documenting, validating and managing the services a customer requires from a system and the constraints under which it operates. It produces the Software Requirements Specification (SRS). The process has four core activities, usually performed iteratively:

1. Feasibility study – A short, focused study that decides whether the proposed system is technically, operationally and economically viable and whether it can be developed within budget and schedule. The output is a report recommending whether to proceed.
2. Requirements elicitation and analysis – Working with stakeholders (users, domain experts, managers) to discover their needs using techniques such as interviews, questionnaires, observation, scenarios, use cases and prototyping. Conflicts are identified and resolved, and requirements are classified and prioritized.
3. Requirements specification – Translating the gathered information into a precise document (the SRS). Requirements are written as user requirements (natural language) and system requirements (detailed/structured), and are recorded as functional and non-functional requirements.
4. Requirements validation – Checking that the documented requirements are correct, complete, consistent, realistic and verifiable. Techniques include reviews/inspections, prototyping and test-case generation. Approved requirements are baselined.

Requirements management runs across the whole life cycle to control changes to the agreed requirements.

Prototype Model – Advantages and Disadvantages (4 marks)

In the prototype model a working prototype is built quickly, shown to the user, and refined through feedback until the requirements are clear.

Advantages

• Users see and interact with a working model early, so requirements are clarified and misunderstandings are reduced.
• Reduces the risk of building the wrong product; missing or unclear functionality is detected early.
• Improves user involvement, satisfaction and acceptance of the final product.
• Suitable when requirements are not well understood at the start.

Disadvantages

• Users may mistake the prototype for the final product and expect it to be delivered.
• Frequent changes from feedback can lead to poor design, scope creep and incomplete documentation.
• Throw-away effort and extra cost/time if the prototype is discarded.
• Quality and architecture may be compromised because of quick-and-dirty implementation.

Architectural styles describe how a system is organized into subsystems and how they interact.

1. Layered Architecture

The system is organized into a stack of layers, each providing services to the layer above and using services of the layer below. Lower layers offer general/core services; higher layers offer application-specific services.

• Example: A typical system with Presentation layer → Application/Business logic layer → Service/Domain layer → Database/OS layer. The OSI network model and the TCP/IP stack are classic examples.
• Advantages: Supports incremental development; each layer can be changed or replaced as long as its interface is unchanged; enhances portability and security (e.g., authentication in an inner layer).
• Disadvantages: Clean separation is often hard; performance can suffer because requests pass through several layers.

2. Repository Architecture

All shared data is held in a central repository (data store) that every subsystem can access; subsystems do not interact directly but only through the shared data.

• Example: An IDE where the compiler, editor and debugger all work on a shared project repository; a management information system or CASE toolset.
• Advantages: Components are independent (they need not know about each other); data is managed consistently in one place; easy to add new tools that share the data; backup, security and version control are centralized.
• Disadvantages: The repository is a single point of failure and a potential performance bottleneck; all subsystems must agree on the repository's data model, making evolution difficult.

3. Pipe and Filter Architecture

Data flows through a sequence of processing components called filters, connected by pipes that carry the output of one filter to the input of the next. Each filter transforms its input and is independent of the others.

• Example: Unix command pipelines (e.g., cat file | grep word | sort | uniq); a batch data-processing/ETL pipeline; a compiler's phases.
• Advantages: Easy to understand and supports reuse; filters can be added, removed or reordered easily; supports concurrent/parallel execution of filters.
• Disadvantages: Often requires a common data format between filters; not well suited to interactive systems; overhead of data transformation and buffering between stages.

System models are abstract representations of a system. Two important behavioural modeling approaches are data-driven and event-driven modeling.

Data-Driven Modeling (Data-Flow Modeling)

Data-driven (data-flow) models show how data is processed and flows through a sequence of processing steps as it moves through the system. The model focuses on the transformations applied to data rather than on the events that trigger them. They are useful for showing end-to-end processing and for business systems that are mainly data-processing oriented.

• Represented using Data Flow Diagrams (DFDs) or UML activity diagrams.
• Notation: processes (transformations), data flows (arrows), data stores and external entities/sources & sinks.

Example (online shopping – placing an order):

Customer → [Validate Order] → [Check Stock] → [Process Payment] → [Generate Invoice] → Customer
                                   ↑                                      ↓
                              Stock DB                              Order DB

Here each box is a process that receives data, transforms it, and passes the result on; the focus is the flow of order data through the steps.

Event-Driven Modeling

Event-driven models show how a system responds to external and internal events and how it changes from one state to another. The system is modeled as having a finite number of states, and events cause transitions between states. This is suited to real-time and interactive systems.

• Represented using State machine / State transition diagrams (UML state diagrams).
• Notation: states (nodes), events/triggers (labelled transitions), guards and actions.

Example (microwave oven):

Idle  --(door closed & timer set)-->  Ready
Ready --(start pressed)-->  Cooking
Cooking --(timer = 0)-->  Idle
Cooking --(door opened)-->  Paused
Paused --(door closed)-->  Cooking

Each arrow is an event that moves the oven between states; the behaviour is driven by events, not by a fixed data pipeline.

Summary

The ACM/IEEE-CS Software Engineering Code of Ethics and Professional Practice sets the standard of behaviour expected of software engineers, requiring them to commit to making the analysis, specification, design, development, testing and maintenance of software a beneficial and respected profession. It is organized around eight key principles:

1. PUBLIC – Act consistently with the public interest; safety, health and welfare of the public come first.
2. CLIENT AND EMPLOYER – Act in the best interests of the client and employer, consistent with the public interest.
3. PRODUCT – Ensure that products and modifications meet the highest professional standards possible.
4. JUDGMENT – Maintain integrity and independence in professional judgment.
5. MANAGEMENT – Managers and leaders should subscribe to and promote an ethical approach to the management of software development and maintenance.
6. PROFESSION – Advance the integrity and reputation of the profession consistent with the public interest.
7. COLLEAGUES – Be fair to and supportive of colleagues.
8. SELF – Participate in lifelong learning and promote an ethical approach to the practice of the profession.

In short, the code stresses honesty, confidentiality, competence, intellectual property rights, social responsibility and protecting the public from harm.

Black box vs White box testing

Importance of White Box Testing

1. Code coverage – Ensures that statements, branches, conditions and paths in the code are exercised, revealing untested code.
2. Detects hidden/internal errors – Finds logical errors, dead code, infinite loops and incorrect control flow that black-box testing may miss.
3. Optimization – Helps remove redundant code and improve performance and structure.
4. Security – Exposes hidden vulnerabilities and security holes in the implementation.
5. Early detection – Done early during development by developers, so defects are caught and fixed cheaply before integration.

The software quality process (software quality management) is the set of activities that ensure a software product meets defined quality standards and satisfies customer requirements. It applies a quality system throughout the development life cycle and has three principal components:

1. Quality Assurance (QA) – Establishing a framework of organizational procedures and standards (a quality system) that lead to high-quality software. It is process-oriented and proactive.
2. Quality Planning – Selecting the appropriate procedures and standards from the framework and adapting them for a specific project, recorded in a Software Quality Plan (defining quality goals, processes, standards and metrics for the product).
3. Quality Control – Checking that the project team follows the defined quality processes and standards, mainly through reviews and quality assurance teams. It is product-oriented and reactive.

Typical steps in the quality process:

• Define quality attributes/goals (e.g., reliability, usability, maintainability, efficiency).
• Set standards and procedures (e.g., ISO 9000/9001, CMMI, IEEE standards).
• Perform reviews, inspections and walkthroughs of documents and code.
• Measure quality using software metrics (defect density, complexity, etc.).
• Test the software and verify against requirements.
• Continuously improve the process based on results and feedback.

Thus the quality process combines standards, planning, reviews, measurement and testing to deliver software that conforms to its specification.

Release management is the part of Software Configuration Management (SCM) concerned with planning, preparing, scheduling and distributing releases of a software system to customers. A release is a version of the system distributed to users, and it includes not just the executable code but also configuration files, data files, installation programs and documentation.

Process / key activities of release management:

1. Release planning – Decide what functionality and bug fixes go into a release and set the release schedule, balancing customer needs against development progress.
2. Deciding release timing – Choose when to release, considering technical quality, marketing factors, competitor releases, customer requests and platform changes.
3. Building the release (release creation) – Assemble the correct versions of all components, data and documentation from the configuration database/version control system into a complete, consistent package.
4. Release documentation – Prepare release notes, installation guides and user documentation describing new features, fixed bugs and known issues.
5. Release distribution / deployment – Deliver and install the release to customers via media, networks or online channels.
6. Recording and archiving the release – Record exactly which component versions make up each release in the configuration management system so that the release can be reproduced or rolled back later.

Because SCM tracks all versions and changes, release management relies on it to guarantee that every distributed release is complete, consistent and re-creatable.

A class diagram for the online movie management system identifies the main classes, their attributes/operations and the relationships (association, aggregation) among them.

Identified Classes

Relationships (textual diagram)

+-------------+        makes        +-------------+
|  Customer   |1 ---------------- *  |  Booking    |
+-------------+                     +-------------+
  | 1                                  | 1
  | gives                              | generates
  | *                                  | 1
+-------------+                     +-------------+
| Rating      |                     |  ETicket    |
+-------------+                     +-------------+
  | *                                  ^
  | for                                | issued after
  | 1                                  | 1
+-------------+    booked for   +-------------+
|   Movie     |* ------------ 1 |  Payment    |
+-------------+                 +-------------+
  | shown in                       ^ 1
  | * Hall                         | pays for (1)
+-------------+ <------ Booking ---+
|   Hall      |
+-------------+

Reading the relationships:

• A Customer makes many Bookings (1 → *).
• A Booking is for one Movie and one Hall, and records date, seatNo and hallNo.
• A Booking has one Payment (online); after a successful Payment, one ETicket is generated.
• A Customer gives many Ratings; each Rating is for one Movie (ranking after watching).

This satisfies all the requirements: registration (Customer), booking by date/hall/seat/movie (Booking), online payment (Payment), e-ticket after payment (ETicket) and ranking the movie (Rating).

Functional vs Non-functional Requirements

Examples of Functional Requirements

1. The system shall allow a user to log in using a valid username and password.
2. The system shall allow a customer to book a ticket and generate an e-ticket.

Examples of Non-functional Requirements

1. Performance: The system shall respond to any user request within 2 seconds.
2. Security/Availability: The system shall be available 99.9% of the time and shall encrypt all stored passwords.

Agile software development is an iterative and incremental approach to developing software that emphasizes flexibility, rapid delivery of working software, close customer collaboration and the ability to respond to change. Instead of producing complete documentation and design up front (as in the plan-driven/waterfall model), agile delivers the system in small increments through short iterations called sprints (typically 1-4 weeks).

The Agile Manifesto values:

1. Individuals and interactions over processes and tools.
2. Working software over comprehensive documentation.
3. Customer collaboration over contract negotiation.
4. Responding to change over following a plan.

Key characteristics:

• Incremental delivery of working software in short iterations.
• Continuous customer/stakeholder involvement and feedback.
• Welcomes changing requirements, even late in development.
• Self-organizing, cross-functional teams and face-to-face communication.
• Continuous integration, testing and refactoring to maintain quality.

Popular agile methods: Scrum, Extreme Programming (XP), Kanban, Feature-Driven Development (FDD) and Dynamic Systems Development Method (DSDM).

Advantages: fast delivery, adaptability to change, high customer satisfaction. Limitation: less suited to very large, safety-critical systems that need heavy up-front documentation.

Types of Testing

Software testing can be classified into many types, including:

• Development / functional testing: Unit testing, Component testing, Integration testing, System testing.
• Acceptance testing: Alpha testing, Beta testing, User acceptance testing.
• Other: Regression testing, Performance/load testing, Stress testing, Security testing, Usability testing, Smoke/sanity testing.
• By knowledge of code: Black-box, White-box and Grey-box testing.

Component Testing

Component (or module/unit-level component) testing tests individual software components in isolation — these may be single objects/classes or composite components made of several interacting objects. The aim is to verify that each component behaves correctly according to its specification through its defined interfaces. Testers focus on the component's interface(s): parameter passing, shared memory, procedural and message-passing interfaces. It is usually performed by developers and often uses stubs and drivers to simulate missing parts. It detects defects early, at the smallest manageable level.

Integration Testing

Integration testing tests groups of components combined together to verify that they work correctly as a subsystem and that their interfaces and interactions are correct. After individual components pass component testing, they are integrated and tested for interface mismatches, data-flow errors and timing problems. Common strategies are:

• Top-down integration – integrate from the top module downward, using stubs for lower modules.
• Bottom-up integration – integrate from the lowest modules upward, using drivers.
• Big-bang integration – combine all components at once and test.
• Incremental/sandwich integration – a combination of top-down and bottom-up.

Whereas component testing checks a component in isolation, integration testing checks that components cooperate correctly when assembled.

a. COCOMO (Constructive Cost Model)

COCOMO, proposed by Barry Boehm (1981), is an algorithmic cost-estimation model that estimates the effort, cost and schedule of a software project based on its estimated size in KLOC (thousands of lines of code).

Basic COCOMO uses:

where $E$ is effort, $D$ is development time, and $a, b, c, d$ are constants that depend on the project type. Projects are classified into three modes — Organic (small, simple), Semi-detached (medium) and Embedded (complex, tightly constrained). For example, for organic mode $a=2.4,\ b=1.05,\ c=2.5,\ d=0.38$. COCOMO has three levels of increasing detail: Basic, Intermediate and Detailed COCOMO.

b. Design Pattern

A design pattern is a general, reusable and proven solution to a commonly occurring problem in software design within a given context. Patterns are not finished code; they are templates/best practices that describe how to solve a design problem so it can be reused in many situations. The concept was popularized by the "Gang of Four" (GoF), who classified patterns into three categories:

1. Creational patterns – deal with object creation, e.g., Singleton, Factory, Builder.
2. Structural patterns – deal with composition of classes/objects, e.g., Adapter, Decorator, Facade.
3. Behavioural patterns – deal with object interaction and responsibility, e.g., Observer, Strategy, Iterator.

A pattern is typically described by four elements: name, problem, solution and consequences. Benefits include reuse of proven designs, a common design vocabulary and more maintainable, flexible software.