Program

B.C.A Semester V
Name
Course Title Software Engineering (Theory)
Course Code: DSC15 No. of Credits 04
Contact hours 52 Hours Duration of SEA/Exam 2 hours
Formative Assessment
40 Summative Assessment Marks 60
Marks

Course Outcomes (COs): After the successful completion of the course, the student will be able to:
How to apply the software engineering lifecycle by demonstrating competence in
CO1
communication, planning, analysis, design, construction, and deployment.
CO2 An ability to work in one or more significant application domains.
Work as an individual and as part of a multidisciplinary team to develop and deliver quality
CO3
software.
Demonstrate an understanding of and apply current theories, models, and techniques that
CO4
provide a basis for the software lifecycle.
CO5 Demonstrate an ability to use the techniques and tools necessary for engineering practice.

Contents 52 Hrs
OVERVIEW: Introduction; Software engineering ethics; Software process models;
Process activities; Coping with change; Agile software development: Agile methods; Plan- 10
driven and agile development.
REQUIREMENTS ENGINEERING: Functional and non-functional requirements;
Software requirements document; Requirement’s specification; Requirements engineering 10
processes; Requirement’s elicitation and analysis; Requirement’s validation;
Requirements management.
SYSTEM MODELING: Context models; Interaction models- Use case modeling,
Sequence diagrams; Structural models- Class diagrams, Generalization, Aggregation; 10
Behavioral models- Data-driven modeling, Event-driven modeling; Model-driven
engineering.
ARCHITECTURAL DESIGN: Architectural design decisions; Architectural views;
Architectural patterns- Layered architecture, Repository architecture, Client–server
architecture Pipe and filter architecture. 12
DESIGN AND IMPLEMENTATION: Object-oriented design using the UML- System
context and interactions, Architectural design, Object class identification, Design models,
Interface specification; Design patterns; Implementation issues.
SOFTWARE TESTING: Development testing- Unit testing, Choosing unit test cases,
Component testing, System testing. Test-driven development; Release testing; User 10
testing- Alpha, Beta, Acceptance testing.

Page 10 of 30
 Software Engineering
Unit 1

What is software?
• Computer programs and associated documentation such as requirements, design
models and user manuals.
• Software products may be developed for a particular customer or may be developed
for a general market.

Types of Software products

1. Generic Software – developed to be sold to a range of different customers
e.g. PC software such as Excel or Word.
2. Bespoke Software (custom) - developed for a single customer according to their specification.
New software can be created by developing new programs, configuring generic software systems or
reusing existing software.

What is software engineering?

Software engineering is an engineering discipline that is concerned with all aspects of software
production. So as to develop the software with the highest quality. Software engineers should adopt
a systematic and organised approach to their work and use appropriate tools and techniques
depending on the problem to be solved, the development constraints and the resources available.

What is the difference between software engineering and computer science?

Computer science is concerned with theory and fundamentals; software engineering is concerned
with the practicalities of developing and delivering useful software.

What is the difference between software engineering and system engineering?

System engineering is concerned with all aspects of computer-based systems development including
hardware, software and process engineering. Software engineering is part of this process concerned
with developing the software infrastructure, control, applications and databases in the system.

NEED OF SOFTWARE ENGINEERING

The need of software engineering arises because of higher rate of change in user requirements and
environment on which the software is working.
Large software - It is easier to build a wall than to a house or building, likewise, as the size of
software become large engineering has to step to give it a scientific process.
Scalability- If the software process were not based on scientific and engineering concepts, it would
be easier to re-create new software than to scale an existing one.
Cost- As hardware industry has shown its skills and huge manufacturing has lower down the price of
computer and electronic hardware. But the cost of software remains high if proper process is not
adapted.
Dynamic Nature- The always growing and adapting nature of software hugely depends upon the
environment in which the user works. If the nature of software is always changing, new
enhancements need to be done in the existing one. This is where software engineering plays a good
role.
Quality Management- Better process of software development provides better and quality software
product.

What is a software process?

A set of activities whose goal is the development or evolution of software.
Generic activities in all software processes are:
• Specification - what the system should do and its development constraints
• Development - production of the software system
• Validation - checking that the software is what the customer wants
• Evolution - changing the software in response to changing demands.
What is a software process model?
A simplified representation of a software process, presented from a specific perspective.
Generic process models
• Waterfall;
• Iterative development;
• Component-based software engineering.

What are the costs of software engineering?

Roughly 60% of costs are development costs, 40% are testing costs. For custom software, evolution
costs often exceed development costs.
Costs vary depending on the type of system being developed and the requirements of system
attributes such as performance and system reliability.

What are software engineering methods?

Structured approaches to software development which include system models, notations, rules,
design advice and process guidance.
Model descriptions -Descriptions of graphical models which should be produced;
Rules- Constraints applied to system models;
Recommendations- Advice on good design practice;
Process guidance-What activities to follow.

What is CASE?
Computer-Aided Software Engineering. CASE tools are software systems which are designed to
support routine activities in the software process such as editing design diagrams, checking diagram
consistency and keeping track of program tests which have been run.

What are the attributes of good software?

The software should deliver the required functionality and performance to the user and should be
maintainable, dependable and acceptable.
• Maintainability-Software must evolve to meet changing needs;
• Dependability- Software must be trustworthy;
• Efficiency-Software should not make wasteful use of system resources;
• Acceptability- Software must accepted by the users for which it was designed. This means it
must be understandable, usable and compatible with other systems.

What are the key challenges facing software engineering?

Heterogeneity- Developing techniques for building software that can cope with heterogeneous
platforms and execution environments;
Delivery- Developing techniques that lead to faster delivery of software;
Trust- Developing techniques that demonstrate that software can be trusted by its users.
Professional and ethical responsibility
• 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.
• 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 outwith 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 computers. Computer misuse ranges from relatively trivial (game
playing on an employer’s machine, say) to extremely serious (dissemination of
viruses).
Software Process Generic Activities
• Communication
– Involves communication among the customer and other stake holders; encompasses
requirements gathering
• Planning
– Establishes a plan for software engineering work; addresses technical tasks, resources,
work products, and work schedule
• Modeling (Analyze, Design)
– Encompasses the creation of models to better understand the requirements and the
design
• Construction (Code, Test)
– Combines code generation and testing to uncover errors
• Deployment
– Involves delivery of software to the customer for evaluation and feedback

Umbrella Activities Involved in Software Development

• Software requirements management
• Software project planning
• Software project tracking and oversight
• Software quality assurance
• Software configuration management
• Software subcontract management
• Formal technical reviews
• Risk management
• Measurement – process, project, product
• Reusability management (component reuse)
• Work product preparation and production
 Software Development Life Cycle (SDLC)
Software Development Life Cycle (SDLC) is a process used by the software industry to design,
develop and test high quality softwares. The SDLC aims to produce a high-quality software that meets
or exceeds customer expectations, reaches completion within times and cost estimates.
• SDLC is the acronym of Software Development Life Cycle.
• It is also called as Software Development Process.
• SDLC is a framework defining tasks performed at each step in the software development
process.
• ISO/IEC 12207 is an international standard for software life-cycle processes. It aims to be the
standard that defines all the tasks required for developing and maintaining software.

SDLC is a process followed for a software project, within a software organization. It consists of a
detailed plan describing how to develop, maintain, replace and alter or enhance specific software. The
life cycle defines a methodology for improving the quality of software and the overall development
process.
Graphical representation of the various stages of a typical SDLC.
A typical Software Development Life Cycle consists of the following stages −
Stage 1: Planning and Requirement Analysis
Requirement analysis is the most important and fundamental stage in SDLC. It is performed by the
senior members of the team with inputs from the customer, the sales department, market surveys and
domain experts in the industry. This information is then used to plan the basic project approach and to
conduct product feasibility study in the economical, operational and technical areas.Planning for the
quality assurance requirements and identification of the risks associated with the project is also done in
the planning stage.

Stage 2: Defining Requirements

Once the requirement analysis is done the next step is to clearly define and document the product
requirements and get them approved from the customer or the market analysts. This is done through an
SRS (Software Requirement Specification) document which consists of all the product requirements
to be designed and developed during the project life cycle.

Stage 3: Designing the Product Architecture

SRS is the reference for product architects to come out with the best architecture for the product to be
developed. Based on the requirements specified in SRS, usually more than one design approach for the
product architecture is proposed and documented in a DDS - Design Document Specification.
This DDS is reviewed by all the important stakeholders and based on various parameters as risk
assessment, product robustness, design modularity, budget and time constraints, the best design
approach is selected for the product.
A design approach clearly defines all the architectural modules of the product along with its
communication and data flow representation with the external and third party module

Stage 4: Building or Developing the Product

In this stage of SDLC the actual development starts and the product is built. The programming code is
generated as per DDS during this stage. If the design is performed in a detailed and organized manner,
code generation can be accomplished without much hassle.
Developers must follow the coding guidelines defined by their organization and programming tools
like compilers, interpreters, debuggers, etc. are used to generate the code. Different high level
programming languages such as C, C++, Pascal, Java and PHP are used for coding. The programming
language is chosen with respect to the type of software being developed.

Stage 5: Testing the Product

This stage is usually a subset of all the stages as in the modern SDLC models, the testing activities are
mostly involved in all the stages of SDLC. However, this stage refers to the testing only stage of the
product where product defects are reported, tracked, fixed and retested, until the product reaches the
quality standards defined in the SRS.

Stage 6: Deployment in the Market and Maintenance

Once the product is tested and ready to be deployed it is released formally in the appropriate market.
Sometimes product deployment happens in stages as per the business strategy of that organization. The
product may first be released in a limited segment and tested in the real business environment (UAT-
User acceptance testing).
Then based on the feedback, the product may be released as it is or with suggested enhancements in the
targeting market segment. After the product is released in the market, its maintenance is done for the
existing customer base.
 The waterfall Model
This model is illustrated in Figure . Because of the cascade from one phase to another, this model is
known as the ‘waterfall model’ or software life cycle. The waterfall model is an example ofa plan-
driven process—in principle, you must plan and schedule all of the process activities before starting
work on them.
The principal stages of the waterfall model directly reflect the fundamental development activities:
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:Normally (although not necessarily), this is the longest life cycle phase.
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 – Advantages

The advantages of waterfall development are that it allows for departmentalization and control. A
schedule can be set with deadlines for each stage of development and a product can proceed through
the development process model phases one by one.
Development moves from concept, through design, implementation, testing, installation,
troubleshooting, and ends up at operation and maintenance. Each phase of development proceeds in
strict order.
Some of the major advantages of the Waterfall Model are as follows –
• Simple and easy to understand and use
• Easy to manage due to the rigidity of the model. Each phase has specific deliverables and a
review process.
• Phases are processed and completed one at a time.
• Works well for smaller projects where requirements are very well understood.
• Clearly defined stages.
• Well understood milestones.
• Easy to arrange tasks.
• Process and results are well documented

Disadvantages of waterfall model

• In principle, the result of each phase is one or more documents that are approved (‘signed off’).
The following phase should not start until the previous phase has finished. In practice, these stages
overlap and feed information to each other.
• The software process is not a simple linear model but involves feedback from one phase to
another. Documents produced in each phase may then have to be modified to reflect the changes
made.
• Because of the costs of producing and approving documents, iterations can be costly and
involve significant rework. Therefore, after a small number of iterations, it is normal to freeze parts of
the development, such as the specification, and to continue with the later development stages. This
premature freezing of requirements may mean that the system won’t do what the user wants.
• During the final life cycle phase (operation and maintenance) the software is put into use.
Errors and omissions in the original software requirements are discovered. Program and design errors
emerge and the need for new functionality is identified. Making these changes (software maintenance)
may involve repeating previous process stages.
• Its major problem is the inflexible partitioning of the project into distinct stages. Commitments
must be made at an early stage in the process, which makes it difficult to respond to changing
customer requirements.

In principle, the waterfall model should only be used when the requirements are well understood and
unlikely to change radically during system development.

Incremental Model

