b

Software Requirement Engineering

(Assignment No.2)
Question No.1

System analysts have to face different type of challenges during requirements elicitation.
Explain these problems and challenges in details.

1. Ambiguous Requirements:

Ambiguity in requirements can cause confusion among developers and testers, leading to incorrect
implementations or test cases.

2. Changing Requirements:

 Requirements can change due to business needs, market trends, or technological

advancements.

 Managing changing requirements, known as "scope creep," is a significant challenge. It

requires communication and negotiation with stakeholders.

3. Incomplete Requirements:

One of the most common problems is incomplete or missing requirements. Stakeholders may
not fully understand or communicate all their needs, which can lead to gaps in the
requirements documentation.

4. Communication Issues:

Communication issues, like language differences and varied knowledge levels among stakeholders,
can lead to misunderstandings in requirements

5. Unclear Objectives:

 Stakeholders might have unclear or undefined objectives for the project.

 System analysts need to work closely with stakeholders to define clear, specific, and
achievable project objectives to guide the requirements .

Question No.2

Explain about the following Software Elicitation Techniques.

 Interviews
 Questionnaire
 Workshops
 Prototyping

Interviews:

Interviews involve direct conversations between the software developers and stakeholders. It's a way
to gather detailed information about requirements. Interviewers can ask specific questions and clarify
doubts in real-time, making it a valuable method for understanding complex requirements directly
from the source.

Questionnaires:
 Questionnaires are a set of predefined questions given to stakeholders. They are asked to fill out the
questions, providing written responses. This method is efficient for gathering a large amount of
information from a broad audience. However, it might lack depth, as there's no immediate opportunity
to clarify ambiguous responses.

Workshops:

Workshops are interactive group sessions where stakeholders, users, and developers collaborate.
Workshops encourage active participation and discussion among participants. They are useful for
exploring ideas, resolving conflicts, and building consensus among diverse stakeholders. Workshops
often lead to a better understanding of requirements through brainstorming and group activities.

Prototyping:

Prototyping involves creating a simplified version of the software to demonstrate ideas and gather
feedback. Prototypes allow stakeholders to visualize the end product early in the development
process. By interacting with the prototype, stakeholders can provide feedback on its functionality and
design. This iterative approach helps in refining requirements as the development progresses

Question No.3

What are major sources of requirements? Explain some of the sources with examples.

1.Stakeholders:

 Example: End users, customers, sponsors, regulatory bodies. These stakeholders directly
interact with the system.

2. Documentation:

 Example: Existing manuals, reports, business process documents. These documents might
contain valuable information about current processes, rules, and functionalities.

3. Interviews:

 Example: One-on-one discussions with users, managers, or subject matter experts.

4. Surveys and Questionnaires:

 Example: Surveys can help gather opinions and preferences from a large number of people.

5. Workshops and Focus Groups:

 Example: Facilitated group discussions with stakeholders. Workshops can encourage

brainstorming and collaborative requirement gathering among participants.

6. Prototyping:

 Example: Building early versions of the software. Prototyping helps users visualize the
system, enabling them to provide more concrete and detailed feedback about what they want.

7. Change Requests:

 Example: Users might identify additional requirements or changes needed after using the
software, which can be collected through formal change request processes.
8. Regulations and Standards:

 Example Regulations and standards are mandatory rules from the government or industry
groups that software developers must follow. These rules influence how software is designed
and what features it includes, ensuring compliance and quality.

Question No.4

What is meant by project and Product? Also define project scope and product scope.

Project: A project is a temporary try undertaken to create a unique product, service, or result. It has
defined objectives, specific start and end dates, and allocated resources.

Product: A product is the outcome of a project. It can be a physical object, a service, software, or any
other deliverable created to fulfill a need.

Project Scope: Project scope outlines the specific goals, deliverables, tasks, costs, and deadlines of a
project. It defines the boundaries of what is included and what is not.

Product Scope: Product scope defines the features, functions, and characteristics of the end product.
It details what the product will do, how it will behave, and the quality standards it must meet

Question No.5

Explain in details about four Software Elicitation Techniques with pros and cons.

1. Interviews:

Interviews involve direct, one-on-one interactions between the analyst and stakeholders
Advantages:
 Depth of Information: Allows for in-depth exploration of requirements.
 Personal Connection: Builds a personal connection, encouraging stakeholders to
express their needs openly.
 Challenges:
 Time-Consuming: Can be time-consuming, especially for large projects with
stakeholders.
Biased Responses: Responses might be control by the interviewer's company
leading to biased answers
2. Questionnaires:
Questionnaires are a written set of questions given to stakeholders to gather their responses.
This method is useful for collecting data from a large number of participants.
 Advantages:
 Anonymity: Allows stakeholders to provide feedback anonymously, encouraging
honest responses.
 Structured Responses: Responses can be standardized, making them easier to
analyze quantitatively.
 Challenges:
  Limited Depth: Questionnaires offer limited space for detailed responses, potentially
