Unit - II

Software
Requirement
Engineering
(14 Marks)

By, Diptesh Dilip Dange

 2.1 Software Engineering Core Principles
Q. List and explain any four principles of “Core Principles” of Software Engineering

1) The First Principle: The Reason It All Exists

• A software system exists for one reason: to provide value to its users.

• All decisions should be made with this in mind.

• Before specifying a system requirement, system functionality, before determining the

hardware platforms, first determine, whether it adds value to the system.
2) The Second Principle: KISS (Keep It Simple, Stupid!)

• All design should be as simple as possible, but no simpler. This facilitates having a more
easily understood and easily maintained system.

• It doesn’t mean that features should be discarded in the name of simplicity.

• Simple also does not mean “quick and dirty.” In fact, it often takes a lot of thought and work
over multiple iterations to simplify.
3) The Third Principle: Maintain the Vision

• A clear vision is essential to the success of a software project.

• If you make compromise in the architectural vision of a software system, it will weaken and will
eventually break even the well - designed systems.

• Having a powerful architect who can hold the vision helps to ensure a very successful software project.
4) The Fourth Principle: What You Produce, Others Will Consume

• Always specify, design, and implement by keeping in mind that someone else will have to understand
what you are doing.

• The audience for any product of software development is potentially large.

• Design (make design), keeping the implementers (programmers) in mind. Code (program) with
concern for those who will maintain and extend the system.

• Someone may have to debug the code you write, and that makes them a user of your code.
5) The Fifth Principle: Be Open to the Future

• A system with a long lifetime has more value.

• True “industrial-strength” software systems must last for longer. To do this successfully, these systems
must be ready to adapt changes.

• Always ask “what if,” and prepare for all possible answers by creating systems that solve the general
problem.
6) The Sixth Principle: Plan Ahead for Reuse

• Reuse saves time and effort.

• The reuse of code and designs has a major benefit of using object-oriented technologies.

• Planning ahead for reuse reduces the cost and increases the value of both the reusable components
and the systems into which they are incorporated.
7) The Seventh principle: Think!

• Placing clear, complete thought before action almost always produces better results.

• When you think about something, you are more likely to do it right. You also gain
knowledge about how to do it right again.

• If you do think about something and still do it wrong, it becomes a valuable experience.

• Applying the first six principles requires intense thought, for which the potential rewards
are enormous.
 2.2 Software Practices: Communication, Planning, Modelling, Construction,
Software deployment
(Statement and meaning of each principles for each practice).

Q. Explain Software Practices with its principles.

Software Practices:

• These practices guide software development from start to finish.

• Each practice has its purpose, and each follows principles to ensure success.
Types of Practices:

1. Communication Practice

Statement: Clear and continuous communication with stakeholders, users, and team members is essential throughout
the software lifecycle.

2. Planning Practice

Statement: Planning provides a roadmap for software development and helps track progress, resources, and risks.

3. Modelling Practice

Statement: Modelling helps visualize the structure, behavior, and requirements of the software before building it.

4. Construction Practice

Statement: Construction is the process of coding and testing to turn models and plans into a working system.

5. Deployment Practice

Statement: Deployment delivers the final software to users, ensuring it is installed, configured, and ready to use.
1. Listen to the speaker and concentrate on what is being said
2. Prepare before you meet by researching and understanding the problem.
3. Someone should facilitate the meeting and have an agenda.
4. Face-to-face communication is best, but also have a document or presentation to focus the discussion
5. Take notes and document decisions
6. Strive for collaboration and consensus. (Consensus is a collaborative process by which people make decisions
based on a group's overwhelming agreement)
7. Stay focused on a topic; modularize your discussion
8. If something is unclear, draw a picture
9. Move on to the next topic a) after you agree to something,
b) if you cannot agree to something,
c) if a feature or function is unclear and cannot be clarified at the moment
10. Negotiation is not a contest or a game; it works best when both parties win
1. Understand the scope of the project
2. Involve the customer/stakeholders in the planning activity
3. Recognize that planning is iterative; things will change
4. Estimate based only on what you know
5. Consider risk as you define the plan
6. Be realistic on how much can be done each day by each person and how well
7. Adjust granularity as you define the plan (Granularity refers to the level of detail that is introduced as a
project plan is developed.)
8. Define how you intend to ensure quality
9. Describe how you intend to accommodate change
10. Track the plan frequently and make adjustments as required
 -- Requirements models (also called analysis models)