Incremental Model is a process of software development where requirements divided into multiple
standalone modules of the software development cycle. In this model, each module goes through the
requirements, design, implementation and testing phases. Every subsequent release of the module
adds function to the previous release. The process continues until the complete system achieved.
The various phases of incremental model are as follows:
1. Requirement analysis: In the first phase of the incremental model, the product analysis expertise
identifies the requirements. And the system functional requirements are understood by the
requirement analysis team. To develop the software under the incremental model, this phase performs
a crucial role.

2. Design & Development: In this phase of the Incremental model of SDLC, the design of the
system functionality and the development method are finished with success. When software develops
new practicality, the incremental model uses style and development phase.

3. Testing: In the incremental model, the testing phase checks the performance of each existing
function as well as additional functionality. In the testing phase, the various methods are used to test
the behavior of each task.

4. Implementation: Implementation phase enables the coding phase of the development system. It
involves the final coding that design in the designing and development phase and tests the
functionality in the testing phase. After completion of this phase, the number of the product working
is enhanced and upgraded up to the final system product

When we use the Incremental Model?

o When the requirements are superior.

o A project has a lengthy development schedule.

o When Software team are not very well skilled or trained.

o When the customer demands a quick release of the product.

o You can develop prioritized requirements first.

Advantage of Incremental Model

o Errors are easy to be recognized.

o Easier to test and debug

o More flexible.

o Simple to manage risk because it handled during its iteration.

o The Client gets important functionality early.

Disadvantage of Incremental Model

o Need for good planning

o Total Cost is high.

o Well defined module interfaces are needed.

Prototype Model

The prototype model requires that before carrying out the development of actual software, a working
prototype of the system should be built. A prototype is a toy implementation of the system. A
prototype usually turns out to be a very crude version of the actual system, possible exhibiting limited
functional capabilities, low reliability, and inefficient performance as compared to actual software. In
many instances, the client only has a general view of what is expected from the software product. In
such a scenario where there is an absence of detailed information regarding the input to the system,
the processing needs, and the output requirement, the prototyping model may be employed.
Steps of Prototype Model

1. Requirement Gathering and Analyst

2. Quick Decision

3. Build a Prototype

4. Assessment or User Evaluation

5. Prototype Refinement
6. Engineer Product

Advantage of Prototype Model

1. Reduce the risk of incorrect user requirement

2. Good where requirement are changing/uncommitted

3. Regular visible process aids management

4. Support early product marketing

5. Reduce Maintenance cost.
6. Errors can be detected much earlier as the system is made side by side.
Disadvantage of Prototype Model

1. An unstable/badly implemented prototype often becomes the final product.

2. Require extensive customer collaboration
o Costs customer money

o Needs committed customer

o Difficult to finish if customer withdraw

o May be too customer specific, no broad market

3. Difficult to know how long the project will last.

4. Easy to fall back into the code and fix without proper requirement analysis, design, customer
evaluation, and feedback.
 5. Prototyping tools are expensive.

6. Special tools & techniques are required to build a prototype.

7. It is a time-consuming process.

Spiral Model
The spiral model, initially proposed by Boehm, is an evolutionary software process model that couples
the iterative feature of prototyping with the controlled and systematic aspects of the linear sequential
model. It implements the potential for rapid development of new versions of the software. Using the
spiral model, the software is developed in a series of incremental releases. During the early iterations,
the additional release may be a paper model or prototype. During later iterations, more and more
complete versions of the engineered system are produced
When to use Spiral Model?
 When deliverance is required to be frequent.

 When the project is large

 When requirements are unclear and complex

 When changes may require at any time

 Large and high budget projects

Each cycle in the spiral is divided into four parts:
• • Objective setting: Each cycle in the spiral starts with the identification of purpose for that
cycle, the various alternatives that are possible for achieving the targets, and the constraints that exists.
• • Risk Assessment and reduction: The next phase in the cycle is to calculate these various
alternatives based on the goals and constraints. The focus of evaluation in this stage is located on the
risk perception for the project.
• • Development and validation: The next phase is to develop strategies that resolve
uncertainties and risks. This process may include activities such as benchmarking, simulation, and
prototyping.
• • Planning: Finally, the next step is planned. The project is reviewed, and a choice made
whether to continue with a further period of the spiral. If it is determined to keep, plans are drawn up
for the next step of the project.

The development phase depends on the remaining risks. For example, if performance or user-interface
risks are treated more essential than the program development risks, the next phase may be an
evolutionary development that includes developing a more detailed prototype for solving the risks.
The risk-driven feature of the spiral model allows it to accommodate any mixture of a specification-
oriented, prototype-oriented, simulation-oriented, or another type of approach. An essential element of
the model is that each period of the spiral is completed by a review that includes all the products
developed during that cycle, including plans for the next cycle. The spiral model works for
development as well as enhancement projects.
Advantages
• High amount of risk analysis
• Useful for large and mission-critical projects.

Disadvantages
• Can be a costly model to use.
• Risk analysis needed highly particular expertise
• Doesn't work well for smaller projects.

RAD Model:
The Rapid Application Development Model was first proposed by IBM in the 1980s. The RAD
model is a type of incremental process model in which there is extremely short development cycle.
When the requirements are fully understood and the component-based construction approach is
adopted then the RAD model is used. Various phases in RAD are Requirements Gathering, Analysis
and Planning, Design, Build or Construction, and finally Deployment.
1. Requirements Planning – It involves the use of various techniques used in requirements
elicitation like brainstorming, task analysis, form analysis, user scenarios, FAST (Facilitated
Application Development Technique), etc. It also consists of the entire structured plan describing
the critical data, methods to obtain it, and then processing it to form a final refined model.

2. User Description – This phase consists of taking user feedback and building the prototype using
developer tools. In other words, it includes re-examination and validation of the data collected in
the first phase. The dataset attributes are also identified and elucidated in this phase.

3. Construction – In this phase, refinement of the prototype and delivery takes place. It includes
the actual use of powerful automated tools to transform processes and data models into the final
working product. All the required modifications and enhancements are too done in this phase.

4. Cutover – All the interfaces between the independent modules developed by separate teams
have to be tested properly. The use of powerfully automated tools and subparts makes testing
easier. This is followed by acceptance testing by the user.
When to use RAD Model?

When the customer has well-known requirements, the user is involved throughout the life cycle, the
project can be time-boxed, the functionality delivered in increments, high performance is not required,
low technical risks are involved and the system can be modularized.

Advantages:

 The use of reusable components helps to reduce the cycle time of the project.
 Feedback from the customer is available at the initial stages.
 Reduced costs as fewer developers are required.
 The use of powerful development tools results in better quality products in comparatively shorter
time spans.
 The progress and development of the project can be measured through the various stages.
 It is easier to accommodate changing requirements due to the short iteration time spans.
 Productivity may be quickly boosted with a lower number of employees.

Disadvantages:

 The use of powerful and efficient tools requires highly skilled professionals.
 The absence of reusable components can lead to the failure of the project.
 The team leader must work closely with the developers and customers to close the project on time.
 The systems which cannot be modularized suitably cannot use this model.
 Customer involvement is required throughout the life cycle.
 It is not meant for small-scale projects as in such cases, the cost of using automated tools and
techniques may exceed the entire budget of the project.
 Not every application can be used with RAD.

Coping with Change

Change is inevitable in all large software projects. The system requirements change as businesses
respond to external pressures, competition, and changed management priorities. As new technologies
become available, new approaches to design and implementation become possible. Therefore whatever
software process model is used, it is essential that it can accommodate changes to the software being
developed.
Change adds to the costs of software development because it usually means that work that has been
completed has to be redone. This is called rework. For example, if the relationships between the
requirements in a system have been analyzed and new requirements are then identified, some or all of
the requirements analysis has to be repeated. It may then be necessary to redesign the system to deliver
the new requirements, change any programs that have been developed, and retest the system.
Two related approaches may be used to reduce the costs of rework:
1. Change anticipation, where the software process includes activities that can anticipate or predict
possible changes before significant rework is required. For example, a prototype system may be
developed to show some key features of the system to customers. They can experiment with the
prototype and refine their requirements before committing to high software production costs.
2. Change tolerance, where the process and software are designed so that changes can be easily made
to the system. This normally involves some form of incremental development. Proposed changes may
be implemented in increments that have not yet been developed. If this is impossible, then only a
single increment (a small part of the system) may have to be altered to incorporate the change.

In this section, we discuss two ways of coping with change and changing system requirements:
1. System prototyping, where a version of the system or part of the system is developed quickly to
check the customer’s requirements and the feasibility of design decisions. This is a method of change
anticipation as it allows users to experiment with the system before delivery and so refine their
requirements. The number of requirements change proposals made after delivery is therefore likely to
be reduced.

2. Incremental delivery, where system increments are delivered to the customer for comment and
experimentation. This supports both change avoidance and change tolerance. It avoids the premature
commitment to requirements for the whole system and allows changes to be incorporated into later
increments at relatively low cost.

Agile Software Development

Agile Software Development is a software development methodology that values flexibility,
collaboration, and customer satisfaction. It is based on the Agile Manifesto, a set of principles for
software development that prioritize individuals and interactions, working software, customer
collaboration, and responding to change.
Agile Software Development is an iterative and incremental approach to software development that
emphasizes the importance of delivering a working product quickly and frequently. It involves close
collaboration between the development team and the customer to ensure that the product meets their
needs and expectations.
The Agile Software Development process typically consists of the following steps:
1. Requirements Gathering: The customer’s requirements for the software are gathered and
prioritized.
2. Planning: The development team creates a plan for delivering the software, including the features
that will be delivered in each iteration.
3. Development: The development team works to build the software, using frequent and rapid
iterations.
4. Testing: The software is thoroughly tested to ensure that it meets the customer’s requirements and
is of high quality.
5. Deployment: The software is deployed and put into use.
6. Maintenance: The software is maintained to ensure that it continues to meet the customer’s needs
and expectations.

Agile Software Development is widely used by software development teams and is considered to be a
flexible and adaptable approach to software development that is well-suited to changing requirements
and the fast pace of software development.
Agile is a time-bound, iterative approach to software delivery that builds software incrementally from
the start of the project, instead of trying to deliver all at once.
Why Agile? Technology in this current era is progressing faster than ever, enforcing global software
companies to work in a fast-paced changing environment. Because these businesses are operating in an
ever-changing environment, it is impossible to gather a complete and exhaustive set of software
requirements. Without these requirements, it becomes practically hard for any conventional software
model to work. The conventional software models such as Waterfall Model that depends on completely
specifying the requirements, designing, and testing the system are not geared towards rapid software
development. As a consequence, a conventional software development model fails to deliver the
required product. This is where agile software development comes to the rescue. It was specially
designed to curate the needs of the rapidly changing environment by embracing the idea of incremental
development and developing the actual final product. Let’s now read about the on which the Agile has
laid its foundation:

Principles:
1. Highest priority is to satisfy the customer through early and continuous delivery of valuable
software.
2. It welcomes changing requirements, even late in development.
3. Deliver working software frequently, from a couple of weeks to a couple of months, with a
preference to the shortest timescale.
4. Build projects around motivated individuals. Give them the environment and the support they need,
and trust them to get the job done.
5. Working software is the primary measure of progress.
6. Simplicity the art of maximizing the amount of work not done is essential.
7. The most efficient and effective method of conveying information to and within a development
team is face-to-face conversation.

Agile is a framework that defines how software development needs to be carried on. Agile is not a
single method, it represents the various collection of methods and practices that follow the value
statements provided in the manifesto. Agile methods and practices do not promise to solve every
problem present in the software industry (No Software model ever can). But they sure help to establish
a culture and environment where solutions emerge. Agile software development is an iterative and
incremental approach to software development. It emphasizes collaboration between the development
team and the customer, flexibility and adaptability in the face of changing requirements, and the
delivery of working software in short iterations. The Agile Manifesto, which outlines the principles of
agile development, values individuals and interactions, working software, customer collaboration, and
response to change. Agile development typically involves the following practices:

4 Important Types Of Agile Methodology