missing nuances

 Low Response Rate: Stakeholders might not respond on time, leading to a low
response rate and incomplete data.

3. Work shops:

Workshops involve facilitated group discussions with stakeholders, typically led by a

facilitator or system analyst.
Advantages:
 Immediate Clarifications: Allows immediate clarification of doubts and
misunderstandings, leading to accurate requirements.
 Shared Understanding: shared understanding of the project goals among
stakeholders.
 Challenges:
 Dominant Participants: Certain participants might dominate discussions, hindering
input from others.
 Time-Consuming: Requires careful planning and can be time-consuming, especially
if not well-organized.
4. Prototyping:
Prototyping creating an early, simplified version of the software to visualize and demonstrate
the requirements.
 Advantages:
 Visual Representation: Provides a visual representation of the software, helping
stakeholders better understand requirements.
 User Feedback: Allows users to interact with the prototype, providing valuable
feedback for refining requirements iteratively.

 Challenges:
 Time and Resources: Developing prototypes requires time and resources, especially
for complex software systems.
 Limited Functionality: Initial prototypes might not capture all functionalities,
leading to limited feedback in the early stages.

Question No.6

What is meant by OFF-THE-SHELF solution for the project? Explain it.

Characteristics of Off-The-Shelf Solutions:

1. Pre-Packaged: Off-the-shelf solutions come as pre-packaged software products that are

ready to be installed and used immediately after purchase.

2. Generic Functionality: Ready-made software has basic features that work for many people
in a specific area. It's like one size fits many.

3. Limited Customization: Off-the-shelf software can't always be changed a lot to fit specific
needs. It has some options, but there are limits.
 4. Cost-Effective: Off-the-shelf solutions are often cost-effective because the development costs
are distributed among a large number of buyers.

5. Quick Deployment: Ready-made software is fast to start using because it's already made.
After buying it, organizations can quickly put it into action.

6. Vendor Support: Vendors provide support and updates, ensuring that the software remains
compatible with evolving technologies and security standards.

Advantages of Off-The-Shelf Solutions:

1. Off-the-shelf solutions save time and money

2. their reliability and effectiveness in addressing common problems.

3. Cost effective

Disadvantages of Off-The-Shelf Solutions:

1. Limited Customization

2. Feature Overload

Question No.7

Mr. Ali was owner of a company GABCo (Pvt.)Ltd.. He assigned project a project to ALPHA-
SOFT by giving his requirements. ALPHA-SOFT designed software for GABCo (Pvt.)Ltd.
They tested all the requirements by their Software Quality Engineers. Now Mr. Ali assigned
Mr. Afzal from his company to check whether his given requirements are fulfilled according to
the provided requirements or not?

a) Write down stakeholders from the given scenario. Also categorize them into different
categories of stakeholders.
b) In the above-given scenario, describe which process is verification and validation. Also
describe verification and validation process in details.
c) Identify non-functional and domain requirements and categorize them. ?

ANSWER

a) Stakeholders and Categories:

Stakeholders:

1. Mr. Ali: Owner of GABCo (Pvt.) Ltd.

2. GABCo (Pvt.) Ltd.: The company for which the software is being developed.

3. ALPHA-SOFT: The software development company responsible for designing the software.

4. Mr. Afzal: Assigned by Mr. Ali to verify if the given requirements are fulfilled.

Categories of Stakeholders:
 1. Primary Stakeholders:

 Mr. Ali (Owner of GABCo)

 GABCo (Pvt.) Ltd.

2. Secondary Stakeholders:

 ALPHA-SOFT (Software development company)

 Mr. Afzal (Internal representative from GABCo)

b) Verification and Validation Process:

In the given scenario:

Verification is the process of rate a system against specified requirements during development.
ALPHA-SOFT verified the software using Software Quality Engineers.

Validation, on the other hand, confirms whether the system meets specified requirements. In this
case, Mr. Afzal checks if provided requirements are fulfilled, ensuring the right software is built.

c) Non-functional and Domain Requirements:

Non-Functional Requirements:

1. Performance: Specifies how the system performs under specific conditions.

2. Security: Describes the system's ability to protect data and functionality.

3. Usability: Focuses on user experience and interface design.

4. Reliability: Refers to the system's ability to perform consistently over time.

Domain Requirements:

Domain requirements are rules or guidelines for a specific area. They tell people what they can and
cannot do in that particular place or field. Just like house rules.

1. Throwaway Prototyping:

 Create a quick prototype to understand the requirements.

 Discard the prototype and build the actual system from scratch.

2. Evolutionary Prototyping:

 Build an initial prototype.

 Keep refining and enhancing the prototype until it evolves into the final system.

3. Incremental Prototyping:
  Divide the system into smaller parts.

 Build and refine prototypes for each part separately.

 Integrate these parts to form the complete system.

4. Extreme Prototyping:

 Use rapid, continuous feedback.

 Collaborate closely with stakeholders.

 Develop the system incrementally and adapt to changes quickly.