MODULE 1 BY , SHRESTA MANGALA

Introduction: Software Crisis, Need for Software Engineering. Professional Software Development, Software
Engineering Ethics. Case Studies
Software Processes: Models: Waterfall Model, Incremental Model and Spiral Model, Process activities.
Requirements Engineering: Requirements Engineering Processes. Requirements Elicitation and
Analysis. Functional and non-functional requirements, The software Requirements Document. Requirements

What is software engineering?

➢ Software engineering is an engineering discipline which is concerned with all aspects of software
production.
➢ Engineering discipline
• Engineers make things work. They apply theories, methods and tools where these are appropriate,
but they use them selectively and always try to discover solutions to problems even when there
are no applicable theories and methods.
• Engineers also recognize that they must work to organizational and financial
constraints, so they look for solutions within these constraints.
• Software engineering is not just concerned with the technical processes of software development
but also with activities such as software project management and with the development of tools,
methods and theories to support software production.

NEED FOR SOFTWARE ENGINEERING

The need for software engineering arises from the complexities and challenges associated with developing
software that meets user expectations, operates effectively, and remains maintainable over time. Here are several
key reasons why software engineering is essential:
1. Complexity Management
• Increasing Complexity: Software systems are becoming more complex due to advanced functionalities and
integrations. Software engineering provides methodologies to manage this complexity through structured
design and modularity.
• Interoperability: Modern software often needs to interact with other systems, requiring careful planning and
design to ensure compatibility.
2. Quality Assurance
• Reliability: Software engineering practices, such as testing and validation, help ensure that the software
performs reliably under various conditions.
• Defect Reduction: Systematic approaches reduce the likelihood of defects, leading to higher quality
software and improved user satisfaction.
3. Cost Efficiency
• Resource Optimization: By following established processes and best practices, software engineering can
minimize wasted resources and time, leading to cost-effective development.
 • Maintenance Costs: Well-engineered software is easier to maintain and update, reducing long-term costs
associated with software lifecycles.
4. User -Centric Development
• Requirements Gathering: Software engineering emphasizes understanding user needs through requirements
analysis, ensuring that the final product meets expectations.
• User Experience: Incorporating user feedback during the development process leads to better usability and
satisfaction.
5. Scalability and Flexibility
• Adaptability: As business needs change, software must evolve. Software engineering practices facilitate
easier updates and scalability.
• Future-Proofing: A solid engineering foundation allows for the integration of new technologies and features
without extensive rework.
6. Project Management
• Structured Approach: Software engineering incorporates project management principles, helping teams
plan, execute, and monitor projects effectively.
• Risk Management: Identifying and mitigating risks early in the development process leads to more
predictable outcomes.
PROFESSIONAL SOFTWARE DEVELOPMENT
Professional software development refers to the systematic and structured approach to designing, developing,
testing, and maintaining software applications. It involves a set of principles, practices, and methodologies that
ensure the delivery of high-quality software products that meet user needs and expectations.
Characteristics of Professional Software Development
• Disciplined Approach: Professional software development follows established processes and methodologies
to ensure consistency and quality.
• Continuous Improvement: Developers continually update their skills and knowledge to stay current with
industry trends and best practices.
• Collaboration: Cross-functional teams work together to ensure that software meets user needs and is
aligned with business objectives.
• Quality Focus: Professional software development prioritizes quality, with a focus on testing, validation,
and continuous improvement.
• Adaptability: Developers are adaptable and responsive to changing user needs and market conditions.
Best Practices in Professional Software Development
• Agile Methodologies: Agile approaches, such as Scrum and Kanban, facilitate iterative development,
continuous improvement, and flexibility.
• Test-Driven Development (TDD): TDD ensures that software is thoroughly tested and validated before
deployment.
• Continuous Integration and Continuous Deployment (CI/CD): CI/CD automates testing, building, and
deployment, reducing the risk of errors and improving efficiency.
• Code Reviews: Regular code reviews promote knowledge sharing, improve code quality, and reduce
defects.
 • Version Control: Version control systems, such as Git, enable collaboration, tracking, and management of