1. Scrum
Scrum is the most popular Agile framework, defined by the Scrum Guide in 2010. According to the
15th State of Agile report, 66% of respondents identified Scrum as one of the Agile frameworks they
follow most closely.
What are the main characteristics of a Scrum team?
• Scrum teams work in short iterations called Sprints, with 2 weeks being the most popular choice.
Each Sprint has its goal.
• Scrum clearly defines the team roles like Scrum Master, Product Owner, and Development Team.
• Scrum teams attend regular Agile events, like Sprint Planning, Daily Scrum, Sprint Review, and
Sprint Retrospective.
Scrum works well in companies with frequent cross-team collaboration. It fits small teams, 3 to 9
people maximum. It’s a good choice for teams that work in short development cycles focused on
timely releases.
The Scrum framework is also great for “newbies” in Agile because it provides clear guidelines. It’s
one of the best-defined Agile frameworks: a good choice to start your Agile journey.

2. Kanban
Kanban is roughly translated from Japanese and means “cards you can see.” In Kanban, the progress
of the development process is visualized on a Kanban board.
What are the main characteristics of a Kanban team?
• Kanban teams work with a Kanban board. Typically the Kanban board includes the “To Do,” “In
Progress,” and “Done” columns. In software development, the Kanban board is usually extended to:
“To Do,” “Dev,” “Test,” and “Done.”
• Kanban teams work with “Work in Progress” limits to prevent bottlenecks and achieve quicker
release cycles.
• Kanban is a continuous workflow. Product improvements happen on an ongoing basis through
continuous collaboration and ad-hoc team meetings.

Which teams would benefit the most from Kanban?

Kanban is the way to go for teams that handle different-size tasks and need to juggle frequently
changing product requirements. Kanban methodology is not as clearly defined as Scrum, so it
wouldn’t be advised to inexperienced Agile teams.
The Kanban concept is usually recommended to smaller teams that work on repetitive tasks and are
not heavily dependent on others. Kanban is a great choice if your team prioritizes the speed to market
and is more advanced in Agile methods.

3. Scrumban
Scrumban is a Scrum Kanban hybrid, taking some of the principles from Scrum and some of the
principles from Kanban.
What are the main characteristics of the Scrumban team?
• Scrumban teams work on a time-based schedule. Instead of 2-week Sprints, they work with 3-month,
6-month, and 1-year buckets.
• Agile events are not a must in Scrumban. The team can choose to skip certain events, however, retro
sessions and ad-hoc planning are definitely recommended.
• Scrumban teams visualize their tasks on a Scrumban board with applied ‘Work In Progress’ limits.

Which teams would benefit the most from Scrumban?

Scrumban is a great choice for either small or large teams that are experienced or just starting with
Agile. It’s a good fit for those who find Scrum too rigid and think that Scrum rules are hindering the
team’s productivity.
Scrumban works well with teams that are developing multiple products in fast-paced environments
and have less strict estimation requirements from the senior management.
4.Crystal
Crystal methodology is made up of smaller Agile project management methodologies that were first
introduced by Dr. Alistair Cockburn, co-author of the Agile Manifesto, and place the main focus on
collaboration practices.

What are the main characteristics of the teams following the Crystal approach?
• Teams following the Crystal approach work with smaller Agile development methodologies like
Crystal Clear, Crystal Yellow, Crystal Orange, Crystal Orange Web, Crystal Red, Crystal Maroon,
Crystal Diamond, and Crystal Sapphire.
• The Crystal approach is very flexible and adaptable, and it works well for different types of Agile
teams.
• Crystal teams avoid unnecessary documentation and reporting and practice one of the lightweight
Agile software development methodologies.

Which teams would benefit the most from Crystal methodology?

Different team sizes can benefit from the Crystal project management process. For example, Crystal
Clear fits smaller teams and shorter projects (up to 6 developers), and Crystal Red works better with
larger teams (up to 80 team members).
The Crystal approach is a good choice for teams that communicate frequently and cooperate without
the day-to-day involvement from the higher management.
Crystal methodologies are not recommended to inexperienced Agile teams as the structure is not
clearly defined, and there are some grey areas open to interpretations.

Agile development has several advantages over traditional software development approaches,
including:
1. Increased customer satisfaction: Agile development involves close collaboration with the
customer, which helps to ensure that the software meets their needs and expectations.
2. Faster time-to-market: Agile development emphasizes the delivery of working software in short
iterations, which helps to get the software to market faster.
3. Reduced risk: Agile development involves frequent testing and feedback, which helps to identify
and resolve issues early in the development process.
4. Improved team collaboration: Agile development emphasizes collaboration and communication
between team members, which helps to improve productivity and morale.
5. Adaptability to change: Agile Development is designed to be flexible and adaptable, which means
that changes to the project scope, requirements, and timeline can be accommodated easily. This can
help the team to respond quickly to changing business needs and market demands.
6. Better quality software: Agile Development emphasizes continuous testing and feedback, which
helps to identify and resolve issues early in the development process. This can lead to higher quality
software that is more reliable and less prone to errors.
7. Increased transparency: Agile Development involves frequent communication and collaboration
between the team and the customer, which helps to improve transparency and visibility into the project
status and progress. This can help to build trust and confidence with the customer and other
stakeholders.
8. Higher productivity: Agile Development emphasizes teamwork and collaboration, which helps to
improve productivity and reduce waste. This can lead to faster delivery of working software with
fewer defects and rework.
9. Improved project control: Agile Development emphasizes continuous monitoring and
measurement of project metrics, which helps to improve project control and decision-making. This can
help the team to stay on track and make data-driven decisions throughout the development process.

Plan-driven development
A plan-driven development is a process where all the activities are planned in advance, and we
measure the progress in advance against that plan. So as it appears from the term ‘plan-driven
development, it is always planned, and the results are to be shown at the end of the product.
It is a software development method. When a user wants to develop all the features that should be
developed in a final product, this plan plays its role. It also determines how all those features should be
developed.
So, you can say that this is an ACTION plan based on executing an arranged set of task-specified
levels.It is basically an attitude to software engineering where it locates how the developmental
procedure will occur. This process handles mega project engineering and administers the old style of
methodology to tackle the software development ventures

Characteristics of Plan Driven Development

• You can focus on the repeatability and predictability
• It is defined, as an incremental improving process, and a standardized way
• It is done through a proper documentation process
• There is a software system architecture that has been defined up-front
• You can find detailed plans, roles, work-product descriptions, workflow, and responsibilities
• It contains resources for specialists: process monitoring, controlling, and educating
• It Focuses on verification and validation

Agile Software Development:

While Agile development, planning is always incremental, where you can change the plan according
to your customer requirements. So, as the term ‘agile development’ suggests, it is the process-based
method where one can alter the way things and planning and replace them with the more suitable ones.
software development methodologies centers around the iterative developmental idea, in which needs
and solutions revolve through an alliance between self-organizing cross-functional teams. It is also
crucial to note that agile development enables teams to deliver value faster with excellent quality,
prediction, and aptitude to respond to change. There are two most widely used methods called Scrum
and Kanban.
Difference b/w Agile and Plan Driven Model
 UNIT - 2
REQUIREMENT ENGINEERING
REQUIREMENTS ENGINEERING: Functional and non-functional requirements; Software
requirements document; Requirement’s specification; Requirements engineering processes;
Requirement’s elicitation and analysis; Requirement’s validation; Requirements management

Requirement Engineering

Before we start to develop our software, it becomes quite essential for us to understand and document
the exact requirement of the customer. Experienced members of the development team carry out this
job. They are called as system analysts. The analyst starts requirements gathering and analysis
activity by collecting all information from the customer which could be used to develop the
requirements of the system. He then analyzes the collected information to obtain a clear and thorough
understanding of the product to be developed, with a view to remove all ambiguities and
inconsistencies from the initial customer perception of the problem

What is Requirement and Requirement Engineering?

Requirements specify how the target system should behave. It specifies what to do, but not how to
do. Requirements engineering refers to the process of understanding what a customer expects from
the system to be developed, and to document them in a standard and easily readable and
understandable format. This documentation will serve as reference for the subsequent design,
implementation and verification of the system.

Characteristics of Requirements

Requirements gathered for any new system to be developed should exhibit the following three
properties:

Unambiguity: There should not be any confusion what a system to be developed should do. For
example, consider you are developing a web application for your client. The client requires that
enough number of people should be able to access the application simultaneously. What's the "enough
number of people"? That could mean 10 to you, but, perhaps, 100 to the client. There's an ambiguity.

Consistency: The requirements gathered should be consistent. To illustrate this, consider the
automation of a nuclear plant. Suppose one of the clients say that itthe radiation level inside the plant
exceeds R1, all reactors should be shut down. However, another person from the client side suggests
that the threshold radiation level should be R2. Thus, there is an inconsistency between the two end
users regarding what they consider as threshold level of radiation.

Completeness: All the requirements pertaining to a system need to be gathered. A particular

requirement for a system should specify what the system should do and also what it should not. For
example, consider a software to be developed for ATM. If a customer enters an amount greater than
the maximum permissible withdrawal amount, the ATM should display an error message, and it
should not dispense any cash.

24 | P a g e Dept of CS, MIT FGC

Categorization of Requirements: Based on the target audience or subject matter, requirements can
be classified into different types, as stated below:

 User requirements: They are written in natural language so that both customers can verify
their requirements have been correctly identified

Problems with natural language while documenting the user requirements

1. Lack of clarity: Difficult to collect the requirements precisely without any confusions.
2. Requirement confusions: The FR, NFR, Design information many not be clearly
documented.
3. Requirement amalgamation: Different requirements many be expressed together as a single
requirement.
4. System requirements: They are written involving technical terms and/or specifications, and
are meant for the development or testing teams. These are expanded version of the user
requirements. They add detail and explain how the used requirements should be provided by
the system.

Requirements can be classified into two groups based on what they describe:

 Functional requirements (FRs): These describe the functionality of a system -- how a system
should react to a particular set of inputs and what should be the corresponding output.
 Non-functional requirements (NFRs): They are not directly related what functionalities are
expected from the system. However, NFRs could typically define how the system should
behave under certain situations. For example, a NFR could say that the system should work
with 128MB RAM. Under such condition, a NFR could be more critical than a FR.
 Domain requirements (DR): Requirements that come from the application domain of the
system and that reflect characteristics of that domain. Ex. DR for Lib sys: Because of copyright
restrictions, some documents must be deleted immediately on arrival.

Functional Requirements

Identifying Functional Requirements

Given a problem statement, the functional requirements could be identified by focusing on the
following points:

 Identify the high level functional requirements simply from the conceptual understanding of
the problem. For example, a Library Management System, apart from anything else, should be
able to issue and return books.
 Identify the cases where an end user gets some meaningful work done by using the system.
For example, in a digital library a user might use the "Search Book" functionality to obtain
information about the books of his interest.
 If we consider the system as a black box, there would be some inputs to it, and some output in
return. This black box defines the functionalities of the system. For

25 | P a g e Dept of CS, MIT FGC

  example, to search for a book, user gives title of the book as input and get the book details and
location as the output.
 Any high level requirement identified could have different sub-requirements. For example,
"Issue Book" module could behave differently for different class of users, or for a particular
user who has issued the book thrice consecutively.

Non - functional requirements could be further classified into different types like:

 Product Requirements
Example: A specification that the web application should use only plain HTML, and no frames
 Performance Requirements
Example: The system should remain available 24x7
 Organizational Requirements
The development process should comply to SEI CMM level 4

Types of NFR

Metrics for Specifying the NFR: Requirements Measures

Requirements measures

Property Measure
Speed Processed transaction/second
User/Event response time
Screen refresh time
Size k bytes Number of RAM chips
Ease of use Training time Number of help frames

Reliability Mean time to failure

Probability of unavailability

26 | P a g e Dept of CS, MIT FGC

 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

Notations for Requirements Specifications

 Structured Natural Language: This approach depends on defining standard forms or

templates to express the requirements specification.
 Design Description Languages: This approach uses a language like a programming language
but with more abstract features to specify the requirements by defining an operational model
of the system. This approach is not now widely used although it can be useful for interface
specifications.
 Graphical Notations : A graphical language, supplemented by text annotations is used to
define the functional requirements for the system. Ex: sequence diagrams
 Mathematical: These are notations based on mathematical concepts such as finite-state
