Indian Ins(tute of Technology (Indian School of Mines) Dhanbad
Mid-Semester Examina0on Solu0ons
So#ware Engineering (CSC306)
Winter 2023-24
Note:
1. The solutions in this document provide “one possible approach” towards solving the problems.
2. There may be other possible solutions in some cases. Due to time pressure, it may be possible the
you did not receive marks for an alternate solution. In such cases, please request for a re-evaluation
of that Question.
A1. The major problem that you have flagged is the elements covered in the defini0on of a SoFware. As per
your understanding, you have observed that a SoFware consists of three different elements: (i)
Code/Program, (ii) Data Structures that handle data manipula0on, and (iii) Documenta*on. The third
element, i.e., Documenta0on, is missed in the defini0on.
The modified defini0on may look like:
A soFware can be described as a collec0on of some programs which manipulate informa0on using a set
of appropriate data structures accompanied by relevant documenta*on to describe the same.
A2. You have deduced that the typical development cycle of the firm must be somewhere around 3 weeks.
You deduced this by seeing the peeks in the number of issues every 3 weeks, which is indica0ve of a
major change in the product, similar to a new release. These peeks are reminiscent of the observed
SoFware Failure curve as shown below:
Increased failure
rate due to side
effect
Failure Rate
Change
Actual curve
Idealised curve
Time
A3. Team B seems to be more likely to succeed in this case, as compared to Team A.
It is because if we analyse the problem at hand, it is a 6 Months long project, where the teams need to
experiment with different possible solu0ons. The fact that experimenta0on is involved, hints that the
requirements are not clear to begin the project. For such scenarios, an itera0ve development process is
a preferred choice over the Waterfall model. Since Scrum is an itera0ve process model, Team B is more
likely to succeed in the project, as compared to Team A, which has chosen the Waterfall model (which is
not itera0ve in nature).
Page 1 of 6
Indian Ins(tute of Technology (Indian School of Mines) Dhanbad
Mid-Semester Examina0on Solu0ons
So#ware Engineering (CSC306)
Winter 2023-24
A4. Two Possible Epics for this problem are as follows:
Some possible Stories for both Epics are as shown:
Page 2 of 6
Indian Ins(tute of Technology (Indian School of Mines) Dhanbad
Mid-Semester Examina0on Solu0ons
So#ware Engineering (CSC306)
Winter 2023-24
Page 3 of 6
Indian Ins(tute of Technology (Indian School of Mines) Dhanbad
Mid-Semester Examina0on Solu0ons
So#ware Engineering (CSC306)
Winter 2023-24
Note: The Numbering of the Epics and User Stories (like A, B, A1, B1, etc.) is not required. I have done
that to make it easier to link the User Stories with the Epics.
A5. Let us assume that the “Func0onal Requirements” chapter is the Chapter 2 of the SRS and the “Quality
Requirement” chapter is the Chapter 3 of the document. The content for the two chapters is shown
below:
Page 4 of 6
Indian Ins(tute of Technology (Indian School of Mines) Dhanbad
Mid-Semester Examina0on Solu0ons
So#ware Engineering (CSC306)
Winter 2023-24
Chapter 2: Func(onal Requirements
Sec4on 2.1: User Authen4ca4on and Authoriza4on
Requirement 2.1.1: Users should be able to create accounts, log in, and log out securely.
Requirement 2.1.2: The system must verify user creden@als and grant appropriate access levels based on user
roles (e.g., admin, par@cipant).
Requirement 2.1.3: Passwords must be securely stored and encrypted to protect user accounts from
unauthorized access.
Requirement 2.1.4: Users should have the op@on to reset their passwords securely in case of forgeGng them.
Sec4on 2.2: Problem Statement Submission
Requirement 2.2.1: Registered users should be able to submit problem statements for coding challenges or
contests.
Requirement 2.2.2: Problem submissions should include a @tle, descrip@on, input/output specifica@ons, and
any addi@onal constraints.
Requirement 2.2.3: SubmiLed problem statements must undergo valida@on to ensure they meet the required
format and criteria.
Requirement 2.2.4: Authors should have the ability to edit or remove their submiLed problem statements
before they are published.
Sec4on 2.3: Language Support
Requirement 2.3.1: Code Veers must support mul@ple programming languages for coding challenges, including
but not limited to C++, Java, Python, and JavaScript.
Requirement 2.3.2: Users should have the flexibility to choose their preferred programming language for
solving problems.
Requirement 2.3.3: The system must provide a compiler or interpreter for each supported language to compile
and execute user-submiLed code.
Sec4on 2.4: Contest Management
Requirement 2.4.1: Administrators should be able to create, schedule, and manage coding contests on the
plaUorm.
Requirement 2.4.2: Contests should have configurable parameters such as start/end @mes, dura@on, problem
sets, and scoring criteria.
Requirement 2.4.3: Par@cipants must be able to register for contests, view contest details, and submit
solu@ons during the contest dura@on.
Requirement 2.4.4: Real-@me leaderboards should display rankings and scores based on par@cipants'
submissions and performance.
Sec4on 2.5: User Profile Management
Requirement 2.5.1: Users should have profile pages where they can view and update their personal
informa@on, including usernames, email addresses, and profile pictures.
Requirement 2.5.2: Profile pages should display users' ac@vity history, including past submissions, contest
par@cipa@on, and achievements.
Requirement 2.5.3: Users must have the op@on to customize their profile seGngs, such as privacy preferences
and no@fica@on preferences.
Requirement 2.5.4: The system should support social features, allowing users to follow other users, view their
profiles, and send messages or friend requests.
Page 5 of 6
Indian Ins(tute of Technology (Indian School of Mines) Dhanbad
Mid-Semester Examina0on Solu0ons
So#ware Engineering (CSC306)
Winter 2023-24
Chapter 3: Quality Requirements
Sec4on 3.1: Performance
Requirement 3.1.1: Code Veers must be able to handle concurrent user sessions and heavy traffic during peak
usage periods without experiencing significant slowdowns or down@me.
Requirement 3.1.2: Response @mes for user interac@ons, such as submiGng code solu@ons or loading contest
pages, should be minimized to provide a seamless user experience.
Requirement 3.1.3: The plaUorm should be op@mized for efficient resource u@liza@on to ensure smooth
performance even on low-bandwidth or limited hardware devices.
Sec4on 3.2: Reliability
Requirement 3.2.1: The system should be highly reliable and available, with an up@me of at least 99.9% to
minimize service disrup@ons and down@me.
Requirement 3.2.2: Automated backup mechanisms should be in place to regularly back up user data and
system configura@ons to prevent data loss in case of system failures or disasters.
Requirement 3.2.3: Error handling and logging mechanisms should be implemented to iden@fy and address
system issues promptly, ensuring uninterrupted service for users.
Sec4on 3.3: Security
Requirement 3.3.1: Code Veers must adhere to industry-standard security prac@ces to protect user data,
including encryp@on of sensi@ve informa@on, secure transmission protocols (e.g., HTTPS), and secure
authen@ca@on mechanisms.
Requirement 3.3.2: The system should implement role-based access control (RBAC) to restrict access to
sensi@ve func@onali@es and data based on user roles and permissions.
Requirement 3.3.3: Regular security audits and vulnerability assessments should be conducted to iden@fy and
mi@gate poten@al security threats and vulnerabili@es proac@vely.
Sec4on 3.4: Usability
Requirement 3.4.1: The plaUorm should have an intui@ve and user-friendly interface that is easy to navigate
and understand, catering to users of all skill levels.
Requirement 3.4.2: Clear instruc@ons and guidance should be provided to users for performing various ac@ons,
such as submiGng code solu@ons, joining contests, or interac@ng with other users.
Requirement 3.4.3: The system should support accessibility features to accommodate users with disabili@es,
ensuring equal access to all plaUorm func@onali@es.
Sec4on 3.5: Scalability
Requirement 3.5.1: Code Veers should be designed to scale horizontally and ver@cally to accommodate
increasing user loads and growing data volumes over @me.
Requirement 3.5.2: The architecture should be modular and flexible, allowing for easy expansion of resources
and infrastructure to meet evolving demands.
Requirement 3.5.3: Load balancing mechanisms should be implemented to distribute traffic evenly across
mul@ple servers or instances, op@mizing performance and resource u@liza@on.
Note: It is fine if you have not assumed any Chapter Numbers, but the requirements shall be in some
structured form.
Page 6 of 6