code changes.
Benefits of Professional Software Development
• Improved Quality: Professional software development ensures that software is reliable, stable, and meets
user needs.
• Increased Efficiency: Structured approaches and best practices reduce development time and costs.
• Enhanced Collaboration: Cross-functional teams promote communication, knowledge sharing, and a shared
understanding of project goals.
• Better Risk Management: Professional software development identifies and mitigates risks early in the
development process.
• Competitive Advantage: High-quality software products can differentiate organizations and provide a
competitive advantage.
Challenges in Professional Software Development
• Complexity: Modern software systems are increasingly complex, requiring specialized skills and expertise.
• Rapidly Changing Technology: The rapid pace of technological change demands continuous learning and
adaptation.
• Talent Acquisition and Retention: Attracting and retaining skilled developers is a significant challenge in
the industry.
• Time and Budget Constraints: Development teams often face tight deadlines and limited budgets, requiring
efficient and effective development processes.

SOFTWARE ENGINEERING ETHICS.

Software engineering ethics refers to the moral principles and professional standards that guide software
engineers in their work. As the software industry grows and impacts society significantly, ethical
considerations become increasingly important. Here are key aspects of software engineering ethics.
Key Principles of Software Engineering Ethics
1. Public Interest:
• Software engineers should prioritize the public good and consider the societal impact of their work.
• They must ensure their software is safe, secure, and respects user privacy.
2. Professional Competence:
• Engineers should maintain and improve their professional skills and knowledge.
• They must only undertake projects for which they are qualified and capable.
3. Integrity:
• Honesty and transparency are crucial in all professional interactions.
• Engineers should avoid conflicts of interest and disclose any potential biases.
4. Confidentiality:
 • Respecting the confidentiality of client and user information is paramount.
• Engineers must safeguard sensitive data and only use it for intended purposes.
5. Quality and Reliability:
• Software engineers have a responsibility to produce high-quality software that meets specifications
and user needs.
• They should implement rigorous testing and validation processes to ensure reliability.
6. Fairness and Non-Discrimination:
• Engineers should strive for inclusivity and accessibility in their software design.
• They must avoid discrimination and ensure that their software is usable by diverse populations.
7. Social Responsibility:
• Software engineers should consider the broader implications of their work on society and the
environment.
• They must advocate for ethical practices within their organizations and the industry.

Challenges Software Engineers Encounter in Their Day-to-Day Work

Software engineers face a variety of challenges in their daily tasks, which can impact their productivity, job
satisfaction, and the quality of the software they produce. Here are some common challenges along with typical
strategies for overcoming them:
1. Complex Problem-Solving
• Challenge: Software development often involves tackling complex problems that require critical thinking
and innovative solutions.
• Overcoming Strategy:
• Break Down Problems: Engineers can decompose complex problems into smaller, manageable tasks
to tackle them more effectively.
• Collaborative Brainstorming: Engaging with team members for brainstorming sessions can lead to
diverse perspectives and solutions.
2. Changing Requirements
• Challenge: Requirements may change frequently due to evolving business needs or user feedback, leading
to scope creep.
• Overcoming Strategy:
• Agile Methodologies: Implementing Agile practices allows for iterative development and flexibility
to adapt to changes.
• Regular Communication: Maintaining open lines of communication with stakeholders helps ensure
alignment on expectations.
3. Time Constraints and Deadlines
• Challenge: Engineers often face tight deadlines, which can lead to stress and compromised quality.
• Overcoming Strategy:
 • Prioritization: Utilizing prioritization techniques, such as the Eisenhower Matrix, helps focus on the
most critical tasks.
• Time Management Tools: Tools like Trello or Asana can aid in tracking progress and managing
tasks effectively.
4. Technical Debt
• Challenge: Accumulating technical debt can hinder future development and maintenance efforts.
• Overcoming Strategy:
• Code Refactoring: Regularly allocating time for code refactoring can help reduce technical debt
over time.
• Establishing Best Practices: Implementing coding standards and best practices can minimize the
introduction of new technical debt.
5. Team Collaboration and Communication
• Challenge: Working in cross-functional teams can lead to misunderstandings and misalignment.
• Overcoming Strategy:
• Daily Stand-ups: Conducting daily stand-up meetings fosters communication and keeps everyone
aligned on project goals.
• Collaboration Tools: Utilizing tools like Slack or Microsoft Teams can facilitate better
communication among team members.
6. Keeping Up with Technology
• Challenge: The rapid pace of technological advancements can make it difficult for engineers to stay current.
• Overcoming Strategy:
• Continuous Learning: Engaging in online courses, workshops, and tech meetups can help engineers
stay updated on industry trends.
• Mentorship: Seeking mentorship from more experienced colleagues can provide guidance and
insights into new technologies.
7. Debugging and Troubleshooting
• Challenge: Identifying and fixing bugs can be time-consuming and frustrating.
• Overcoming Strategy:
• Systematic Debugging: Using systematic debugging techniques, such as rubber duck debugging or
logging, can help isolate issues.
• Peer Reviews: Collaborating with peers for code reviews can provide fresh perspectives and catch
errors early.
8. Work-Life Balance
• Challenge: The demanding nature of software development can lead to burnout and poor work-life balance.
• Overcoming Strategy:
• Setting Boundaries: Engineers should establish clear boundaries between work and personal time to
maintain balance.
 • Regular Breaks: Taking regular breaks and practicing self-care can enhance productivity and reduce