machines or sets. These unambiguous specifications reduce the arguments between customer
and contractor about system functionality. However, most customers don't understand formal
specifications and are reluctant to accept it as a system contract.

Example of FR and NFR for library software:

FR

R1 New user registration High

R2 User Login High
R3 Search book High
R4 Issue book High
R5 Return book High
R6 Reissue book Low

NFR:
Performance Requirements:
 This system should remain accessible 24x7
 At least 50 users should be able to access the system altogether at any given time
Security Requirements:
 This system should be accessible only within the institute LAN

27 | P a g e Dept of CS, MIT FGC

  The database of LIS should not store any password in plain text -- a hashed value has to be
stored
Software Quality Attributes
Database Requirements
Design Constraints:
 The LIS has to be developed as a web application, which should work with Firefox 5, Internet
Explorer 8, Google Chrome 12, Opera 10
 The system should be developed using HTML 5
 Once all the functional and non-functional requirements have been identified, they are
documented formally in SRS, which then serves as a legal agreement.

Functional Requirements Non – Functional Requirements

Functional requirements help to understand They help to understand the system's
the functions of the system. performance.
While non-functional requirements are not
Functional requirements are mandatory.
mandatory.
They are easy to define. They are hard to define.

They describe what the product does. They describe the working of product.

It concentrates on the expectation and

It concentrates on the user's requirement.
experience of the user.
It helps us to verify the software's
It helps us to verify the software's performance.
functionality.
These requirements are specified by the
These requirements are specified by the user. software developers, architects, and technical
persons.

There is functional testing such as API There is non-functional testing such as usability,
testing, system, integration, etc. performance, stress, security, etc.

Examples of the functional requirements are- Examples of the non-functional requirements

Authentication of a user on trying to log in to are The background color of the screens should
the system. be light blue.
These requirements are important to system These are not always the important
operation requirements, they may be desirable.
Completion of Functional requirements
While system will not work only with non-
allows the system to perform, irrespective of
functional requirements.
meeting the non- functional requirements.

28 | P a g e Dept of CS, MIT FGC

The Software Requirements Specifications Document:
Once all possible functional and non-functional requirements have been identified, which are
complete, consistent, and non-ambiguous, the Software Requirements Specification (SRS) is to be
prepared. The requirement document has a diverse set of users such as customers, managers, system
engineers, test engineers and maintenance engineers. The SRS is prepared by the service provider,
and verified by its client. This document serves as a legal agreement between the client and the service
provider. Once the concerned system has been developed and deployed, and a proposed feature was
not found to be present in the system, the client can point this out from the SRS. Also, if after delivery,
the client says a new feature is required, which was not mentioned in the SRS, the service provider
can again point to the SRS. The scope of the current experiment, however, doesn't cover writing a
SRS. IEEE format is most widely used format for preparing the SRS document.
Structure of SRS Document:
The IEEE standard suggests the following structure:
1. Table of contents
2. Preface
3. Introduction
4. Glossary
5. User requirements definition
6. System architecture
7. System requirements specification
8. System models
9. System evolution
10. Appendices
11. Index
A general structure of an SRS will be as follows:

1. Introduction:
This provides an overview of the entire information described in SRS. This involves purpose
and the scope of SRS, which states the functions to be performed by the system. In addition, it
describes definitions, abbreviations, and the acronyms used. The references used in SRS
provide a list of documents that is referenced in the document.

2. Overall Description: Describe the general factors that affect the product and its requirements.
It should also be made clear that this section does not state specific requirements, it only makes
those requirements easier to understand.
It comprises the following sub-sections.

29 | P a g e Dept of CS, MIT FGC

 1. Product Perspective: It determines whether the product is an independent product or an
integral part of the larger product. It determines the interface with hardware, software, system,
and communication. It also defines memory constraints and operations utilized by the user.
2. Product Functions: Provide a summary of the functions that the software will perform.
3. User Characteristics: Describe general characteristics of the users.
4. General Constraints: It provides the general description of the constraints such as regulatory
policies, audit functions, reliability requirements, and so on.
5. Assumptions and Dependencies: List each of the factors that affect the requirements stated
in the SRS. These factors are not design constraints on the software but are, rather, any changes
to them that can affect the requirements in the SRS. For example, an assumption might be that
a specific operating system will be available on the hardware designated for the software
product. If, in fact, the operating system is not available, the SRS would then have to change
accordingly.

3. Specific Requirements:
Give the detailed requirements that are used to guide the project’s software design, implementation,
and testing. Each requirement in this section should be correct, unambiguous, verifiable, prioritized,
complete, consistent, and uniquely identifiable. Attention should be paid to the carefully organize the
requirements presented in this section so that they may easily accessed and understood. Furthermore,
this SRS is not the software design document, therefore one should avoid the tendency to over-
constrain (and therefore design) the software project within this SRS.

1. External Interface Requirements: Include user, hardware, software, and communication

interfaces.
2. Functional Requirements: Describes specific features of the software project. If desired,
some requirements may be specified in the use-case format and listed in the Use Cases Section.
3. Use Cases: Describe all applicable use cases in the system.
4. Classes and Objects: Describe all classes by expressing its functions and attributes in the
system.
5. Non-Functional Requirements: Requirements may exist for performance, reliability,
availability, security, maintainability and portability. For example (95% of transaction shall be
processed in less than a second, system downtime may not exceed 1 minute per day, > 30 day
MTBF value, etc).
6. Design Constraints: Specify design constrains imposed by other standards, company policies,
hardware limitation, etc. that will impact this software project.
7. Other Requirements: Catchall section for any additional requirements.

4. Analysis Models: List all analysis models used in developing specific requirements previously
given in this SRS. Each model should include an introduction and a narrative description.
Furthermore, each model should be traceable the SRS’s requirements.
1. Sequence Diagrams: It is a kind of interaction diagram that shows how processes operate with
one another and in what order. It is a construct of a Message Sequence Chart. A sequence
diagram shows object interactions arranged in time sequence. It depicts the objects and classes
involved in the scenario and the sequence of messages exchanged between the objects needed
30 | P a g e Dept of CS, MIT FGC
 to carry out the functionality of the scenario. Sequence diagrams typically are associated with
use case realizations in the Logical View of the system under development.
2. Data Flow Diagrams: It is a graphical representation of the "flow" of data through an
information system, modeling its process aspects. Often they are a preliminary step used to
create an overview of the system which can later be elaborated.
3. State-Transition Diagrams:Describe the system as finite number of states.

5. Change Management Process:

Identify and describe the process that will be used to update the SRS, as needed, when project scope
or requirements change. Who can submit changes and by what means, and how will these changes be
approved.
6. Appendices:
Provide additional (and hopefully helpful) information. If present, the SRS should explicitly state
whether the information contained within an appendix is to be considered as a part of the SRS’s overall
set of requirements. Example Appendices could include (initial) conceptual documents for the
software project, marketing materials, minutes of meetings with the customer(s), etc.

Characteristics of SRS
Software requirements specification should be accurate, complete, efficient, and of high quality, so
that it does not affect the entire project plan. An SRS is said to be of high quality when the developer
and user easily understand the prepared document. Other characteristics of SRS are discussed below.
1. Correct:
SRS is correct when all user requirements are stated in the requirements document. The stated
requirements should be according to the desired system. This implies that each requirement is
examined to ensure that it (SRS) represents user requirements. Note that there is no specified tool or
procedure to assure the correctness of SRS. Correctness ensures that all specified requirements are
performed correctly.
2. Unambiguous:
SRS is unambiguous when every stated requirement has only one interpretation. This implies that
each requirement is uniquely interpreted. In case there is a term used with multiple meanings, the
requirements document should specify the meanings in the SRS so that it is clear and easy to
understand.
3. Complete:
SRS is complete when the requirements clearly define what the software is required to do. This
includes all the requirements related to performance, design and functionality.
4. Ranked for importance/stability:
All requirements are not equally important, hence each requirement is identified to make differences
among other requirements. For this, it is essential to clearly identify each requirement. Stability
implies the probability of changes in the requirement in future.
5. Modifiable:
31 | P a g e Dept of CS, MIT FGC
The requirements of the user can change, hence requirements document should be created in such a
manner that those changes can be modified easily, consistently maintaining the structure and style of
the SRS.
6. Traceable:
SRS is traceable when the source of each requirement is clear and facilitates the reference of each
requirement in future. For this, forward tracing and backward tracing are used. Forward tracing
implies that each requirement should be traceable to design and code elements. Backward tracing
implies defining each requirement explicitly referencing its source.
7. Verifiable:
SRS is verifiable when the specified requirements can be verified with a cost-effective process to
check whether the final software meets those requirements. The requirements are verified with the
help of reviews. Note that unambiguity is essential for verifiability.
8. Consistent:
SRS is consistent when the subsets of individual requirements defined do not conflict with each other.
For example, there can be a case when different requirements can use different terms to refer to the
same object. There can be logical or temporal conflicts between the specified requirements and some
requirements whose logical or temporal characteristics are not satisfied For instance, a requirement
states that an event 'a' is to occur before another event 'b'. But then another set of requirements states
(directly or indirectly by transitivity) that event 'b' should occur before event 'a'.

Requirement Engineering Process:

Goal of requirement engineering process is to create and maintain a system requirements documents.
Processes used to discover, analyze and validate system requirements
The four sub processes in RE process:
 Feasibility Studies- concerned with assessing whether the system is useful to the business.
 Requirements elicitation and analysis- discovering requirements. 
 Requirements Specification- converting the requirements into a standard form.
 Requirements Validation- Checking the requirements with the customers wants.

Fig: the requirement engg process

32 | P a g e Dept of CS, MIT FGC
Spiral model for Requirement Engineering Process:
The Spiral model accommodates approaches to development in which the requirements are developed
to different levels of detail. The no. of iterations around the spiral can vary so the spiral can be exited
when the user requirements are elicitated.

Feasibility studies
A feasibility study decides whether or not the proposed system is worthwhile or doable. The results
of feasibility study should be a report whether or not it is worth carrying on with the requirement
engineering and system development process.

A short focused study that checks:

 If the system contributes to organisational objectives
 If the system can be engineered using current technology and with in budget
 If the system can be integrated with other systems that are used
Feasibility study implementation
Based on information assessment (what is required), information collection and report writing.
Questions for people in the organization:
 What if the system wasn’t implemented?
 What are current process problems?
 How will the proposed system help?
 What will be the integration problems?

33 | P a g e Dept of CS, MIT FGC

  Is new technology needed? What skills?
 What facilities must be supported by the proposed system?
Elicitation and analysis
 Second stage of requirement engineering.
 In this activity, software engineers work with customers, end users to find about the application
domain, services the system should do, performance of system, HW constraints etc.
 Sometimes called requirements elicitation or requirements discovery. 
 May involve end-users, managers, engineers involved in maintenance, domain experts, trade
unions, etc. These are called stakeholders.
Ex: Stake holders for a bank ATM are:

 Bank customers
 Representatives of other banks
 Bank managers
 Counter staff
 Database administrators
 Security managers
 Marketing department
 Hardware and software maintenance engineers
 Banking regulators

Problems of requirements analysis

 Stakeholders don’t know what they really want.

 Stakeholders express requirements in their own terms.
 Different stakeholders may have conflicting requirements.
 Organizational and political factors may influence the system requirements.

The requirements change during the analysis process

34 | P a g e Dept of CS, MIT FGC

Process activities:
 Requirements discovery
 Interacting with stakeholders to discover their requirements. Domain requirements are
also discovered at this stage.
 Requirements classification and organization
 Groups related requirements and organizes them into coherent clusters.
 Prioritization and negotiation
 Prioritizing requirements and resolving requirements conflicts.
 Requirements documentation
 Requirements are documented and input into the next round of the spiral.
Requirements discovery
 The process of gathering information about the proposed and existing systems and distilling
the user and system requirements from this information.
 Sources of information include documentation, system stakeholders and the specifications of
similar systems (templates). These requirement sources can be represented as system
viewpoints, where each viewpoint represent subset of system.
Requirements validation
 Concerned with demonstrating that the requirements define the system that the customer 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 an