1. The information domain of a problem must be represented and understood.

2. The functions that the software performs must be defined.

3. The behavior of the software (as a consequence of external events) must be represented.

4. The models that depict information, function, and behavior must be partitioned in a manner
that uncovers detail in a layered (or hierarchical) fashion.

5. The analysis task should move from essential information toward implementation detail.
 -- Design Modeling Principles

1. Design should be traceable to the requirements model.

2. Always consider the architecture of the system to be built.

3. Design of data is as important as design of processing functions

4. Interfaces (both internal and external) must be designed with care.

5. User interface design should be tuned to the needs of the end user. However, in every case, it should stress
ease of use.

6. Component-level design should be functionally dependent.

7. Components should be loosely coupled to one another and to the external environment.

8. Design representations (models) should be easily understandable.

9. The design should be developed iteratively. With each iteration, the designer should strive for greater
simplicity
 Agile process model: (Modeling Practices)

1. The primary goal of the software team is to build software, not create models
2. Travel light—don’t create more models than you need
3. Strive to produce the simplest model that will describe the problem or the software.
4. Build models in a way that makes them amenable to change
5. Be able to state an explicit purpose for each model that is created.
6. Adapt the models you develop to the system at hand.
7. Try to build useful models, but forget about building perfect models.
8. Don’t become dogmatic about the syntax of the model. If it communicates content successfully,
representation is secondary.
9. If your instincts tell you a model isn’t right even though it seems okay on paper, you probably have
reason to be concerned.
10. Get feedback as soon as you can.
2.3 Requirement Engineering:

• Requirement Gathering and Analysis,

• Types:
• - Functional,
• - Product,
• - organizational,
• - External Requirements,
• Eliciting Requirements,
• Developing Use-cases,
• Building requirement models,
• Negotiation,
• Validation.
- Requirement Engineering

• The process to gather the software requirements from client, analyze and document them is known as
requirement engineering.

• The goal of requirement engineering is to develop and maintain sophisticated and descriptive System
Requirements Specification document.

• Requirement Engineering is the process of defining, documenting, and maintaining the requirements in the
engineering design process.

• It includes all activities related to discovering, analyzing, validating, and documenting system requirements.
Requirements gathering and analysis:

● The complete set of requirements are almost never available in the form of a single document from the
customer.

● Complete requirements are rarely obtainable from any single customer representative.

● We can conceptually divide the requirements gathering and analysis activity into two separate tasks:
Requirements gathering and Requirements Analysis
What is Requirement Gathering?

• Requirement gathering is the first step in the Software Development Life Cycle (SDLC).

• It refers to the process of collecting information about what users expect from the system or software.

• This stage focuses on understanding:

- What the user wants
- Why they need it
- How they expect the system to work

• Stakeholders involved in this stage:

- Clients
- End-users
- System analysts
- Project managers
- Developers/testers (in some cases)
Techniques Used in Requirement Gathering:

1. Interviews

• Face-to-face or virtual meetings between stakeholders and analysts.

• Helps uncover both explicit (clearly stated) and implicit (unstated) requirements.

• Types: - Structured (with pre-planned questions),

- Unstructured (open discussion) and
- Semi-structured.

Example: Asking the client, "How do you currently handle user logins?"
2. Questionnaires/Surveys

• A set of predefined questions given to a large group of users.

• Useful when feedback is needed from many people.
• Can be closed-ended (MCQs) or open-ended.

Example: Asking users to rate the importance of certain features.

3. Brainstorming

• A group discussion method involving stakeholders and team members.

• Encourages creative ideas and rapid requirement discovery.
• Useful in the early phase to explore all possibilities.

Example: Brainstorming session on features needed in an e-learning platform.