stress.

Software Engineering Ethics

➢ Software engineering involves wider responsibilities than simply the application of technical skills.
➢ Software engineers must behave in an honest and ethically responsible way if they are to be respected
as professionals.
➢ Ethical behaviour is more than simply upholding the law but involves following a set of
principles that are morally correct.
• Confidentiality
Engineers should normally respect the confidentiality of their employers or clients irrespective of whether
or not a formal confidentiality agreement has been signed.

• Competence
Engineers should not misrepresent their level of competence. They should not knowingly accept work
which is out with their competence.
• Intellectual property rights
Engineers should be aware of local laws governing the use of intellectual property such as patents,
copyright, etc. They should be careful to ensure that the intellectual property of employers and clients is
protected.
• Computer misuse Software engineers should not use their technical skills to misuse other
people's
Case studies
A personal insulin pump
• An embedded system in an insulin pump used by diabetics to maintain blood glucose
control. 4 A mental health case patient management system
• A system used to maintain records of people receiving care for mental health
problems. 4 A wilderness weather station
• A data collection system that collects data about weather conditions in remote
areas.
Insulin pump control system
Collects data from a blood sugar sensor and calculates the amount of insulin required to
be injected. 4 Calculation based on the rate of change of blood sugar levels.
• Sends signals to a micro-pump to deliver the correct dose of insulin.
• Safety-critical system as low blood sugars can lead to brain malfunctioning, coma and death; high-blood
sugar levels have long-term consequences such as eye and kidney damage.
Essential high-level requirements
➢ The system shall be available to deliver insulin when required.
➢ The system shall perform reliably and deliver the correct amount of insulin to counteract the current
level of blood sugar.
➢ The system must therefore be designed and implemented to ensure that the system always meets these
requirements.
A patient information system for mental health care
➢ A patient information system to support mental health care is a medical information system that maintains
information about patients suffering from mental health problems and the treatments that they have
received.
➢ Most mental health patients do not require dedicated hospital treatment but need to attend specialist
clinics regularly where they can meet a doctor who has detailed knowledge of their problems.
➢ To make it easier for patients to attend, these clinics are not just run in hospitals. They may also be held
in local medical practices or community centres.
➢ The MHC-PMS (Mental Health Care-Patient Management System) is an information system that is
intended for use in clinics.
➢ It makes use of a centralized database of patient information but has also been designed to run on a PC,
so that it may be accessed and used from sites that do not have secure network connectivity.
➢ When the local systems have secure network access, they use patient information in the database but they
can download and use local copies of patient records when they are disconnected.

MHC-PMS goals
➢ To generate management information that allows health service managers to assess
performance against local and government targets.
➢ To provide medical staff with timely information to support the treatment of patients.
MHC-PMS key feature
➢ Individual care management
• Clinicians can create records for patients, edit the information in the system, view patient history,
etc. The system supports data summaries so that doctors can quickly learn about the key problems
and treatments that have been prescribed.