implementation error.
During the requirement validation process, checks should be carried out on the requirements
in the requirements documents. These checks include:
 Validity. Does the system provide the functions which best support the customer’s needs?
 Consistency. Are there any requirements conflicts?
 Completeness. Are all functions required by the customer included?
 Realism. Can the requirements be implemented given available budget and technology
 Verifiability. Can the requirements be checked?
Requirements validation techniques
 Requirements reviews
 Systematic manual analysis of the requirements.
 Prototyping

35 | P a g e Dept of CS, MIT FGC

  Using an executable model of the system to check requirements.
 Test-case generation
 Developing tests for requirements to check testability.
Requirements reviews

 Regular reviews should be held while the requirements definition is being formulated.
 Both client and contractor staff should be involved in reviews.
 Reviews may be formal (with completed documents) or informal. Good communications
between developers, customers and users can resolve problems at an early stage.

Review checks

 Verifiability. Is the requirement realistically testable?

 Comprehensibility. Is the requirement properly understood?
 Traceability. Is the origin of the requirement clearly stated?
 Adaptability. Can the requirement be changed without a large impact on other requirements?

Requirements management

The process of managing the changes in system, software and organization environment is called
requirement management.

Requirements are inevitably incomplete and 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.

Requirements evolution

36 | P a g e Dept of CS, MIT FGC

From an evolution perspective, requirements fall into two categories:

 Enduring requirements. Stable requirements derived from the core activity of the customer
organization. E.g. a hospital will always have doctors, nurses, etc. May be derived from domain
models
 Volatile requirements. Requirements which change during development or when the system is
in use. In a hospital, requirements derived from health-care policy.

Requirements management planning

During the requirements engineering process, you have to plan:

 Requirements identification
 How requirements are individually identified;
 A change management process
 The process followed when analysing a requirements change;
 Traceability policies
 The amount of information about requirements relationships that is maintained;
 CASE tool support
 The tool support required to help manage requirements change;

Traceability

 Traceability is concerned with the relationships between requirements, their sources and the
system design
 Source traceability
 Links from requirements to stakeholders who proposed these requirements;
 Requirements traceability
 Links between dependent requirements;
 Design traceability
 Links from the requirements to the design;

Requirements change management

 Should apply to all proposed changes to the requirements .Principal stages to change
management process:
 Problem analysis. Discuss requirements problem and propose change;
 Change analysis and costing. Assess effects of change on other requirements
 Change implementation. Modify requirements document and other documents to reflect
change.

37 | P a g e Dept of CS, MIT FGC

 Unit-3 SYSTEM MODELLING
SYSTEM MODELLING: Context models; Interaction models - Use case Modelling, Sequence
diagrams; Structural models - Class diagrams, Generalization, Aggregation; Behavioral models -
Data-driven Modelling, Event-driven Modelling; Model-driven engineering.

System modelling is the process of developing abstract models of a system, with each model
presenting a different view or perspective of that system. System Modelling has generally come to
mean representing the system using some kind of graphical notation, which is now almost always
based on notations in the Unified Modelling Language (UML).
Models are used during the requirements engineering process to help derive the requirements for a
system, during the design process to describe the system to engineers implementing the system, and
after implementation to document the system’s structure and operation. You may develop models of
both the existing system and the system to be developed.
You may develop different models to represent the system from different perspectives.
1. An external perspective, where you model the context or environment of the system.
2. An interaction perspective, where you model the interactions between a system and its
environment or between the components of a system.
3. A structural perspective, where you model the organization of a system or the structure of the
data that is processed by the system.
4. A behavioral perspective, where you model the dynamic behavior of the system and how it
responds to events.
Five types of UML diagrams that are the most useful for system Modelling:
1. Activity diagrams, which show the activities involved in a process or in data processing.
2. Use case diagrams, which show the interactions between a system and its environment.
3. Sequence diagrams, which show interactions between actors and the system and between
system components.
4. Class diagrams, which show the object classes in the system and the associations between these
classes.
5. State diagrams, which show how the system reacts to internal and external events.
Context models

 Context models are used to illustrate the operational context of a system - they show what lies
outside the system boundaries.

38 | P a g e
  Social and organizational concerns may affect the decision on where to position system
boundaries. Architectural models show the system and its relationship with other systems.
 System boundaries are established to define what is inside and what is outside the system.
 They show other systems that are used or depend on the system being developed.
 The position of the system boundary has a profound effect on the system requirements.
 Defining a system boundary is a political judgment since there may be pressures to develop
system boundaries that increase/decrease the influence or workload of different parts of an
organization.
 Context models simply show the other systems in the environment, not how the system being
developed is used in that environment. Process models reveal how the system being developed
is used in broader business processes.

Interaction models
Types of interactions that can be represented in a model:
1. Modelling user interaction is important as it helps to identify user requirements.
2. Modelling system-to-system interaction highlights the communication problems that may
arise.
3. Modelling component interaction helps us understand if a proposed system structure is likely
to deliver the required system performance and dependability.
Interaction models
1. Use case Modelling, which is mostly used to model interactions between a system and external
actors (users or other systems).
2. Sequence diagrams, which are used to model interactions between system components,
although external agents may also be included.

39 | P a g e
Use Cases
 In software and systems engineering, a use case is a list of actions or event steps, typically
defining the interactions between a role (known in the Unified Modelling Language as an
actor) and a system, to achieve a goal. The actor can be a human, an external system, or time.
In systems engineering, use cases are used at a higher level than within software engineering,
often representing missions or stakeholder goals. Another way to look at it is a use case
describes a way in which a real-world actor interacts with the system.
The purpose of a use case is to:

 Manage scope
 Establish requirements
 Outline the ways a user will interact with the system
 Visualize system architecture
 Communicate technical requirements to business stakeholders

1. Use Case Diagram Objects

Use case diagrams consist of 4 objects:

o Actor Use Case

o System Package

 Actor: Actor in a use case diagram is any entity that performs a role in one given system. This
could be a person, organization, or an external system and is usually drawn like the skeleton
shown below.

 Use Case: A use case represents a function or an action within the system. It's drawn as an oval
and named with the function.

40 | P a g e
  System: The system is used to define the scope of the use case and is drawn as a rectangle.
This is an optional element but useful when visualizing large systems. For example, you can
create all the use cases and then use the system object to define the scope covered by your
project. Or you can even use it to show the different areas covered in different releases.

 Package: Package is another optional element that is extremely useful in complex diagrams.
Similar to class diagrams, packages are used to group together use cases. They are drawn like
the image shown below.

Example: Use Case Diagram

41 | P a g e
Sequence Diagrams
Sequence Diagrams are interaction diagrams that detail how operations are carried out. They capture
the interaction between objects in the context of a collaboration. Sequence Diagrams are time-
focused, and they show the order of the interaction visually by using the vertical axis of the diagram
to represent time, showing what messages are sent and when.
Purpose of Sequence Diagram:
 Model high-level interaction between active objects in a system.
 Model the interaction between object instances within a collaboration that realizes a use case.
 Model the interaction between objects within a collaboration that realizes an operation.
 Either model generic interactions (showing all possible paths through the interaction) or
specific instances of an interaction (showing just one path through the interaction).
Actor:
 A type of role played by an entity that interacts with the subject (e.g., by exchanging signals
and data).
 Represent roles played by human users, external hardware, or other subjects.

42 | P a g e
43 | P a g e
Example 2: Sequence Diagram

Structural Model
Structural models of software display the organization of a system in terms of the components that
make up that system and their relationships. Structural models may be static models, which show the
structure of the system design, or dynamic models, which show the organization of the system when
it is executing. These are not the same things—the dynamic organization of a system as a set of
interacting threads may be very different from a static model of the system components.
Class Diagrams
Class diagrams are used when developing an object-oriented system model to show the classes in a
system and the associations between these classes. An object class can be thought of as a general
definition of one kind of system object. An association is a link between classes that indicates that
there is a relationship between.
these classes. Consequently, each class may have to have some knowledge of its associated class.
When you are developing models during the early stages of the software engineering process,
objects represent something in the real world, such as a patient, a prescription, a doctor, etc. As an
implementation is developed, you usually need to define additional implementation objects that are
used to provide the required system functionality.

Class diagrams in the UML can be expressed at different levels of detail. When you are developing
a model, the first stage is usually to look at the world, identify the essential objects, and represent
these as classes. The simplest way of writing these is to write the class name in a box. You can also
simply note the existence of an association by drawing a line between classes. For example, Figure
is a simple class diagram
showing two classes: Patient and Patient Record with an association between them.

44 | P a g e
In Figure 5.8, I illustrate a further feature of class diagrams—the ability to show how many objects
are involved in the association. In this example, each end of the association is annotated with a 1,
meaning that there is a 1:1 relationship between objects of these classes. That is, each patient has
exactly one record and each record maintains information about exactly one patient. As you can see
from later examples, other multiplicities are possible. You can define that an exact number of
objects are involved or, by using a *, as shown in Figure 5.9, that there are an indefinite number of
objects involved in the association.

Figure 5.9 develops this type of class diagram to show that objects of class Patient are also involved
in relationships with a number of other classes. In this example, you can name associations to give
the reader an indication of the type of relationship that exists. The UML also allows the role of the
objects participating in
the association to be specified.
Fig 5.9 Classes and associations in the MHC-PM

However, the UML is used to represent a semantic data model. You can think of entities in a semantic
data model as simplified object classes (they have no operations), attributes as object class attributes,
and relations as named associations between object classes.
When showing the associations between classes, it is convenient to represent these classes in the
simplest possible way. To define them in more detail, you add information about their attributes (the

45 | P a g e
characteristics of an object) and operations (the things that you can request from an object). For
example, a Patient object will have the attribute Address, and you may include an operation called
Change Address, which is called when a patient indicates that they have moved from one address to
another. In the UML, you show attributes and operations by extending the simple rectangle that
represents a class.
This is illustrated in Figure 5.10 where:
1. The name of the object class is in the top section.
2. The class attributes are in the middle section. This must include the attribute names and,
optionally, their types.
3. The operations (called methods in Java and other OO programming languages) associated with
the object class are in the lower section of the rectangle.
Figure 5.10 shows possible attributes and operations on the class Consultation. In this example,
assume that doctors record voice notes that are transcribed later to record details of the consultation.
To prescribe medication, the doctor involved must use the Prescribe method to generate an electronic
prescription.

Figure 5.10 The .consultation class

46 | P a g e
Class Diagram Relationships

Classes are interrelated to each other in specific ways. In particular, relationships in class diagrams
include different types of logical connections. The following are such types of logical connections
that are possible in UML:

Generalization Model

Generalization is an everyday technique that we use to manage complexity. In Modelling systems, it

is often useful to examine the classes in a system to see if there is scope for generalization. In object-
oriented languages, such as Java, generalization is implemented using the class inheritance
mechanisms built into the language. In a generalization, the attributes and operations associated with
higher-level classes are also associated with the lower-level classes. The lower-level classes are
subclasses inherit the attributes and operations from their super classes. These lower-level classes
then add more specific attributes and operations.

47 | P a g e
Aggregation model

An aggregation model shows how classes that are collections are composed of other classes.
Aggregation models are similar to the part-of relationship in semantic data models.

Behavioral models

Behavioral models are models of the dynamic behavior of the system as it is executing. They show
what happens or what is supposed to happen when a system responds to a stimulus from its
environment. You can think of these stimuli as being of two types:

1. Data. Some data arrives that has to be processed by the system.

2. Events. Some event happens that triggers system processing. Events may have associated
data but this is not always the case.
Many business systems are data processing systems that are primarily driven by data. They
are controlled by the data input to the system with relatively little external event processing.
Their processing involves a sequence of actions on that data and the generation of an output.
For example, our bookstore system will accept information about orders made by a customer,
calculate the costs of these orders, and using another system, it will generate an invoice to be
sent to that customer.

Data-driven Modelling

Data-driven models show the sequence of actions involved in processing input data and generating
the associated output. This is very useful during the analysis stage since they show end-to-end
processing in a system which means that they show the entire action sequence of how input data
become output data. In ither words, it shows the response of the system to particular input.