4. Document Analysis
• Reviewing existing documentation like manuals, reports, or business process diagrams.
• Helps understand current systems, business rules, and workflows.

Example: Reading the current user manual to understand limitations.

5. Observation

• Analyst observes end-users as they perform their daily tasks.

• Reveals actual user behavior, not just what they claim.

Example: Watching how a cashier operates the current POS system.

6. Prototyping

• Creating a quick working model of the system to understand client needs better.
• Helps refine vague or incomplete requirements.

Example: Building a simple UI mockup to confirm how a shopping cart should work.

7. Studying existing documentation:

• The analyst usually studies all the available documents regarding the system to be developed
before visiting the customer site.
• Customers usually provide a statement of purpose (SoP) document to the developers.
What is Requirement Analysis?

• Requirement analysis is the process of refining, clarifying, and validating the gathered requirements.
• It ensures that the software will meet user expectations and business goals.

- Goals of Requirement Analysis

- Remove ambiguity and conflicts

- Ensure completeness and consistency
- Understand feasibility
- Prepare a Software Requirements Specification (SRS) document
Example Scenario

Let’s say you're building a mobile banking app:

• Gathering: Interview users and discover they want quick login, transaction history, and bill payment.

• Analysis: You find out "quick login" means Face ID for some, while others mean 4-digit PIN.
This needs clarification and prioritization.
Types of Requirements

In Requirement Engineering, requirements are generally categorized into four major types:
1) Functional Requirements (FRs)

- Definition:
Functional requirements define what the system should do — the core features and behaviors of the
software. They describe interactions between the system and its users or other systems.

- Purpose:
To specify the actual functionality or services that the system must provide to fulfill user needs.

- Examples:
•The system must allow users to register using email and password.
•The system must enable users to log in and access their dashboard.
•The system should generate monthly sales reports.
•The system must allow the admin to delete a user account.

- Importance:
Functional requirements are directly related to user interactions. If not implemented correctly, the system
may not perform the intended job.
2. Product Requirements

- Definition:
• Product requirements describe the quality attributes of the system such as performance, reliability,
usability, security, and scalability.
• These are also known as non-functional requirements (a broader category).

- Purpose:
To define how well the system should perform the required functions.

- Examples:
•The system should respond within 2 seconds to user inputs.
• The system should have 99.9% uptime availability.
• The app should be user-friendly and intuitive.
• The system must support 1 million concurrent users.

- Importance:
Even if a system meets all its functional requirements, poor product qualities (e.g., slow performance or bad
usability) can cause failure or poor user satisfaction.
3. Organizational Requirements

- Definition:
• Organizational requirements are constraints or standards derived from the organization’s internal policies,
procedures, practices, or corporate goals. [Organizational requirements are rules, policies, or standards
that come from within a company ]

- Purpose:
To ensure that the software aligns with internal organizational needs, processes, and restrictions.

- Examples:
• The project must follow ISO 9001 standards.
• The software must be developed using Java as per company policy.
• Only open-source libraries approved by the legal department may be used.
• All project data must be stored in company-owned data centers.

- Importance:
Ignoring these constraints can lead to compliance violations or internal rejections.
These are usually non-negotiable.
4. External Requirements

- Definition:
• External requirements originate from outside the organization and are often imposed by third parties,
such as:
1. Government regulations
2. Industry standards
3. Legal agreements

- Purpose:
To ensure legal compliance and adherence to external authorities or market standards.

- Examples:
• The system must be GDPR compliant (General Data Protection Regulation).
• Data encryption must follow the AES-256 standard.

- Importance:
Non-compliance with external requirements can lead to legal penalties, project shutdown, or security breaches.
- Eliciting Requirements

Definition:

• Requirement Elicitation is the process of discovering, extracting, and understanding the needs and
expectations of stakeholders (users, clients, developers, business owners) for a software system.

• It is not just about asking what users want — it involves active listening, analyzing workflows, and
uncovering hidden needs.

Goal of Requirement Elicitation

• To gain a complete, accurate, and clear understanding of system requirements.

• To uncover real user needs (not just what they say).

• To handle conflicts and ambiguities in expectations early in the project.