➢ Patient monitoring
The system monitors the records of patients that are involved in treatment and issues warnings if
possible problems are detected.
➢ Administrative reporting
The system generates monthly management reports showing the number of patients treated at each clinic,
the number of patients who have entered and left the care system, number of patients sectioned, the drugs
prescribed and their costs, etc.
➢ Privacy
It is essential that patient information is confidential and is never disclosed to anyone apart from
authorised medical staff and the patient themselves.
➢ Safety
o Some mental illnesses cause patients to become suicidal or a danger to other people. Wherever
possible, the system should warn medical staff about potentially suicidal or dangerous patients.
o The system must be available when needed otherwise safety may be compromised and it may
be impossible to prescribe the correct medication to patients.
Wilderness weather station
➢ The government of a country with large areas of wilderness decides to deploy several hundred
weather stations in remote areas.
➢ Weather stations collect data from a set of instruments that measure temperature and pressure,
sunshine, rainfall, wind speed and wind direction.
• The weather station includes a number of instruments that measure weather parameters such as the
wind speed and direction, the ground and air temperatures, the barometric pressure and the
rainfall over a 24-hour period. Each of these instruments is controlled by a software system that
takes parameter readings periodically and manages the data collected from the instruments.
The weather station's environment
Weather information system
➢ The weather station system
➢ This is responsible for collecting weather data, carrying out some initial data processing and
transmitting it to the data management system.
➢ The data management and archiving system
➢ This system collects the data from all of the wilderness weather stations, carries out data processing
and analysis and archives the data.
➢ The station maintenance system
➢ This system can communicate by satellite with all wilderness weather stations to monitor the health of
these systems and provide reports of problems.
Additional software functionality
• Monitor the instruments, power and communication hardware and report faults to the
management system.

• Manage the system power, ensuring that batteries are charged whenever the environmental conditions
permit but also that generators are shut down in potentially damaging weather conditions, such as
high wind.
• Support dynamic reconfiguration where parts of the software are replaced with new versions and where
backup instruments are switched into the system in the event of system failure.

SOFTWARE PROCESSES MODELS

➢ The waterfall model

Plan-driven model. Separate and distinct phases of specification and development.
➢ Incremental development
Specification, development and validation are interleaved. May be plan-driven or agile.
➢ Reuse-oriented software engineering
The system is assembled from existing components. May be plan-driven or agile.
In practice, most large systems are developed using a process that incorporates elements from all of these
models.
The waterfall model
➢ Requirements analysis and definition
The system's services, constraints, and goals are established by consultation with system users. They
are then defined in detail and serve as a system specification.
➢ System and software design
The systems design process allocates the requirements to either hardware or software systems by
establishing an overall system architecture. Software design involves identifying and describing the
fundamental software system abstractions and their relationships.
➢ Implementation and unit testing
During this stage, the software design is realized as a set of programs or program units. Unit testing
involves verifying that each unit meets its specification.
 ➢ Integration and system testing
The individual program units or programs are integrated and tested as a complete system to ensure that
the software requirements have been met. After testing, the software system is delivered to the customer.
➢ Operation and maintenance
The system is installed and put into practical use. Maintenance involves correcting errors which were not
discovered in earlier stages of the life cycle, improving the implementation of system units and enhancing
the system's services as new requirements are discovered.

Waterfall model problems

➢ Inflexible partitioning of the project into distinct stages makes it difficult to respond to changing
customer requirements.
➢ Therefore, this model is only appropriate when the requirements are well-understood and changes
will be fairly limited during the design process.
➢ Few business systems have stable requirements.
➢ The waterfall model is mostly used for large systems engineering projects where a system is developed
at several sites.
➢ In those circumstances, the plan-driven nature of the waterfall model helps
coordinate the work.

Example Projects Suitable for the Waterfall Model

1. Hospital Management System
2. E-commerce Website Development
3. Payroll Management System
4. Library Management System
5. Government Database System
6. Inventory Management System
7. Point of Sale (POS) System
Detailed Explanation: Hospital Management System
Project Overview: A Hospital Management System (HMS) is designed to manage various aspects of a hospital's
operations, including patient records, appointments, billing, and inventory management. This project is suitable for
the Waterfall model due to its well-defined requirements and the need for compliance with healthcare regulations.
Steps of the Waterfall Model in the Hospital Management System Project
1. Requirements Gathering and Analysis
• Objective: Identify and document all requirements for the HMS.
• Activities:
• Conduct interviews with stakeholders, including doctors, nurses, and administrative staff, to
gather their needs.
• Document functional requirements (e.g., patient registration, appointment scheduling,
billing) and non-functional requirements (e.g., security, performance).
• Output: A comprehensive requirements specification document that outlines all features and
functionalities of the HMS.
2. System Design
• Objective: Create a detailed design based on the gathered requirements.
• Activities:
• Design the system architecture, including the database schema, user interface, and system
interactions.
• Develop design documents that specify how each component of the HMS will function and
interact with others.
• Output: Detailed design specifications that guide developers in building the system.
3. Implementation (Coding)
• Objective: Develop the HMS according to the design specifications.
• Activities:
• Write code for the backend (e.g., database interactions, business logic) and frontend (e.g.,
user interface).
• Ensure that the code follows established coding standards and best practices.
• Output: A functioning Hospital Management System that aligns with the design documents.
4. Testing
• Objective: Verify that the HMS meets the specified requirements and is free of defects.
• Activities:
• Perform unit testing on individual components, integration testing to ensure components
work together, and system testing to validate the complete system.
• Conduct user acceptance testing (UAT) with stakeholders to confirm that the system meets
their needs.
• Output: A thoroughly tested Hospital Management System, ready for deployment.
5. Deployment
• Objective: Release the HMS to users.
• Activities:
• Install the system on the production server and configure it for use.
• Provide training sessions for users to familiarize them with the new system.
• Output: The Hospital Management System is live and operational for the hospital staff.
6. Maintenance
• Objective: Address any issues and implement updates post-deployment.
• Activities:
• Monitor the system for bugs or performance issues and provide necessary patches.
• Gather user feedback for potential enhancements or additional features.
• Output: A well-maintained Hospital Management System that evolves according to user needs over
time.
Incremental development