In UML, activity and sequence diagrams can be used to describe such data flows. Note that these are
the same diagram types we used for interaction Modelling but now the emphasis is put on the
processing itself, not on the objects that will participate in processing (interactions). That is why
48 | P a g e
activity diagrams are better used for that purpose since the lifelines of sequence diagrams depict
objects and actors therefore some attention must be paid to responsibility allocation when using
sequence diagrams.

Event-driven Modelling

Event-driven Modelling shows how a system responds to external and internal events (stimuli). It is
based on the assumption that a system has a finite number of states and that an event (stimulus) may
cause a transition from one state to another. The UML supports event-based Modelling using state
machine diagrams

A state machine diagram models the behaviour of a single object, specifying the sequence of events
that an object goes through during its lifetime in response to events. It contains the following
elements:

 State: A state is denoted by a round-cornered rectangle with the name of the state written
inside it. There are two special states:
o Initial state: The initial state is denoted by a filled black circle and may be labeled
with a name.
o Final state. The final state is denoted by a circle with a dot inside and may also be
labeled with a name.
 Transitions: Transitions from one state to the next are denoted by lines with arrowheads. A
transition may have a trigger, a guard and an effect, as below. Trigger is the cause of the
transition, which could be a signal, an event, a change in some condition, or the passage of
time. Guard is a condition which must be true in order for the trigger to cause the transition.
Effect is an action which will be invoked directly on the object that owns the state machine
as a result of the transition.

49 | P a g e
  State action. State actions describe effects associated with a state. A state action is an
activity label/behavior expression pair. The activity label identifies the circumstances under
which the behavior will be invoked. There are three reserved activity labels:
 entry: the behavior is performed upon entry to the state, odo: ongoing behavior, performed
as long as the element is in the state,
 exit: a behavior that is performed upon exit from the state.
 Self-transition. A state can have a transition that returns to itself. This is most useful when
an effect is associated with the transition.
 Entry point. If we do not enter the machine at the normal initial state, we can have
additional entry points.
 Exit point. In a similar manner to entry points, it is possible to have named alternative exit
points.

Besides these main element, it is important to note that UML state machine diagrams support the
notion of superstates that encapsulate a number of separate states. This superstate can be used as a
single state on a higher-level model but is then expanded to show more details.

The following state machine diagram shows the internal states and transitions of a shopping cart.

Example 1. State machine diagram of the class Shopping Cart

When the shopping cart is initiated, it will be in an Empty state. Whenever products are added, a
transition to Collecting state is performed. When the shopping cart is in the Collecting state and a

50 | P a g e
Product deleted stimulus happens then based on the guards (if the number of products in cart is
equal to 1 or greater) a transition to Empty state might happen.

One might argue that Empty and Collecting are very similar that it does not worth separating them.
This can be a valid point, however, the reason why we separated is that when converting a
bookshelf's contents (like a wishlist) to shopping cart contents will not allow having an empty cart
so the inclusion of the entry point resulted in the separation.

Example 2: State diagram of a micro-oven

Take simple microwave oven to illustrate event-driven Modelling. Real microwave ovens are
actually much more complex than this system but the simplified system is easier to understand.

This simple

microwave has a switch to select full or half power, a numeric keypad to input the cooking time, a
start/stop button, and an alphanumeric display.

I have assumed that the sequence of actions in using the microwave is:

1. Select the power level (either half power or full power).

2. Input the cooking time using a numeric keypad.

3. Press Start and the food is cooked for the given time.

For safety reasons, the oven should not operate when the door is open and, on completion of
cooking, a buzzer is sounded. The oven has a very simple alphanumeric display that is used to
display various alerts and warning messages

Model-driven engineering

 Model-driven engineering (MDE) is an approach to software development where models

rather than programs are the principal outputs of the development process.

51 | P a g e
  The programs that execute on a hardware/software platform are then generated automatically
from the models.
 Proponents of MDE argue that this raises the level of abstraction in software engineering so
that engineers no longer have to be concerned with programming language details or the
specifics of execution platforms.

Usage of model-driven engineering

 Model-driven engineering is still at an early stage of development, and it is unclear whether or

not it will have a significant effect on software engineering practice.
Pros
 Allows systems to be considered at higher levels of abstraction
 Generating code automatically means that it is cheaper to adapt systems to new
platforms.

Cons

 Models for abstraction and not necessarily right for implementation.

 Savings from generating code may be outweighed by the costs of developing
translators for new platforms.

Model driven architecture

o Model-driven architecture (MDA) was the precursor of more general model-driven

engineering
o MDA is a model-focused approach to software design and implementation that uses a subset
of UML models to describe a system.
o Models at different levels of abstraction are created. From a high-level, platform independent
model, it is possible, in principle, to generate a working program without manual
intervention.

Types of model

 A computation independent model (CIM)

These model the important domain abstractions used in a system. CIMs are sometimes called
domain models.
 A platform independent model (PIM)
These model the operation of the system without reference to its implementation. The PIM is
usually described using UML models that show the static system structure and how it
responds to external and internal events.
 Platform specific models (PSM)
These are transformations of the platform-independent model with a separate PSM for each
application platform. In principle, there may be layers of PSM, with each layer adding some
platform-specific detail.

52 | P a g e
 MDA transformations

53 | P a g e
 UNIT - 4
ARCHITECTURAL DESIGNS
ARCHITECTURAL DESIGN: Architectural design decisions; Architectural views; Architectural
patterns- Layered architecture, Repository architecture, Client–server architecture Pipe and filter
architecture
Architectural Design:
 Architectural design is concerned with understanding how a system should be organized and
designing the overall structure of that system.
 It is the critical link between design and requirements engineering, as it identifies the main
structural components in a system and the relationships between them.
 The output of the architectural design process is an architectural model that describes how the
system is organized as a set of communicating components.

You can design software architectures at two levels of abstraction, which I call architecture in
the small and architecture in the large:
1. Architecture in the Small: Concerned with the architecture of individual programs. At this
level, we are concerned with the way that an individual program is decomposed into
components.
2. Architecture in the Large: Concerned with the architecture of complex enterprise systems
that include other systems, programs, and program components. These enterprise systems are
distributed over different computers, which may be owned and managed by different
companies.
Advantages of Explicitly Designing and Documenting Software Architecture:
1. Stakeholder Communication: The architecture is a high-level presentation of the system that
may be used as a focus for discussion with different stakeholders.
2. System Analysis: Making the system architecture explicit at an early stage in the system
development requires some analysis. Architectural design decisions have a profound effect on
whether or not the system can meet critical requirements such as performance, reliability, and
maintainability.
3. Large-Scale Reuse: A model of a system architecture is a compact, manageable description
of how a system is organized and how the components interoperate. The system architecture
is often the same for systems with similar requirements and can support large-scale software
reuse.

53 | P a g e
Dept of CS, MIT FGC
During the architectural design process, system architects have to make a number of structural
decisions that profoundly affect the system and its development process. Based on their
knowledge and experience, they have to consider the following fundamental questions about the
system:
1. Is there a generic application architecture that can act as a template for the system that is being
designed?
2. How will the system be distributed across a number of cores or processors?
3. What architectural patterns or styles might be used?
4. What will be the fundamental approach used to structure the system?
5. How will the structural components in the system be decomposed into subcomponents?
6. What strategy will be used to control the operation of the components in the system?
7. What architectural organization is best for delivering the non-functional requirements of the
system?
8. How will the architectural design be evaluated?
9. How should the architecture of the system be documented?
Architectural Views:
1. What views or perspectives are useful when designing and documenting a system’s
architecture?
2. What notations should be used for describing architectural models?
3. It is impossible to represent all relevant information about a system’s architecture in a single
architectural model, as each model only shows one view or perspective of the system.
4. It might show how a system is decomposed into modules, how the run-time processes interact,
or the different ways in which system components are distributed across a network. All of these
are useful at different times, so, for both design and documentation, you usually need to present
multiple views of the software architecture.
Different Types of Views:
1. A logical view, which shows the key abstractions in the system as objects or object classes. It
should be possible to relate the system requirements to entities in this logical view.
2. A process view, which shows how, at run-time, the system is composed of interacting
processes. This view is useful for making judgments about non-functional system
characteristics such as performance and availability.
3. A development view, which shows how the software is decomposed for development, that is,
it shows the breakdown of the software into components that are implemented by a single
developer or development team. This view is useful for software managers and programmers.

54 | P a g e
Dept of CS, MIT FGC
 4. A physical view, which shows the system hardware and how software components are
distributed across the processors in the system. This view is useful for systems engineers
planning a system deployment.
Architectural Patterns:
The idea of patterns as a way of presenting, sharing, and reusing knowledge about software systems
is now widely used.
Different Types of Architectural Patterns:
1. Layered architecture
2. Repository architecture
3. Client–server architecture
4. Pipe and filter architecture
Layered Architecture:
1. Layered architecture patterns are tiered patterns where the components are organized in
horizontal layers.
2. This is the traditional method for designing most software and is meant to be self-independent.
This means that all the components are interconnected but do not depend on each other.
3. This layered approach supports the incremental development of systems. As a layer is
developed, some of the services provided by that layer may be made available to users.
4. The architecture is also changeable and portable. So long as its interface is unchanged, a layer
can be replaced by another, equivalent layer.

The layered architecture patterns

55 | P a g e
Dept of CS, MIT FGC
Figure 6.6 is an example of a layered architecture with four layers. The lowest layer includes system
support software—
typically database and operating system support. The next layer is the application layer that includes
the components concerned with the application functionality and utility components that are used by
other application components. The third layer is concerned with user interface management and
providing user authentication and authorization, with the top layer providing user interface facilities.
Of course, the number of layers is arbitrary. Any of the layers in Figure 6.6 could be split into two or
more layers.

Example for Layered Architecture

56 | P a g e
Dept of CS, MIT FGC
Repository Architecture:
A repository architecture consists of a central data structure (often a database) and a collection of
independent components that operate on the central data structure. Repositories are very important
for data integration and are being introduced in a variety of applications, including software
development, CAD, etc.

The majority of systems that use large amounts of data are organized around a shared database or
repository. This model is therefore suited to applications in which data is generated by one component
and used by another. Examples of this type of system include command and control systems,
management information systems, CAD systems, and interactive development environments for
software.

Client–Server Architecture:
A system that follows the client–server pattern is organized as a set of services and associated servers,
and clients that access and use these services. The major components of this model are:
 A set of servers that offer services to other components. Examples of servers include print
servers that offer printing services, file servers that offer file management services, and a
compile server, which offers programming language compilation services.

57 | P a g e
Dept of CS, MIT FGC
  A set of clients that call on the services offered by servers. There will normally be several
instances of a client program executing concurrently on different computers.
 A network that allows the clients to access these services. Most client–server systems are
implemented as distributed systems, connected using Internet protocols.

The client–server pattern

Pipe and Filter Architecture:
Pipe and Filter is another architectural pattern, which has independent entities called filters
(components) that perform transformations on data and process the input they receive, and pipes,
which serve as connectors for the stream of data being transformed, each connected to the next
component in the pipeline. Many systems are required to transform streams of discrete data items
from input to output. Many types of transformations occur repeatedly in practice, and so it is desirable
to create these as independent, reusable parts, Filters.

58 | P a g e
Dept of CS, MIT FGC
The pattern of interaction in the pipe-and-filter pattern is characterized by successive transformations
of streams of data. As you can see in the diagram, the data flows in one direction. It starts at a data
source, arrives at a filter’s input port(s) where processing is done at the component, and then is passed
via its output port(s) through a pipe to the next filter, and then eventually ends at the data target.
A single filter can consume data from, or produce data to, one or more ports. They can also run
concurrently and are not dependent. The output of one filter is the input of another; hence, the order
is very important. A pipe has a single source for its input and a single target for its output. It preserves
the sequence of data items, and it does not alter the data passing through.

The Pipe and Filter Pattern

59 | P a g e
Dept of CS, MIT FGC
DESIGN AND IMPLEMENTATION: Object-oriented design using the UML- System context and
interactions, Architectural design, Object class identification, Design models, Interface specification;
Design patterns; Implementation issues
Design:
Software design and implementation is the stage in the software engineering process at which an
executable software system is developed.
Object-Oriented Design Using UML
 An object-oriented system is made up of interacting objects that maintain their own local state