Requirement Elicitation is the process of extracting requirements from stakeholders using techniques such as:

• Interviews
• Workshops
• Surveys/Questionnaires
• Use-case analysis
• Prototyping
• Observation

The goal is to understand what stakeholders really need.

Developing Use-Cases

What is a Use-Case?

• A use-case is a detailed description of how users (actors) interact with a system to achieve a specific goal.
• It captures functional requirements and describes step-by-step how the system responds to user actions.

Purpose of Use-Cases:

• Understand user interactions with the system

• Define system boundaries
• Help in requirement validation
• Assist in test case creation and design planning
 Key Elements of a Use-Case:

Element Description
The person, role, or external system
Actor
interacting with the system (e.g., User, Admin)
System The software or product being developed
A scenario describing an interaction to achieve
Use-Case
a goal
Conditions that must be true before the use-
Precondition
case begins
Basic Flow The normal or main path to complete the task
Alternate Flow Variations from the main path
Exception Flow What happens when something goes wrong
Postcondition The result after the use-case completes
Use-Case Name Login to System
Actor User
Preconditions User must be registered
1. User opens login page
2. Enters username & password
Basic Flow 3. Clicks "Login"
4. System validates credentials
5. User is redirected to dashboard
- User clicks "Forgot Password" and receives
Alternate Flow
reset link
- If credentials are wrong, system displays
Exception Flow
error message
Postcondition User is logged in successfully
Alternate Format – Use-Case Diagram (UML)

• A visual way to show actors and their interactions

with use-cases.

• Tools: Lucidchart, [Link], StarUML, etc.

- Building Requirement Models

Requirement models help visualize and structure requirements. Common models include:

1. Use-case diagrams (show system interactions)

2. Data Flow Diagrams (DFD)
3. Entity-Relationship Diagrams (ERD)
4. State transition diagrams
5. User stories (in Agile)

These models help clarify complex requirements and reveal hidden ones.
Use Case Diagram
Flow Chart
- Requirement Validation
- Requirement Negotiation

Conflicts may arise between stakeholders. Negotiation helps:

• Resolve conflicting requirements

• Prioritize features
• Agree on trade-offs (cost, time, scope)

Tools used:
• Discussion & meetings
• Prioritization techniques (MoSCoW: Must have, Should have, Could have, Won’t have)
Summary :

Topic Description
Gathering Collecting requirements from stakeholders
Analysis Checking for completeness, consistency
Functional Actions system must perform
Product Performance and quality attributes
Organizational Business rules and standards
External Regulatory/legal requirements
Elicitation Techniques to uncover stakeholder needs
Use-Cases User interaction scenarios
Models Visual representation (DFD, ERD)
Negotiation Resolving requirement conflicts
Validation Checking correctness and feasibility
2.4 Software Requirement Specification: Need, Format, and its Characteristics.

- What is SRS?

• SRS (Software Requirement Specification) is a formal document that captures the functional and non-
functional requirements of a software system.

• It serves as an agreement between stakeholders (clients, users) and developers on what the software
should do.
- Uses of SRS document

• Development team require it for developing product according to the need.

• Test plans are generated by testing group based on the describe external behavior.

• Maintenance and support staff need it to understand what the software product is supposed to do.

• Project manager base their plans and estimates of schedule, effort and resources on it.

• Customer rely on it to know that product they can expect.

• As a contract between developer and customer.

• in documentation purpose.
- Characteristics of a Good SRS
No. Characteristic Description

1. Correct Every requirement stated must be accurate and reflect stakeholder needs

2. Complete All possible scenarios, functionalities, and constraints must be covered

3. Unambiguous No vague words like “fast”, “easy”, or “user-friendly” without clear definition

4. Verifiable Every requirement should be testable (can you prove it’s met?)

5. Consistent No conflicting requirements

6. Modifiable Easy to update when changes are needed

7. Traceable Each requirement must be traceable through development to testing

8. Understandable Written in clear, simple language for both technical and non-technical readers

9. Feasible Technically and financially realistic to implement

10. Prioritized Requirements must be ranked by importance or urgency (if applicable)