➢ Incremental software development, which is a fundamental part of agile approaches, is better than a
waterfall approach for most business, e-commerce, and personal systems.
➢ Incremental development reflects the way that we solve problems.
➢ We rarely work out a complete problem solution in advance but move toward a solution in a series of
steps, backtracking when we realize that we have made a mistake. By developing the software
incrementally, it is cheaper and easier to make changes in the software as it is being developed.
➢ Each increment or version of the system incorporates some of the functionality that is needed by
the customer.
➢ Generally, the early increments of the system include the most important or most urgently required
functionality. This means that the customer can evaluate the system at a relatively early stage in the
development to see if it delivers what is required. If not, then only the current increment has to be changed
and, possibly, new functionality defined for later increments.
Incremental development benefits
➢ The cost of accommodating changing customer requirements is reduced.
The amount of analysis and documentation that has to be redone is much less than is required with the
waterfall model.
➢ 4 It is easier to get customer feedback on the development work that has been done.
Customers can comment on demonstrations of the software and see how much has been implemented.
➢ More rapid delivery and deployment of useful software to the customer is possible. Customers are
able to use and gain value from the software earlier than is possible with a waterfall process
Spiral Model

Identification
This phase starts with gathering the business requirements in the baseline spiral. In the subsequent spirals as
the product matures, identification of system requirements, subsystem requirements and unit requirements are
all done in this phase.
This phase also includes understanding the system requirements by continuous communication between the
customer and the system analyst. At the end of the spiral, the product is deployed in the identified market.
Design
The Design phase starts with the conceptual design in the baseline spiral and involves architectural design,
logical design of modules, physical product design and the fmal design in the subsequent spirals.
Construct or Build
The Construct phase refers to production of the actual software product at every spiral. In the baseline spiral,
when the product is just thought of and the design is being developed a POC (Proof of Concept) is developed in
this phase to get customer feedback.

• Then in the subsequent spirals with higher clarity on requirements and design details a working model of
the software called build is produced with a version number. These builds are sent to the customer for
feedback.
Evaluation and Risk Analysis
Risk Analysis includes identifying, estimating and monitoring the technical feasibility and management risks,
such as schedule slippage and cost overrun. After testing the build, at the end of first iteration, the customer
evaluates the software and provides feedback.
Spiral Model Application
When there is a budget constraint and risk evaluation is important.
• For medium to high-risk projects.
• Long-term project commitment because of potential changes to economic priorities as the
requirements change with time.
• Customer is not sure of their requirements which are usually the case.
• Requirements are complex and need evaluation to get clarity.
• New product line which should be released in phases to get enough customer feedback.
• Significant changes are expected in the product during the
development cycle.

The advantages of the Spiral SDLC Model are as follows