and provide operations on that state.
 Object-oriented design processes involve designing object classes and the relationships
between these classes.
 These classes define the objects in the system and their interactions. When the design is
realized as an executing program, the objects are created dynamically from these class
definitions.
 Objects include both data and operations to manipulate that data.
 They may therefore be understood and modified as stand-alone entities. Changing the
implementation of an object or adding services should not affect other system objects. 
 This improves the understandability, and hence the maintainability, of the design.
To develop a system design from concept to detailed, object-oriented design, there are several
things that you need to do:
1. Understand and define the context and the external interactions with the system.
2. Design the system architecture
3. Identify the principal objects in the system.
4. Develop design models.
5. Specify interfaces.
System Context and Interactions
The first stage in any software design process is to develop an understanding of the relationships
between the software that is being designed and its external environment. This is essential for deciding
how to provide the required system functionality and how to structure the system to communicate
with its environment. Understanding of the context also lets you establish the boundaries of the
system.
System context models and interaction models present complementary views of the
relationships between a system and its environment:
1. A system context model is a structural model that demonstrates the other environment of the
system being developed.

60 | P a g e
Dept of CS, MIT FGC
 2. An interaction model is a dynamic model that shows how the system interacts with its
environment as it is used.
The context model of a system may be represented using associations. Associations simply show that
there are some relationships between the entities involved in the association. The nature of the
relationships is now specified.

System context for the weather Station

Architectural Design
Once the interactions between the software system and the system’s environment have been defined,
you use this information as a basis for designing the system architecture. Of course, you need to
combine this with your general knowledge of the principles of architectural design and with more
detailed domain knowledge.

You identify the major components that make up the system and their interactions, and then may
organize the components using an architectural pattern such as a layered or client–server model.
However, this is not essential at this stage.
Object Class Identification
By this stage in the design process, you should have some ideas about the essential objects in the
system that you are designing. As your understanding of the design develops, you refine these ideas
about the system objects. The use case description helps to identify objects and operations in the
system.

61 | P a g e
Dept of CS, MIT FGC
There have been various proposals made about how to identify object classes in object-
oriented systems:
1. Use a grammatical analysis of a natural language description of the system to be constructed.
Objects and attributes are nouns.
2. Use tangible entities (things) in the application domain such as aircraft, roles such as
manager or doctor, events such as requests, interactions such as meetings, locations such as
offices, organizational units such as companies, and so on.
3. Use a scenario-based analysis where various scenarios of system use are identified and
analyzed in turn. As each scenario is analyzed, the team responsible for the analysis must
identify the required objects, attributes, and operations.
You have to use several knowledge sources to discover object classes. Object classes, attributes, and
operations that are initially identified from the informal system description can be a starting point
for the design.

Weather Station Objects

Design Models
Design or system models show the objects or object classes in a system. They also show the
associations and relationships between these entities. These models are the bridge between the
system requirements and the implementation of a system. They have to be abstract so that
unnecessary detail doesn’t hide the relationships between them and the system requirements.
However, they also have to include enough detail for programmers to make implementation
decisions.
When you use the UML to develop a design, you will normally develop two kinds of design
model:
1. Structural models which describe the static structure of the system using object classes and
their relationships. Important relationships that may be documented at this stage are
62 | P a g e
Dept of CS, MIT FGC
 generalization (inheritance) relationships, uses/used-by relationships and composition
relationships.
2. Dynamic models which describe the dynamic structure of the system and show the
interactions between the system objects. Interactions that may be documented include the
sequence of service requests made by objects and the state changes that are triggered by these
object interactions.
In the early stages of the design process, I think there are three models that are particularly
useful for adding detail to use case and architectural models:
1. Subsystem models, which show logical groupings of objects into coherent subsystems.
These are represented using a form of class diagram with each sub system shown as a
package with enclosed objects. Subsystem models are static (structural) models.
2. Sequence models, which show the sequence of object interactions. These are represented
using a UML sequence or a collaboration diagram. Sequence models are dynamic models.
3. State machine model, which show how individual objects change their state in response to
events. These are represented in the UML using state diagrams. State machine models are
dynamic models.

Interface Specification
 An important part of any design process is the specification of the interfaces between the
components in the design.
 You need to specify interfaces so that objects and subsystems can be designed in parallel.
 Once an interface has been specified, the developers of other objects may assume that
interface will be implemented. 
 Interface design is concerned with specifying the detail of the interface to an object or to a
group of objects. This means defining the signatures and semantics of the services that are
provided by the object or by a group of objects. Interfaces can be specified in the UML using
the same notation as a class diagram. However, there is no attribute section and the UML
stereotype <<interface>> should be included in the name part.

Weather Station Interfaces

63 | P a g e
Dept of CS, MIT FGC
Design Patterns
The pattern is a description of the problem and the essence of its solution, so that the solution may be
reused in different settings. The pattern is not a detailed specification. Rather, you can think of it as a
description of accumulated wisdom and experience, a well-tried solution to a common problem.
OR
Patterns and Pattern Languages are ways to describe best practices, good designs, and capture
experience in a way that it is possible for others to reuse this experience.

Multiple Displays (Design Patterns)

The four essential elements of design patterns were defined by the ‘Gang of Four’ in their
patterns book:

1. A name that is a meaningful reference to the pattern.

2. A description of the problem area that explains when the pattern may be applied.
3. A solution description of the parts of the design solution, their relationships, and their
responsibilities. It is a template for a design solution that can be instantiated in different ways.
This is often expressed graphically and shows the relationships between the objects and object
classes in the solution.
4. A statement of the consequences—the results and trade-offs—of applying the pattern. This can
help designers understand whether or not a pattern can be used in a particular situation.
Graphical representations are normally used to illustrate the object classes in patterns and their
relationships. These supplement the pattern description and add detail to the solution description.
Figure 7.12 is the representation in UML of the Observer pattern.

64 | P a g e
Dept of CS, MIT FGC
 Figure 7.12 A UML Model of the Observer Pattern
Patterns are a great idea but you need experience of software design to use them effectively. You have
to recognize situations where a pattern can be applied. Inexperienced programmers, even if they have
read the pattern books, will always find it hard to decide whether they can reuse a pattern or need to
develop a special purpose solution.
Implementation Issues
System implementation, where you create an executable version of the software. Implementation may
involve developing programs in high- or low-level programming languages or tailoring and adapting
generic, off-the-shelf systems to meet the specific requirements of an organization.
Implementation issues are:
1. Reuse - Software is constructed by reusing existing components or systems. When you are
developing software, you should make as much use as possible of existing code.
2. Configuration management - During the development process, many different versions of
each software component are created. If you don’t keep track of these versions in a
configuration management system, you are liable to include the wrong versions of these
components in your system.
3. Host-target development - Production software does not usually execute on the same
computer as the software development environment. Rather, you develop it on one computer
(the host system) and execute it on a separate computer (the target system). The host and target
systems are sometimes of the same type but, often they are completely different.
Reuse:
Making use of existing code during the software development is called reuse.
1. The only significant reuse is reuse of functions and objects in programming libraries.
Software reuse is possible at different levels. These reuse levels are as follows:
1. Abstraction level: At this level of reuse the software is not directly reused. Instead, the
knowledge of successful abstractions is used in the design of the intended software system.
2. Object level: At this level of reuse, instead of writing the code, the ready objects from the
library are directly used.
65 | P a g e
Dept of CS, MIT FGC
 3. Component level: At this level the components can be reused. The components are basically
the collection of objects and object classes that can be reused on the application software.
4. System level: At this level entire application system can be reused.
Reuse Costs
1. The time spent in looking for software to reuse and analyzing it to check whether the identified
software meets the requirements or not.
2. The required reusable software can be bought. For large off-the-shelf systems this cost can be
high.
3. The cost can be added up while adapting and reconfiguring the reusable software components
in order to fulfil the requirements of the system being developed.
4. The cost also gets increased when integrating reusable software elements with each other and
with the new code being developed for your system.

66 | P a g e
Dept of CS, MIT FGC
 UNIT – 5
SOFTWARE TESTING
SOFTWARE TESTING: Development testing- Unit testing, Choosing unit test cases, Component
testing, System testing. Test-driven development; Release testing; User testing- Alpha, Beta,
Acceptance testing.

Software testing is method to assess the functionality of the software program. The process checks
whether the actual software matches the expected requirements and ensures the software is bug-free.
The purpose of software testing is to identify the errors, faults, or missing requirements in contrast to
actual requirements.
Importance of Software Testing:
 Defects an be identified early :Software testing is important because if there are any bugs
they can be identified early and can be fixed before the delivery of the software.
 Improves quality of software: Software Testing uncovers the defects in the software, and
fixing them improves the quality of the software.
 Increased customer satisfaction: Software testing ensures reliability, se-purity, and high
performance which results in saving time, costs, and customer satisfaction.
 Helps with scalability: Software testing type non-functional testing helps to identify the
scalability issues and the point where an application might stop working. Saves time and
money: After the application is launched it will be
 Saves time and money: After the application is launched it will be very difficult to trace and
resolve the issues, as performing this activity will incur more costs and time. Thus, it is better
to conduct software testing at regular intervals during software development.
Verification
Verification is the process of checking that software achieves its goal without any bugs. It is the
process to ensure whether the product that is developed is right or not. It verifies whether the
developed product fulfils the requirements that we have.
Validation
Validation is the process of checking whether the software product is up to the mark or in other words
product has high-level requirements. It is the process of checking the validation of the product i.e. it
checks what we are developing is the right product. It is a validation of actual and expected products.

67 | P a g e Dept of CS, MIT FGC

Different Types of Software Testing

Classification Software Testing

1. Manual Testing: Manual testing includes testing software manually, i.e., without using any
automation tool or script. In this type, the tester takes over the role of an end-user and tests the
software to identify any unexpected behavior or bug. There are different stages for manual
testing such as unit testing, integration testing, system testing, and user acceptance testing.
Testers use test plans, test cases, or test scenarios to test software to ensure the completeness
of testing. Manual testing also includes exploratory testing, as testers explore the software to
identify errors in it.
2. Automation Testing: Automation testing, which is also known as Test Automation, is when
the tester writes scripts and uses another software to test the product. This process involves the
automation of a manual process. Automation Testing is used to re-run the test scenarios quickly
and repeatedly, that were performed manually in manual testing. Apart from regression testing,
automation testing is also used to test the application from a load, performance, and stress point
of view. It increases the test coverage, improves accuracy, and saves time and money when
compared to manual testing.
Different types of Software Testing Techniques
Software testing techniques can be majorly classified into two categories:
1. Black Box Testing: Black box technique of testing in which the tester doesn’t have access to
the source code of the software and is conducted at the software interface without any concern
with the internal logical structure of the software known as black-box testing.
2. White Box Testing: White box technique of testing in which the tester is aware of the internal
workings of the product, has access to its source code, and is conducted by making sure that

68 | P a g e Dept of CS, MIT FGC

 all internal operations are performed according to the specifications is known as white box
testing.
3. Grey Box Testing: Grey Box technique is testing in which the testers should have knowledge
of implementation, however, they need not be experts.

Sl Black Box Testing White Box Testing

No.
1 Internal workings of an application are Knowledge of the internal workings is amust.
not required.
2 Also known as closed box/data- driven Also known as clear box/structural testing.
testing.
3 End user, testers, and developers. Normally done by testers and developers.

4 This can only be done by atrial and Data domains and internal boundaries can be
Error method better tested.

A model of the software testing process

A commercial software system has to go through three stages of testing:

1. Development testing where the system is tested during development to discover bugs and
defects. System designers and programmers are likely to be involved in the testing process.
2. Release testing where a separate testing team tests a complete version of the system before it
is released to users. The aim of release testing is to check that the system meets the
requirements of system stakeholders.
3. User testing where users or potential users of a system test the system in their own
environment.
Development Testing:
Development testing includes all testing activities that are carried out by the team developing the
system. The tester of the software is usually the programmer who developed that software, although
this is not always the case. Some development processes use programmer/tester pairs. For critical

69 | P a g e Dept of CS, MIT FGC

