SOFTWARE ENGINEERING

UNIT-2
[Link] Analysis and Specification
Software requirement analysis simply means complete study, analyzing, describing
software requirements so that requirements that are genuine and needed can be fulfilled to
solve problem.

1. Problem Recognition
The main aim of requirement analysis is to fully understand main objective of
requirement

2. Evaluation and Synthesis :

Evaluation means judgement about something whether it is worth or not and synthesis
means to create or form something.

3. Modeling :
After complete gathering of information from above tasks, functional and behavioral
models are established after checking function and behavior of system using a domain
model that also known as the conceptual model.

4. Specification :
The software requirement specification (SRS) which means to specify the requirement
whether it is functional or non-functional should be developed.

5. Review:
After developing the SRS, it must be reviewed to check whether it can be improved or
not and must be refined to make it better and increase the quality.

[Link] and Analysis

What is Requirements Gathering?
Requirements gathering is a crucial phase in the software development life cycle (SDLC)
and project management. It involves collecting, documenting, and managing the
requirements that define the features and functionalities of a system or application.

1
The success of a project often depends on the accuracy and completeness of the gathered
requirements in software.

Processes of Requirements Gathering in Software Development:

There are 6 steps crucial for requirement gathering processes

Step 1- Assigning roles:

• The first step is to identify and engage with all relevant stakeholders.
Stakeholders can include end-users, clients, project managers, subject matter
experts, and anyone else who has a vested interest in the software project.
Understanding their perspectives is essential for capturing diverse requirements.
Step 2- Define Project Scope:
• Clearly define the scope of the project by outlining its objectives, boundaries,
and limitations. This step helps in establishing a common understanding of what
the software is expected to achieve and what functionalities it should include.
Step 3- Conduct Stakeholder Interviews:
• Schedule interviews with key stakeholders to gather information about their
needs, preferences, and expectations. Through open-ended questions and
discussions, aim to uncover both explicit and implicit requirements. These
interviews provide valuable insights that contribute to a more understanding of
the project.
Step 4- Document Requirements:
• Systematically document the gathered requirements. This documentation can
take various forms, such as user stories, use cases, or formal specifications.
Clearly articulate functional requirements (what the system should do) and non-
functional requirements (qualities the system should have, such as performance
or security).
Step 5- Verify and Validate Requirements:
• Once the requirements are documented, it’s crucial to verify and validate them.
Verification ensures that the requirements align with the stakeholders’ intentions,
while validation ensures that the documented requirements will meet the
project’s goals. This step often involves feedback loops and discussions with
stakeholders to refine and clarify requirements.

2
Step 6- Prioritize Requirements:
• Prioritize the requirements based on their importance to the project goals and
constraints. This step helps in creating a roadmap for development, guiding the
team on which features to prioritize. Prioritization is essential, especially when
resources and time are limited.
Advantages:
• Cost Reduction
• Customer Satisfaction
• Improved Communication
• Enhanced Quality
Disadvantages:
• Poor Stakeholder Involvement
• Changing Requirements
• Communication Barriers

[Link]
• Software Requirement Specification (SRS) Format as the name suggests, is a
complete specification and description of requirements of the software that need to
be fulfilled for the successful development of the software system.
• These requirements can be functional as well as non-functional depending upon the
type of requirement.
Purpose

• Communication: Acts as a formal agreement between stakeholders and developers.

• Guidance: Provides a basis for system design, development, and validation.
• Clarity: Ensures all stakeholders have a clear and common understanding of the
requirements.

Key Components

1. Introduction:
o Purpose: The goal of the SRS document.
o Scope: Boundaries and limits of the software system.
o Definitions: Acronyms, abbreviations, and terms used in the document.
2. Overall Description:
o Product Perspective: Context of the software in its environment.
o Product Functions: Major functions the system performs.
o User Characteristics: Types and characteristics of end users.
o Assumptions and Dependencies: Assumptions made and dependencies on
external factors.