➢ Changing requirements can be accommodated.
➢ Allows extensive use of prototypes.
➢ Requirements can be captured more accurately.
➢ Users see the system early.
➢ Development can be divided into smaller parts and the risky parts can be developed earlier which
helps in better risk management.
The disadvantages of the Spiral SDLC Model are as follows
➢ Management is more complex.
➢ End of the project may not be known early.
➢ Not suitable for small or low risk projects and could be expensive for small projects.
➢ Process is complex
➢ Spiral may go on indefinitely.
SOFTWARE DEVELOPMENT, IT'S ESSENTIAL TO HAVE A STRATEGIC APPROACH
.Here are some tips to help you learn new technologies efficiently:
First, identify the technology you want to learn and understand its relevance to your current or desired job role.
This will help you stay motivated throughout the learning process.
Setting Goals and Planning
• Define the end goal: Identify what you want to achieve with the new technology. This could be building a
specific project, improving your skills, or enhancing your career prospects.
• Set a deadline: Establish a realistic timeline to learn the technology. This will help you stay focused and
track your progress.
• Create a learning plan: Break down your learning process into smaller, manageable chunks. Allocate time
for each task, and prioritize the most critical aspects of the technology.
Learning Strategies
• Find reliable resources: Look for high-quality tutorials, online courses, books, or blogs that provide in-
depth information on the technology. Ensure the resources are up-to-date and relevant to your goals.
• Practice hands-on: Apply your knowledge by working on practical projects or exercises. This will help you
retain information better and gain real-world experience.
• Join online communities: Participate in online forums, discussion groups, or social media platforms focused
on the technology. This will provide access to a network of experts, resources, and support.
Time Management and Focus
• Allocate dedicated time: Set aside a specific time slot each day or week to focus on learning the new
technology. Minimize distractions during this time.
• Stay organized: Keep track of your progress, note down important concepts, and review them regularly.
• Avoid information overload: Focus on one aspect of the technology at a time. Avoid trying to learn
everything at once, as this can lead to confusion and burnout.
Review and Reflection
• Regularly review: Schedule regular review sessions to reinforce your understanding of the technology.
• Reflect on your progress: Identify areas where you need improvement and adjust your learning plan
accordingly.
Collaboration and Feedback
• Find a mentor: Seek guidance from an experienced professional who can provide valuable insights and
feedback.
• Collaborate with others: Join online groups or find a study partner to collaborate on projects and share
knowledge.
By following these steps, you can quickly learn a new technology in software development and stay ahead in your
career.
Here's an example of how I applied these strategies to learn a new technology:
Learning React
• Goal: Build a web application using React within 3 months.
• Learning plan: Allocate 2 hours each day to learn React, focusing on one topic at a time (e.g., components,
state management, routing).
• Resources: Used online tutorials, React documentation, and online courses to learn the basics.
• Practice: Built small projects, such as a to-do list app, to apply my knowledge.
• Community: Participated in online forums, such as the React subreddit, to connect with other developers
and get feedback on my projects.
• Review and reflection: Scheduled weekly review sessions to reinforce my understanding of React and
identified areas for improvement
 REQUIREMENTS ENGINEERING

REQUIREMENT ENGINEERING PROCESS

Requirement engineering is a critical phase in software development that involves identifying, analyzing,
documenting, and maintaining the requirements of a software system. It is a systematic approach to understanding
the needs of stakeholders and ensuring that the software meets those needs.
The processes used for RE vary widely depending on the application domain,
the people involved and the organisation developing the requirements.
However, there are a number of generic activities common to all processes
which are:
1. Feasibility Study
2. Requirements elicitation;
3. Requirements analysis;
4. Requirements validation;
5. Requirements management
Feasibility Study : Decides whether or not the proposed system is worthwhileattempting. A
short focused study that checks the following:

If the system contributes to organisational objectives;

If the system can be engineered using current technology and withinbudget;

If the system can be integrated with other systems that are used
If the system can fit into the cultural framework of the organizationalculture and
acceptable to all the stake-holders

Requirement Elicitation
Involves Interacting with technical staff working with customers to find out about
the application domain, the services that the system should provide and the system‟s operational
constraints. This may involve stakeholders like end-users, managers, Engineers involved in
maintenance, domain experts, trade unions, etc. Domain requirements are also discovered at this
[Link] Requirements are derived from the application domain rather than specific needsof
a customer in that domain. They usually refer to specialized domain terminology / concepts. They
describe system characteristics & features that reflect the domain. Domain requirements could be

1. New functional requirements,

2. Constraints on existing requirements or
3. Define specific computations.
 If domain requirements are not satisfied, the system may be unworkable.
The requirements elicitation and analysis process
Fig 15 shows the process of requirements elicitation and analysis.

Fig 15: Requirements elicitation and analysis process