systems, a more formal process may be used, with a separate testing group within the development
team. They are responsible for developing tests and maintaining detailed records of test results.
During development, testing may be carried out at three levels of granularity:
1. Unit testing, where individual program units or object classes are tested. Unit testing should
focus on testing the functionality of objects or methods.
2. Component testing, where several individual units are integrated to create composite
components. Component testing should focus on testing component interfaces.
3. System testing, where some or all the components in a system are integrated and the system
is tested as a whole. System testing should focus on testing component interactions.
Unit Testing
Unit testing is the process of testing program each unit or components, such as methods or object
classes. Individual functions or methods are the simplest type of component. Your tests should be
calls to these routines with different input parameters.
When you are testing object classes, you should design your tests to provide coverage of all the
features of the object. This means that you should:
 Test all operations associated with the object.
 Set and check the value of all attributes associated with the object.
 Put the object into all possible states. This means that you should simulate all events that cause
a state change.
 Generalization or inheritance makes object class testing more complicated. 
 Whenever possible, you should automate unit testing. In automated unit testing, you make use
of a test automation framework (such as JUnit) to write and run your program tests. Unit testing
frameworks provide generic test classes that you extend to create specific test cases.
An automated test has three parts:
1. A setup part, where you initialize the system with the test case, namely the inputs and expected
outputs.
2. A call part, where you call the object or method to be tested.
3. An assertion part where you compare the result of the call with the expected result. If the
assertion evaluates to true, the test has been successful; if false, then it has failed.
Choosing Unit Test Cases
It is important that you choose effective unit test cases. Effectiveness, in this case, means two things:
1. The test cases should show that, when used as expected, the component that you are testing
does what it is supposed to do.

70 | P a g e Dept of CS, MIT FGC

 2. If there are defects in the component, these should be revealed by test cases.
You should therefore write two kinds of test case. The first of these should reflect normal operation
of a program and should show that the component works.
The other kind of test case should be based on testing experience of where common problems arise.
It should use abnormal inputs to check that these are properly processed and do not crash the
component.
There are two possible strategies here that can be effective in helping you choose test cases.
These are:
1. Partition testing, where you identify groups of inputs that have common characteristics and
should be processed in the same way. You should choose tests from within each of these groups.
2. Guideline-based testing, where you use testing guidelines to choose test cases. These
guidelines reflect previous experience of the kinds of errors that programmers often make when
developing components.
Advantages of Unit Testing:
1. Unit Testing allows developers to learn what functionality is provided by a unit and how to use
it to gain a basic understanding of the unit API.
2. Unit testing allows the programmer to refine code and make sure the module works properly.
3. Unit testing enables testing parts of the project without waiting for others to be completed.
4. Early Detection of Issues: Unit testing allows developers to detect and fix issues early in the
development process before they become larger and more difficult to fix.
5. Improved Code Quality: Unit testing helps to ensure that each unit of code works as intended
and meets the requirements, improving the overall quality of the software.
6. Increased Confidence: Unit testing provides developers with confidence in their code, as they
can validate that each unit of the software is functioning as expected.
Disadvantages of Unit Testing:
1. The process is time-consuming for writing the unit test cases.
2. Unit Testing will not cover all the errors in the module because there is a chance of having
errors in the modules while doing integration testing.
3. Unit Testing is not efficient for checking the errors in the UI (User Interface) part of the
module.
4. It requires more time for maintenance when the source code is changed frequently.
5. It cannot covert the non-functional testing parameters such as scalability, the performance of
the system, etc.

71 | P a g e Dept of CS, MIT FGC

 6. Time and Effort: Unit testing requires a significant investment of time and effort to create and
maintain the test cases, especially for complex systems.
Unit Testing Tools:
1. Jtest
2. Junit
3. NUnit
4. EMMA
5. PHPUnit
Top 4 Unit Testing Tools
JUnit
JUnit is an open-source unit testing tool in Java. It does not require the creation of class objects or the
definition of the main method to run tests. It has an assertion library for evaluating test results.
Annotations in JUnit are used to execute test methods. JUnit is commonly used to run automation
suites with multiple test cases.
N Unit
N Unit, an open-source unit testing framework based on .NET, inherits many of its features directly
from JUnit. Like JUnit, N Unit offers robust support for Test-Driven Development (TDD) and shares
similar functionalities. N Unit enables the execution of automated tests in batches through its console
runner.
TestNG
TestNG, short for Test Next Generation, is a robust framework that offers comprehensive control over
the testing and execution of unit test cases. It incorporates features from both JUnit and NUnit,
providing support for various test categories such as unit, functional, and integration testing. TestNG
stands out as one of the most powerful unit testing tools due to its user-friendly functionalities.
PHP Unit
PHP Unit is a programmer-oriented unit testing framework specifically designed for PHP. It adheres
to the x Unit architecture commonly utilized by unit testing frameworks such as NUnit and JUnit.
PHP Unit operates exclusively through command-line execution and does not have direct
compatibility with web browsers.
Component Testing
Component testing is a form of closed-box testing, meaning that the test evaluates the behavior of the
program without considering the details of the underlying code. Component testing is done on the
section of code in its entirety, after the development has been completed.

72 | P a g e Dept of CS, MIT FGC

Component testing takes longer to conduct than unit testing, because a component is made up of
multiple units of code. Although it can be time-consuming, it is still very much necessary. Sometimes
the individual units work on their own, but start having problems when you use them together.
Component testing examines use cases, so it could be considered a form of end-to-end (E2E) testing.
End-to-end testing and component testing replicate real-life scenarios and test the system against
those scenarios from a user’s perspective.
Implementing component testing is beneficial because it can reveal bugs and errors that users might
encounter. It is always better to catch and fix these errors before users know about them.
There are two types of component testing:
1. Component testing in small
2. Component testing in large
Component Testing in Small
With component testing in small, the components that are being tested are still segregated from other
components in the system. You should still make use of mocks and test endpoints to simulate the
components that connect with the one that is being tested. This form of testing ensures the component
is ready to be integrated with the rest of the system.
Component Testing in Large
Component testing in large is done without segregation, meaning the tested component will have
access to external components. With component testing in large, it is still only the main component
that is being tested, not the connected components or how the components interact with each other.
That would be integration testing.
Advantages:
1. It is convenient for small systems.
2. Simple and straightforward approach.
3. Can be completed quickly.
4. Does not require a lot of planning or coordination.
5. May be suitable for small systems or projects with a low degree of interdependence between
components.
Disadvantages:
1. There will be quite a lot of delay because you would have to wait for all the modules to be
integrated.
2. High-risk critical modules are not isolated and tested on priority since all modules are tested
at once.

73 | P a g e Dept of CS, MIT FGC

 3. Not Good for long projects.
4. High risk of integration problems that are difficult to identify and diagnose.
5. This can result in long and complex debugging and troubleshooting efforts.

System Testing
The software is compiled as product and then it is tested as a whole.
OR
System testing is a type of software testing that evaluates the overall functionality and performance
of a complete and fully integrated software solution. It tests if the system meets the specified
requirements and if it is suitable for delivery to the end-users.
1. During system testing, reusable components that have been separately developed and off-the-
shelf systems may be integrated with newly developed components. The complete system is
then tested.
Components developed by different team members or groups may be integrated at this stage. System
testing is a collective rather than an individual process.
In some companies, system testing may involve a separate testing team with no involvement from
designers and programmers.
Types of System Testing:
 Performance Testing: Performance Testing is a type of software testing that is carried out to
test the speed, scalability, stability and reliability of the software product or application.
 Load Testing: Load Testing is a type of software Testing which is carried out to determine the
behavior of system or software product under extreme load.
 Stress Testing: Stress Testing is a type of software testing performed to check the robustness
of the system under the varying loads.
 Scalability Testing: Scalability Testing is a type of software testing which is carried out to
check the performance of a software application or system in terms of its capability to scale up
or scale down the number of user re-quest load.
Advantages of System Testing:
 Verifies the overall functionality of the system.
 Detects and identifies system-level problems early in the development cycle.
 Helps to validate the requirements and ensure the system meets the user needs.
 Improves system reliability and quality.

74 | P a g e Dept of CS, MIT FGC

  Facilitates collaboration and communication between development and testing teams. 
 Enhances the overall performance of the system.
Disadvantages of System Testing:
 Can be time-consuming and expensive.
 Requires adequate resources and infrastructure.
 Can be complex and challenging, especially for large and complex systems.
 Dependent on the quality of requirements and design documents.
 Limited visibility into the internal workings of the system.
 Can be impacted by external factors like hardware and network configurations.
Test-driven development
Test Driven Development (TDD) is a software development practice that focuses on creating unit test
cases before developing the actual code. It is an iterative approach combining programming, unit test
creation, and refactoring.
 The TDD approach originates from the Agile manifesto principles and Extreme programming.
 As the name suggests, the test process drives software development. 
 Moreover, it’s a structuring practice that enables developers and testers to obtain optimized
code that proves resilient in the long term. 
Three Phases of Test Driven Development
1. Create precise tests: Developers need to create exact unit tests to verify the functionality of
specific features. They must ensure that the test compiles so that it can execute. In most cases,
the test is bound to fail. This is a meaningful failure as developers create compact tests based
on their assumptions of how the feature will behave.
2. Correcting the Code: Once a test fails, developers must make the minimal changes required
to update the code to run successfully when re-executed.
3. Refactor the Code: Once the test runs successfully, check for redundancy or any possible code
optimizations to enhance overall performance. Ensure that refactoring does not affect the
external behavior of the program.

75 | P a g e Dept of CS, MIT FGC

 The image below represents a high-level TDD approach toward development:

Benefits of Test Driven Development (TDD)

 Fosters the creation of optimized code.
 It helps developers better analyze and understand client requirements and request clarity when
not adequately defined.
 Adding and testing new functionalities become much easier in the latter stages of development.
 Test coverage under TDD is much higher compared to conventional development models. The
TDD focuses on creating tests for each functionality right from the beginning.
 It enhances the productivity of the developer and leads to the development of a codebase that
is flexible and easy to maintain.
Release Testing:
Release testing is the process of testing a particular release of a system that is intended for use outside
of the development team.
There are two important distinctions between release testing and system testing during the
development process:
1. A separate team that has not been involved in the system development should be responsible
for release testing.
2. System testing by the development team should focus on discovering bugs in the system
(defect testing). The objective of release testing is to check that the system meets its
requirements and is good enough for external use (validation testing).

76 | P a g e Dept of CS, MIT FGC

 3. Release testing is usually a black-box testing process where tests are derived from the system
specification. The system is treated as a black box whose behavior can only be determined by
studying its inputs and the related outputs. Another name for this is ‘functional testing’, so-
called because the tester is only concerned with functionality and not the implementation of
the software.
There are three types User testing- Alpha, Beta, Acceptance testing.
Alpha Testing
Alpha Testing is a type of Acceptance Testing performed by the testers who are part of the
organization, in other words: internal employees. It is the final stage of testing and it is usually done
to verify that an application is free of errors /bugs before being launched on the market. This test uses
black box and white box techniques and it is performed near the end of the development of the
software and before Beta Testing.
Beta Testing
Beta Testing is performed by real users and it is unstructured. It can be considered as a form of external
User Acceptance Testing. Users can freely use the application and then they are encouraged to give
feedback about their experience. This test is more focuses on performance and scalability.
Beta Testing helps reduce product failures and provides higher product quality through customer
validation that resulted from their experience with the application.
Acceptance Testing
Acceptance testing is formal testing based on user requirements and function pro- cessing. It
determines whether the software is conforming specified requirements and user requirements or not.
It is conducted as a kind of Black Box testing where the number of required users involved testing
the acceptance level of the system. It is the fourth and last level of software testing.

User Acceptance Testing (UAT) is a type of testing, which is done by the customer before accepting
the final product. Generally, UAT is done by the customer (domain expert) for their satisfaction, and
check whether the application is working according to given business scenarios, real-time scenarios.
In this, we concentrate only on those features and scenarios which are regularly used by the customer
or mostly user scenarios for the business or those scenarios which are used daily by the end-user or
the customer

77 | P a g e Dept of CS, MIT FGC