3
 3. Specific Requirements:
o Functional Requirements: Detailed description of each function the system
must perform.
o Non-Functional Requirements: System attributes such as performance,
security, usability, and reliability.
o External Interface Requirements: Interactions with other systems, hardware,
and software.
4. Appendices:
o Supporting Information: Glossary, references, and index.

Characteristics of a Good SRS

• Correctness: All stated requirements must be correct.

• Unambiguity: Clear and precise language to avoid misunderstandings.
• Completeness: All necessary requirements are included.
• Consistency: No conflicting requirements.
• Verifiability: Each requirement should be testable.
• Modifiability: Easy to update and modify as needed.
• Traceability: Ability to trace requirements to their origins and throughout the project
lifecycle.

Best Practices

• Use Clear Language: Avoid jargon and ambiguous terms.

• Involve Stakeholders: Regularly review and validate the document with stakeholders.
• Maintain Version Control: Keep track of changes and updates to the document.
• Use Templates: Follow standardized templates for consistency.
• Focus on User Needs: Prioritize requirements based on user and stakeholder needs.

Importance

• Alignment: Ensures the development team’s understanding aligns with the

stakeholders’ expectations.
• Planning: Provides a foundation for detailed project planning and resource allocation.
• Risk Reduction: Helps identify potential issues and conflicts early in the development
process.
• Quality Assurance: Facilitates validation and verification, ensuring the final product
meets requirements.

4
[Link] System Specification

Definition

• Formal System Specification: The use of formal methods, mathematical models, and
languages to describe the system's requirements and behavior with precision and rigor.

Techniques

1. Formal Languages:
o Z: A formal specification language based on set theory and first-order predicate
logic.
o VDM (Vienna Development Method): Uses model-based specifications to
describe system behavior.
o B-Method: Employs abstract machines to model systems and support formal
proof of correctness.
2. Mathematical Models:
o State Machines: Models that describe system states and transitions.
o Petri Nets: Graphical and mathematical modeling tools suitable for describing
concurrent processes.
o Process Algebras: Mathematical models for analyzing and verifying concurrent
systems (e.g., CSP, CCS).

Objectives

• Precision: To provide an exact, unambiguous specification of system requirements.

• Verification: To enable formal verification and validation of requirements, ensuring
correctness and consistency.
• Communication: To facilitate precise communication among stakeholders,
particularly in complex systems.

Advantages

• Reduces Ambiguities: Eliminates misunderstandings and inconsistencies in

requirements.
• Enhances Reliability: Increases the reliability and correctness of the system through
rigorous specification.
• Facilitates Verification: Allows for formal verification methods to prove properties of
the system, such as safety and liveness.

Disadvantages:

• Specialized Knowledge: Requires expertise in formal methods and mathematical

modeling.

5
 • Time-Consuming: Can be labor-intensive and time-consuming to develop formal
specifications.
• Complexity: May be difficult for non-technical stakeholders to understand and engage
with formal specifications.
• Cost: Implementation and training can be costly.

Applications

• Safety-Critical Systems: Widely used in domains where system failures can have
severe consequences, such as aerospace, medical devices, and nuclear power.
• High Assurance Systems: Applied in systems requiring high assurance of correctness,
such as financial systems and critical infrastructure.

Examples

• NASA’s Software: Utilizes formal methods to ensure the reliability of software for
space missions.
• Railway Signaling Systems: Employs formal specifications to ensure safety and
correctness in signaling protocols.

Importance

• Ensures Accuracy: By providing a precise and unambiguous description, formal

specifications ensure the accurate representation of requirements.
• Improves Quality: Leads to higher quality software by enabling thorough verification
and reducing defects early in the development process.
• Supports Complex Systems: Facilitates the development and maintenance of complex
systems by providing clear, rigorous documentation.

Using formal system specification in software engineering is essential for projects that demand
high levels of accuracy, reliability, and safety.