Requirements validation
This is concerned with demonstrating that the requirements define the
system that thecustomer really wants. Requirements error costs are high so
validation is very important. Fixing a requirements error after delivery may
cost up to 100 times the cost of fixing animplementation error.
Requirements checking
To check the requirements for a software, the following parameters need
to beconsidered:
1. Validity. Does the system provide the functions which best support the
customer‟sneeds?
2. Consistency. Are there any requirements conflicts?
3. Completeness. Are all functions required by the customer included?
4. Realism. Can the requirements be implemented given available
budget andtechnology
5. Verifiability. Can the requirements be checked?
Requirements validation techniques
Various ways exist for validating the requirements:
1. Requirements reviews: This involves systematic manual analysis of
therequirements.
2. Prototyping: This involves using an executable model of the
system to checkrequirements.
3. Test-case generation: Developing tests for requirements to check testability.
Requirements reviews
It is essential that regular reviews should be held while the requirements
definition is being formulated. Both client and contractor staff should be
involved in reviews. Reviewsmay be formal (with completed documents) or
informal. Good communications between developers, customers and users can
resolve problems at an early stage.
Review checks
Parameters for review checks consist of checking for the following:
1. Verifiability: Is the requirement realistically testable?
2. Comprehensibility: Is the requirement properly understood?
3. Traceability: Is the origin of the requirement clearly stated?
4. Adaptability: Can the requirement be changed without a large
impact on other requirements?
Requirements management
Process of understanding and controlling the changing requirements during the requirements
engineering process and system development forms the major activity of requirements
management. Requirements are inevitably incomplete & inconsistent. New requirements emerge
during the process as business needs change and a better understanding of the system is developed.
Different viewpoints have different requirements and these are often contradictory. All this needs
reconciliation & management.
Reasons for change in Requirements
The business and technical environment of the system always changes after installation. New
hardware may be introduced, it may be necessary to interface the system with other systems,
business priorities may change (with consequent changes in the system support required), and
new legislation and regulations may be introduced that the system must necessarily abide by.

The people who pay for a system and the users of that system are rarely the same people. System
customers impose requirements because of organizational and budgetary constraints. These may
conflict with end-user requirements and, after delivery; new features may have to be added for
user support if the system is to meet its goals. Large systems usually have a diverse user
community, with many users having different requirements and priorities that may be conflicting
or contradictory. The final system requirements are inevitably a compromise between them and,
with experience, it is often discovered that the balance of support given to different users has to
be changed

Requirements management planning

This activity establishes the level of requirements management detail that is required. It isessential that
Requirements management decisions need to be taken for the following purposes
Requirements identification- Each requirement must be uniquely identified so thatit can be
cross-referenced with other requirements.

Requirements identification- Each requirement must be uniquely identified so thatit can be

cross-referenced with other requirements.

A change management process -This is the set of activities that assess the impact and cost of
changes. I discuss this process in more detail in the following section.

Traceability policies- These policies define the relationships between each requirement and
between the requirements and the system design that should be recorded.

Tool support- Tools that may be used range from specialist requirements management systems
to spreadsheets and simple database systems

Why is Requirement Engineering Important?

1. Prevents Miscommunication: Requirement engineering helps to prevent miscommunication among
stakeholders by ensuring that everyone has a clear understanding of the software's requirements.
2. Reduces Errors: By identifying and documenting requirements early on, requirement engineering reduces
the likelihood of errors and defects in the software.
3. Improves Quality: Requirement engineering ensures that the software meets the needs of stakeholders,
resulting in a higher-quality product.
4. Saves Time and Money: By identifying and addressing requirements early on, requirement engineering can
save time and money by reducing the need for costly rework and changes later in the development process.
Classification of requirements
Functional requirements: Statements of services the system should provide, how the system should react to
particular inputs and how the system should behave in particular situations. These requirements may also state
what the system should not do.
Non-functional requirements: Constraints on the services or functions offered by the system such as timing
constraints, constraints on the development process, standards, etc.
Functional Requirements:
Describe functionality or system services and depend on the type of software, expected users and the organization
where the software is used. This could be high-level statements of what the system should do. However, it should
describe all the system services in detail which could include its inputs, its Outputs, exceptions and so on. Such
requirements are generally described in fairly abstract but precise way.
Non-Functional Requirements:
Define system properties and constraints e.g. reliability, response time and storage occupancy, Security, etc..
Alternatively they may define platform constraints like, I/O devices capability, data representations. Process
requirements may also be specified mandating a particular C CASE system, programming language or
development method. These requirements arise through organizational policies, budget limits,
interoperability needs etc. They may be considered to be more critical than functional requirements
because if these are not met, the system will be useless.
Non-functional requirements can be further classified as shown in Fig 12
Fig 12: Classification of Non-functional requirements
The classification can be described as given below:
1. Product requirements: Requirements which specify that the
delivered product must behave in a particular way e.g. execution
speed, reliability, etc.
2. Organisational requirements: Requirements which are a
consequence of organisational policies and procedures e.g. process
standards used, implementation requirements, etc.
External requirements: Requirements which arise from factors which are external to the
system and its development process e.g. interoperability requirements, legislative
requirements, etc
Non-functional requirements may affect the overall architecture of a system rather than the
individual components. For example, to ensure that performance requirements are met, you
may have to organize the system to minimize communications between components.
A single non-functional requirement, such as a security requirement, may generate a number
of related functional requirements that define system services that are required. It may also
generate requirements that restrict existing requirements.
Metrics for specifying nonfunctional requirements
Since non-functional requirements are equally important for the operation of a software metrics
have been defined to indicate non-functional requirements as a part of requirements
specification document. This is indicated in Table 1.

Table 1 : Metrics for non-functional requirements

Property Measure

Speed Processed transactions/second User/event

response time Screen refresh time

Size Mbytes
Number of ROM chips

Ease of use Training time

Number of help frames
Reliability Mean time to failure Probability of
unavailability Rate of failure occurrence
Availability

Robustness Time to restart after failure Percentage of events

causing failure
Probability of data corruption on failure

Portability Percentage of target dependent statements

Number of target systems

The software requirements document

The software requirements document is the official statement of what is required
of the system developers. It should include both a definition of user
requirements and a specification of the system requirements. It is not a design
document. As far as possible, it should be a set of what the system should do
rather than how it should do it.
Fig 13 shows the users of a requirements document. The illustration is self-
explanatory. It should be noted that requirements specification is not just for end
users or for developers. It is for all those entities who are involved through out
the software development process.
Fig 13: Users of a software requirements document IEEE structure of a
requirements document
The table below describes the various chapters and its description for a standard
requirements document. This is given by the IEEE. All software do not
necessarily follow this exact structure. But a standard structure tuned to the needs
of the application is required to be followed.

Steps to Create a Software Requirements Document

1. Define the Purpose and Scope
• Purpose: Clearly state the purpose of the document.
• Scope: Outline what the application will cover and what it will not
(inclusions and exclusions).
2. Gather Stakeholder Input
• Identify stakeholders (users, clients, developers, etc.).
• Conduct interviews, surveys, and workshops to gather requirements.
• Use techniques like brainstorming sessions to capture diverse
perspectives.
3. Create an Overall Description
• Product Perspective: Describe how the application fits into the larger
system or business context.
• Product Functions: Summarize the high-level functionalities of the
application.
• User Classes and Characteristics: Identify different user types and
their needs.
• Constraints and Assumptions: Note any constraints (technical,
regulatory) and assumptions that affect the project.
4. Document Functional Requirements
• Break down the application into specific functionalities.
• Use use cases or user stories to illustrate how users will interact with
the application.
• Prioritize requirements based on stakeholder needs.
5. Document Non-Functional Requirements
• Specify performance requirements (e.g., response time, load
capacity).
• Detail security requirements (e.g., authentication, data encryption).
• Outline usability requirements (e.g., user interface design,
accessibility standards).
• Include reliability requirements (e.g., uptime, fault tolerance).
6. Define System Requirements
• List hardware and software specifications necessary for the
application to run.
• Outline network requirements (e.g., internet connectivity).
• Specify compatibility with existing systems or third-party services.
7. Document User Requirements
• Capture specific needs and expectations of end-users.
• Include user interface requirements to guide design.
8. Outline Business Requirements
• Detail high-level business goals and objectives the application aims
to achieve.
• Include compliance and regulatory needs.
9. Identify Transition Requirements
• Specify what is needed to transition from the current state to the
desired state (e.g., data migration, user training).
• Outline training and support needs for users.
[Link] and Validate Requirements
• Conduct reviews with stakeholders to validate the documented
requirements.
• Ensure that all requirements are clear, complete, and agreed upon.
[Link] Appendices
• Include any additional information, such as a glossary of terms,
references, and diagrams.
12. Maintain and Update the Document
• Keep the document updated throughout the development process to
reflect any changes in requirements.
• Establish a process for managing changes to requirements.