PANIMALAR INSTITUTE OF TECHNOLOGY

DEPARTMENT OF INFORMATION TECHNOLOGY

CS8494- SOFTWARE ENGINEERING
LECTURE NOTES
UNIT-I
SYLLABUS
UNIT I SOFTWARE PROCESS AND AGILE DEVELOPMENT
Introduction to Software Engineering, Software Process, Perspective and Specialized Process
Models-Introduction to Agility – Agile process – Extreme programming – XP Process.

INTRODUCTION TO SOFTWARE ENGINEERING

Software:
Software is a set of instructions (computer programs) that when executed provide desired
features, function, and performance.
Example: Microsoft Teams, Windows media player

Characteristics of Software:
1.Software is developed or engineered; it is not manufactured in the classical sense.
 Software is developed. But hardware is manufactured.
 In both hardware and software, high quality is achieved through good design.
 Both activities are dependent on people, but the relationship between people applied and
work accomplished is entirely different.
 Changes can be made easily in software compared to hardware.

2. Software doesn’t “wear out.”

 Hardware exhibits relatively high failure rates early in its life.
 Though defects can be corrected and rectified, as time passes the failure rate rises again
as hardware components suffer from the cumulative effects of dust, vibration, abuse,
temperature extremes, and many other environmental maladies. Stated simply, the
hardware begins to wear out.
1
  But software does not wear out. But, deteriorate! (worse). The performance of the
software will become less efficient as time passes.

3.Although the industry is moving toward component-based construction, most

software continues to be custom built.
 In the hardware world, component reuse is a natural part of the engineering process.
But, not in case of software.
 A software component should be designed and implemented so that it can be
reused in many different programs.

Software Products:
They are two types
1. Generic products
2. Customized products

Generic Product Customized Product

They are developed by an organization They are developed by an organization for
and sold to a open market(public). specific customer.

Ex: Whatsapp, Windows movie maker. Ex: Library management system for
specific college

Categories of Computer Software:

1.System software:
A software collection of programs written to service other programs.
E.g., compilers, editors.

2.Application software:
Stand-alone programs that solve a specific business need.
E.g., Zoom, Google Meet, MS word.

2
3.Scientific software:
Software used for scientific purpose
E.g, Computer-aided design, MATLAB, Autocad,etc..

4.Embedded software:
Resides within a product or system.
E.g., Traffic control system found in traffic light, Imaging processing system in medical imaging
equipment etc.

5.Product-line software:
Designed to provide a specific capability for use by many different customers.
E.g., word processing, spreadsheets, computer graphics, multimedia, entertainment

6.Web applications:
Called ―WebApps. Web applications not only provide standalone features but are also
integrated with corporate databases and business applications.
E.g, gmail, yahoo, shopping carts, google apps etc..

7.Artificial intelligence software:

Makes use of non numerical algorithms to solve complex problems.
Applications within this area include robotics, expert systems, pattern recognition (image and
voice), artificial neural networks and game playing.

Software Engineering – A Layered Technology

 Software engineering is a branch that is associated with collection of methods
(practice), procedures, concepts, techniques and tools that allow professionals to
build high quality computer software.
 Software engineering is the application of a systematic, disciplined, quantifiable
approach to the development, operation, and maintenance of software.
 Software engineering is a layered technology.

3
A Quality Focus:
Any engineering approach (including software engineering) must rest on an organizational
commitment that focus on quality of the product.
Process:
The foundation for software engineering is the process layer.(Technology layer).
A process is a collection of activities, actions or task that performed when some work product is
to be created.
Methods:
Methods includes a broad set of tasks such as communication, requirements analysis, design
modeling, program construction, testing, and support.

Fig: Software Engineering – A Layered Technology

Tools:
Software engineering tools provide automated or semi automated support for the process and the
methods.

SOFTWARE PROCESS
Process:
A process is a collection of activities, actions or task that are performed when some work
product is to be created.
Software process is characterized by
i) Process Framework Activities
ii) Task sets
iii) Umbrella Activities

4
 Generic Process Framework Activities: ( Software Development Lifecycle phases) :
1. Communication
2. Planning
3. Modeling
4. Construction
5. Deployment

Communication (Requirement gathering)

Business requirements are gathered in this phase
•Meetings with managers, developer and users are held in order to determine the requirements
like;who is going to use the system? How will they use the system? What data should be input
into the system? What data should be output by the system?
•After requirement gathering these requirements are analyzed for their validity.
Finally, a Requirement Specification document is created which serves the purpose of guideline
for thenext phase of the model.

Planning (Cost Estimating, Scheduling)

 Estimation of cost or project budget is done here
 Scheduling the time duration of a project is done in this stage
 Project budget and delivery date are finalized and documented

Modeling (Analysis, Design)

Models are created to better understand software requirements and the design that will

5
 achievethose requirements.
In this phase, the system and software design is prepared from the requirement
specificationswhich were studied in the first phase.
•System Design helps in specifying hardware and system requirements and also helps in
defining overall system architecture. It is actually a blueprint for implementation.
•The system design specifications serve as input for the next phase of the model.

Construction (Coding, Testing)

•On receiving system design documents, the work is divided in modules/units and actual coding
is started.

Coding: It is an important phase where design is translated into machine readable form. Simply,
Programs are created in this phase. This is the longest phase of the software development life
cycle.

Testing: After the code is developed it is tested against the requirements to make sure that the
product is actually solving the needs addressed and gathered during the requirements phase.
During this phase unit testing, integration testing, system testing, acceptance testing are done.
Testing ensures the execution of all the paths and functional behaviors.
The purpose of testing is to uncover errors, fix the bugs and meet customer requirements.

Deployment (delivery, maintenance)

•After successful testing, the product is delivered / deployed to the customer for their use.
•Once when the customers starts using the developed system then the actual problems comes up
and needs to be solved from time to time.
•This process where the care is taken for the developed product is known as maintenance.

(ii) Taskset:
It defines the actual work done in order to achieve the software objectives.

6
(iii) Umbrella Activities:
• Software engineering process framework activities are complemented by a number of
umbrella activities.
• In general, umbrella activities are applied throughout a software project and help a
software team to manage and control progress, quality, change, and risk.

Fig: A software Process framework

7
Typical umbrella activities include:
Software project tracking and control—allows the software team to assess progress
against the project plan and take any necessary action to maintain the schedule.
Risk management—assesses risks that may affect the outcome of the project or the
quality of the product.
Software quality assurance—defines and conducts the activities required to ensure
software quality
Technical reviews—assesses software engineering work products in an effort to uncover
and remove errors before they are propagated to the next activity.
Measurement—defines and collects process, project, and product measures that assist
the team in delivering software that meets stakeholders‘ needs; can be used in
conjunction with all other framework and umbrella activities.
Software configuration management—manages the effects of change throughout the
software process.
Reusability management—defines criteria for work product reuse (including software
components) and establishes mechanisms to achieve reusable components.
Work product preparation and production—encompasses the activities required to
create work products such as models, documents, logs, forms, and lists.

PERSPECTIVE PROCESS MODELS

Prescribe set of process elements for each project.
1. The waterfall model
2. V-model
3. Incremental process model / RAD model
4. Evolutionary process model / Prototyping model
5. The spiral model
6. Concurrent Development model

8
The Waterfall Model
The Waterfall Model is also referred to as a linear-sequential model or classic life cycle
model.
It is a sequential approach to software development that begins with customer
specification of requirements and progresses through planning, modeling,
construction, and deployment, culminating in ongoing support of the completed
software.

Fig: Waterfall Model

Features of waterfall model:
• It is very simple to understand and use.
• In a waterfall model, each phase must be completed fully before the next phase can
begin.
• This type of model is basically used for the for the project which is small and there are no
uncertain requirements.
• At the end of each phase, a review takes place to determine if the project is on the right
path and whether or not to continue or discard the project.
• Testing phase starts only after the development is complete.
• In waterfall model phases do not overlap.
• Documentation is produced in each and every step.

Advantages of waterfall model:

• This model is simple and easy to understand and use.
• In this model phases are processed and completed one at a time. Phases do not overlap.
• Easy to manage because there is no parallel processing.

9
• Waterfall model works well for smaller projects where requirements are very well
understood.
• Documentation helps for future reference.

Disadvantages of waterfall model:

• Requirement analysis is done initially, sometime its not possible to state all requirements
initially.
• Once an application is in the testing stage, it is very difficult to go back and change
something.
• Customer can see the model only at the end.
• High amounts of risk and uncertainty.
• Not a good model for complex and object-oriented projects.
• Poor model for long and complex projects.
• No customer interaction.

When to use the waterfall model:

• This model is used only when the requirements are very well known, clear and fixed.
• Product definition is stable.
• Technology is understood.
• There are no ambiguous requirements
• The project is short.

V-model
• V- Model means Verification and Validation model.
• A variation in the representation of the waterfall model is called the V-model.
• Just like the waterfall model, the V-Shaped life cycle is a sequential path of execution of
processes.
• Each phase must be completed before the next phase begins.
• Testing of the product is planned in parallel with a corresponding phase of development.

10
Phases of V-Model:
Requirements :
• Requirements like BRS and SRS begin the life cycle model just like the waterfall model.
• But, in this model before development is started, a system test plan is created.

The high-level design (HLD):

• This phase focuses on system architecture and design.
• It provides overview of solution, platform, system, product and service/process.
• An integration test plan is created in this phase as well in order to test the pieces of the
software systems ability to work together.
The low-level design (LLD):
• This phase is where the actual software components are designed.
• It defines the actual logic for each and every component of the system.
Implementation
• In this phase , all coding takes place.
• Once coding is complete, the path of execution continues up the right side of the V where
the test plans developed earlier are now put to use.
Coding:
• This is at the bottom of the V-Shape model.
• Module design is converted into code by developers.
Advantages of V-model:
• Simple and easy to use.
• Testing activities like planning, test designing happens well before coding. This saves a
lot of time. Hence higher chance of success over the waterfall model.
• Proactive defect tracking – that is defects are found at early stage.
• Avoids the downward flow of the defects.
• Works well for small projects where requirements are easily understood.
Disadvantages of V-model:
• Very rigid and least flexible.

11
• Software is developed during the implementation phase, so no early prototypes of the
software are produced.
• If any changes happen in midway, then the test documents along with requirement
documents has to be updated.

Diagram of V-model:

12
 When to use the V-model:
• The V-shaped model should be used for small to medium sized projects where
requirements are clearly defined and fixed.
• The V-Shaped model should be chosen when ample technical resources are available
with needed technical expertise.
• High confidence of customer is required for choosing the V-Shaped model approach.
Since, no prototypes are produced, there is a very high risk involved in meeting customer
expectations.

Incremental Model:
• Incremental model combines elements of waterfall model applied in an iterative fashion.
• In incremental model the whole requirement is divided into various builds.
 Incremental model delivers series of releases to the customer. These releases are called
increments. More and more functionality is associated with each increment.
First increment is called core product. Basic requirements are included in this
increment. Then, new requirements are added in further increments. The process
continues till the complete system is achieved.

For example:

Diagram of Incremental model:

13
Multiple development cycles take place here, making the life cycle a multi-
waterfall cycle.Cycles are divided up into smaller, more easily managed modules.
Each module passes through the requirements, design, implementation and testing phases.
Example: Word processing package

Advantages of Incremental model:

 Generates working software quickly and early during the software life cycle.
 This model is more flexible – less costly to change scope and requirements.
 It is easier to test and debug during a smaller iteration.
 In this model customer can respond to each built.
 Easier to manage risk because risky pieces are identified and handled during it‘d
iteration.

Disadvantages of Incremental model:

 Needs good planning and design.
 Needs a clear and complete definition of the whole system before
it can be broken down andbuilt incrementally.
 Total cost is higher than waterfall.

When to use the Incremental model:

 This model can be used when the requirements of the complete
system are clearly defined andunderstood.
 Major requirements must be defined; however, some details can evolve with time.
 There is a need to get a product to the market early.
 A new technology is being used
 Resources with needed skill set are not available
 There are some high risk features and goals.

14
RAD Model/(RAPID APPLICATION DEVELOPMENT MODEL)
RAD model is a type of incremental process model in which there is extremely short
development cycle.
It is a type of incremental model.

In RAD model the components or functions are developed in parallel as if they were
mini projects.

The developments are time boxed, delivered and then assembled into a working
prototype.
This can quickly give the customer something to see and use and to provide
feedback regarding thedelivery and their requirements.

Fig: RAD Model

Features of RAD model:
Using a RAD Model, a software product can be developed within 60 to 90 days of time.

Various phases of RAD model are

 Requirement gathering,
 Planning,
 Analysis,
 Design
15
  Coding
 Deployment

Advantages of the RAD model:

 Reduced development time.
 Increases reusability of components
 Quick initial reviews occur
 Encourages customer feedback
Disadvantages of RAD Model:
 Requires highly skilled developers/designers.
 Requires multiple teams and large number of people to work on a project.
 Need Heavy resources
 If there is no proper modularization, then RAD project would fail.
 Adopting new technologies is difficult.

The Evolutionary Process Model / Prototyping Model:

It is difficult to do modifications in earlier development phases of linear model. In such
cases Iterative approach is adopted.
The evolutionary process model is iterative model.

Fig: Prototyping Model

16
Features
• The basic idea here is that instead of freezing the requirements before a design or coding
can proceed, a throwaway prototype is built to understand the requirements.
• This prototype is developed based on the currently known requirements.
• By using this prototype, the client can get an actual feel of the system, since the
interactions with prototype can enable the client to better understand the requirements of the
desired system.
• Prototyping is an attractive idea for complicated and large systems for which there is
no manual process or existing system to help determining the requirements.
• The prototype is usually not complete systems and many of the details are not built in the
prototype. The goal is to provide a system with overall functionality.

Advantages of Prototype model:

 Since, in this methodology a working model of the system is provided, the
users get a better understanding of the system being developed.
 Users are actively involved in the development
 Errors can be detected much earlier.

Disadvantages of Prototype model:

 Leads to implementing and then repairing way of building systems.
 Practically, this methodology may increase the complexity of the
system as scope of the systemmay expand beyond original plans.
 Incomplete application may cause application not to be used as the full system was
designed.
 Incomplete or inadequate problem analysis.

When to use Prototype model:

 Prototype model should be used when the desired system needs to have a lot of
interaction with the end users.
 Typically, online systems, web interfaces have a very high amount of

17
 interaction with end users, are bestsuited for Prototype model.
 It might take a while for a system to be built that allows ease of use and
needs minimal training forthe end user.
 Prototyping ensures that the end users constantly work with the system and
provide a feedback which is incorporated in the prototype to result in a useable
system.
 They are excellent for designing good human computer interface systems.

The Spiral Model:

Spiral model is proposed by Boehm.
• Spiral model is evolutionary process model that combines the iterative nature of
prototyping.
• Spiral model iterative in nature.
• The spiral model is similar to the incremental model, with more emphasis placed on risk
analysis.
• The spiral model has four phases: Planning, Risk Analysis, Engineering and Evaluation.
• A software project repeatedly passes through these phases in iterations (called Spirals in
this model).
• The baseline spiral, starting in the planning phase, requirements is gathered and risk is
assessed.
• Each subsequent spiral builds on the baseline spiral.

18
• Planning Phase:
 Requirements are gathered during the planning phase.
 Requirements like ‛BRS‘ that is ‛Business Requirement Specifications’ and SRS‘
that is System Requirement specifications’ is created.

Risk Analysis:
 In the risk analysis phase, a process is undertaken to identify risk and alternate
solutions.
 A prototype is produced at the end of the risk analysis phase.
 If any risk is found during the risk analysis then
alternate solutions are suggestedand implemented.

Engineering Phase:
 In this phase software is developed, along with testing at the end of the phase.
 Hence in this phase the development and testing is done.

Evaluation phase:
 This phase allows the customer to evaluate the output of the project to date
before theproject continues to the next spiral.

19
Advantages of Spiral model:
 High amount of risk analysis hence, Hence Risk vcan be
identified and rectified before theyget problematic.
 Requirement changes can be made easily at every stage.
 Good for large and mission-critical projects.
 Strong approval and documentation control.
 Additional Functionality can be added at a later date.
 Software is produced early in the software life cycle.

Disadvantages of Spiral model:

 Can be a costly model to use.
 Risk analysis requires highly specific expertise.
 Project‘s success is highly dependent on the risk analysis phase.
 Doesn‘t work well for smaller projects.
When to use Spiral model:
 When costs and risk evaluation is important
 When project is not expected within a specific limited time span
 For medium to high-risk projects
 Users are unsure of their needs
 Requirements are complex.
 Significant changes are expected (research and exploration)

The Concurrent Process Model (Concurrent Development Model):

 The concurrent development model, sometimes called concurrent engineering.
 Any process model can be represented in concurrent methodology.
 It has following states
1. Inactive
2. Under development
3. Under review
4. Baselined

20
5. Done
6. Awaiting changes
7. Under revision

Working Principle:
 For example, early in a project the communication activity (not shown in the
figure) has completedits first iteration and exists in the awaiting changes state.
 The modeling activity (which existed in the inactive state while initial
communication was completed, now makes a transition into the under development
state.
 If, however, the customer indicates that changes in requirements must be made,
the modeling activity moves from the under development state into the awaiting
changes state.
 Concurrent modeling defines a series of events that will trigger transitions from
state to state for each of the software engineering activities, actions, or tasks.

Advantages:
 It is applicable for all type of software projects
 It gives accurate state of current project.
 It requires less time compare to other models.

Disadvantages:
 Need to keep track of all states simultaneously
 Costly model
 Need more man power
 Because all of the stages are working simultaneously, any changes to
user requirements halts the work on any component dependent on the
component being changed.
 This model requires excellent and current communication between all
teams, which is sometimesnot easily feasible.

21
 Fig: Concurrent development model
When to use:
 When time duration of the project is less
 When we want to utilize all resources

22
 SPECIALIZED PROCESS MODELS
These specialized process models will take many characteristics of one or more perspective
process model.

Types:
1. Component Based Development
2. The Formal Methods Model
3. Aspect-Oriented Software Development

Component Based Development Model:

• Prepackaged components , Commercial off-the-shelf (COTS) Software components that
are developed by different vendors, can be used to build the software product.
• These components provide targeted functionality with well-defined interfaces . It
enables the component to be integrated into the Software.
• This model construct the applications from prepackages software model.
• The component based development model incorporates many of the characteristics use of
various spiral model.
• This model is evolutionary in model.(i.e.) necessary changes can be made in the software
during each iteration of software development cycle.

Steps involved in developing the component-based development model :

1. Available component-based products are researched and evaluated for the
application.
2. Component integration issues are considered.
3. Software architecture is designed to accommodate the components.
4. Components are integrated into the architecture.
5. Integration testing is conducted to ensure proper functionality.

Advantages:
 Component reusability

23
  SDLC time will be reduced.
 Reduction in projects cost if component is already available.

The Formal Methods Model

Encompasses a set of activities that leads to formal mathematical specifications of
Software.
•Formal methods enable a Software engineer to specify, develop, and verify a computer-
based system by applying a rigorous, mathematical notation.

In this method all specifications and designs are converted into mathematical notations.
All mathematical notations are validated against mathematical proofs.
So this method assures us to produce error free software.
Ambiguity, incompleteness, and inconsistency can be discovered and corrected more easily
throughthe application of mathematical analysis.
When formal methods are used during design, they serve as a basis for program verification
and therefore enable.
A variation of this approach, called clean-room Software engineering is currently applied
bysome software development organizations.

Advantages:
100% error free software.
Ambiguity and complex functionality are removed
Fault tolerance.

Disadvantages:
It is difficult to communicate with technically unsophisticated customers.
It is difficult to convert all specifications into mathematical notations.

24
Aspect-Oriented Software Development (AOSD)
AOSD is a software design solution that helps to address the modularity issues that
are not properly resolved by other software approaches like procedural, structured
and object oriented programming.
Aspect-oriented software development (AOSD), often referred to as aspect-oriented
programming (AOP).

Aspect-oriented software development focuses on the identification, specification and

representation of cross-cutting concerns and their modularization into separate functional
units as well as their automated composition into a working system.
Used in conjunction with other approaches like object-oriented software engineering.

The separation of concerns

The principle of separation of concerns states that software should be organised so that each
program element does one thing and one thing only.
● Each program element should therefore be understandable without reference to other
elements.
● Program abstractions (subroutines, procedures, objects, etc.) support the separation of
concerns.

Concerns
Concerns are not program issues but reflect the system requirements and the priorities of the
system stakeholders.
• Examples of concerns are performance, security, specific functionality, etc.

Stakeholder concerns
 Functional concerns which are related to specific functionality to be included in a system.
● Quality of service concerns which are related to the non-functional behaviour of a system.
● Policy concerns which are related to the overall policies that govern the use of the system.

25
● System concerns which are related to attributes of the system as a whole such as its
maintainability or its configurability.
● Organizational concerns which are related to organizational goals and priorities such as
producing a system within budget, making use of existing software assets or maintaining the
reputation of an organization.

Cross-cutting concerns
Cross-cutting concerns are concerns whose implementation cuts across a number of program
components.
● This results in problems when changes to the concern have to be made the code to be changed
is not localized but is in different places across the system.

Aspects, join points and pointcuts

 An aspect is an abstraction which implements a concern.
 It includes information where it should be included in a program.
 A join point is a place in a program where an aspect may be included (woven).
 A pointcut defines where (at which join points) the aspect will be included in the
program.

Software engineering with aspects

 Aspects were introduced as a programming concept but, as the notion of concerns comes
from requirements, an aspect oriented approach can be adopted at all stages in the system
development process.
 The architecture of an aspect-oriented system is based around a core system plus
extensions.
 The core system implements the primary concerns. Extensions implement secondary and
cross-cutting concerns.

Types of extension
Secondary functional extensions ->Add extra functional capabilities to the core system

26
Policy extensions-> Add functional capabilities to support an organizational policy such as
security
QoS extensions -> Add functional capabilities to help attain quality of service requirements
Infrastructure extensions-> Add functional capabilities to support the implementation of the
system on some platform

An AOSD process

Capability Maturity Model Integration(CMMI)

• Capability Maturity Model Integration is a bench-mark for measuring the maturity
of an organization‘s software process.
• CMMI is a process improvement model
• Capability Maturity Model Integration is an industry framework to improve product
quality and development efficiency for both hardware and software.
• It is a methodology used to develop and refine an organization‘s software
development process.
• CMMI can be used to assess an organization against five process maturity levels.
• Five process maturity levels are used to describe the maturity of the organization.
• CMMI provides a way to focus and manage hardware and software development
and maintenance.

27
 Level One:Initial
 Level One deals with performed processes.
 Performed processes are unpredictable, poorly controllable.

Level Two: Managed

 Level 2 deals with managed process.
 Managed process are performed processes that
 Are planned and executed in accordance with policy.
 Employs skilled people.
 Stakeholders are involved.
 Controlled outputs are produced.
 Adequate resources are available.

Level Three: Defined

 Level 3 deals with defined processes.
 Defined processes are managed process that are well defined, understood,
deployed and executed across the entire organization.
28
 Level Four: Quantitatively managed
 Projects are done based on the organization standards.

Level Five: Optimizing

 This level focuss on process improvement.

Advantage:
 Cost saving in terms of lesser effort due to less defects and less rework
 On-Time Deliveries
 Increased Customer Satisfaction
 Overall increased Return on Investment
 Decreased Costs
 Improved Productivity
Disadvantage:
 It may not be suitable for every organization.
 It may add overhead in terms of documentation.
 May require a considerable amount of time and effort for implementation.

INTRODUCTION TO AGILITY
Agile Process:
Agile software development refers to a group of software development methodologies based
on iterative development, where requirements and solutions evolve through collaboration
between self-organizing cross-functional teams.
The ultimate value in Agile development is that it enables teams to deliver value faster, with
greater quality and predictability, and greater aptitude to respond to change.
The Agile methodology is a way to manage a project by breaking it up into several phases.
It involves constant collaboration with stakeholders and continuous improvement at every
stage.
Once the work begins, teams cycle through a process of planning, executing, and evaluating.

29
 Continuous collaboration is vital, both with team members and project stakeholders.

Agile's four main values are:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

EXTREME PROGRAMMING
Definition:
Extreme Programming (XP) is an agile software development framework that aims to
produce higher quality software, and higher quality of life for the development team.
Extreme Programming emphasizes teamwork. Managers, customers, and developers are
all equal partners in a collaborative team.

Advantages:
Extreme Programming solves the following problems often faced in the software development
projects.
• Slipped schedules − and achievable development cycles ensure timely deliveries.
• Cancelled projects − Focus on continuous customer involvement ensures transparency
with the customer and immediate resolution of any issues.
• Costs incurred in changes − Extensive and ongoing testing makes sure the changes do
not break the existing functionality. A running working system always ensures sufficient time
for accommodating changes such that the current operations are not affected.
• Misunderstanding the business and/or domain − Making the customer a part of the
team ensures constant communication and clarifications.
• Business changes − Changes are considered to be inevitable and are accommodated at
any point of time.
• Staff turnover − Intensive team collaboration ensures enthusiasm and good will.

30
Extreme Programming Values
Extreme Programming (XP) is based on the five values −
 Communication
 Simplicity
 Feedback
 Courage
 Respect

Communication
Communication plays a major role in the success of a project. Problems with projects
often arise due to lack of communication. Many circumstances may lead to the
breakdown in communication.
Some of the common problemsare −
 A developer may not tell someone else about a critical change in the design.
 A developer may not ask the customer the right questions, and so a critical domain
decision is blown.
 A manager may not ask a developer the right question, and project progress is
misreported.
 A developer may ignore something important conveyed by the customer.
Extreme Programming emphasizes continuous and constant communication among the
team members, managers and the customer.

Simplicity
Extreme Programming believes in ‘it is better to do a simple thing today and pay a
little more tomorrow to change it’ than ‘to do a more complicated thing today that may
never be used anyway’.
 Do what is needed and asked for, but no more.
 ''Do the simplest thing that could possibly work'' The DTSTTCPW principle.
 Implement a new capability in the simplest possible way. Also known as the KISS principle
‘Keep It Simple, Stupid!’

31
 Take small simple steps to your goal and mitigate failures as they happen.
 Never implement a feature you do not need now i.e. You Aren‘t Going to Need It‘
(YAGNI) principle.

Feedback
Every iteration commitment is taken seriously by delivering working software. The
software is delivered early to the customer and a feedback is taken so that necessary
changes can be made if needed.
In Extreme Programming, feedback is ensured at all levels at different time scales −
 Customers tell the developers what features they are interested in so that the
developers can focus only onthose features.
 Unit tests tell the developers the status of the system.
 The system and the code provide feedback on the state of development to the
managers, stakeholders andthe customers.
 Frequent releases enable the customer to perform acceptance tests and provide
feedback and developers towork based on that feedback.
 When the customers write new features/user stories, the developers estimate the
time required to deliver the changes, to set the expectations with the customer and
managers.

Courage
Extreme Programming provides courage to the developers in the following way −
 To focus on only what is required
 To communicate and accept feedback
 To tell the truth about progress and estimates
 To refactor the code
 To adapt to changes whenever they happen
 To throw the code away (prototypes)

32
Respect
Respect is a deep value, one that lies below the surface of the other four values.

In Extreme Programming,
 Everyone respects each other as a valued team member.
 Everyone contributes value such as enthusiasm.
 Developers respect the expertise of the customers and vice versa.
 Management respects the right of the developers to accept the responsibility and receive
authority over their own work.

Extreme Programming Principles

The fundamental principles of Extreme Programming are −
 Rapid feedback
 Assume simplicity
 Incremental change
 Embracing change
 Quality work

Rapid Feedback
Rapid feedback is to get the feedback, understand it, and put the learning back into the
system as quickly as possible.
 The developers design, implement and test the system, and use that feedback in
seconds or minutes insteadof days, weeks, or months.
 The customers review the system to check how best it can contribute, and give
feedback in days or weeksinstead of months or years.

Assume Simplicity
Assume Simplicity means do a good job of solving today's job today and trust your
ability to add complexity in the future where you need it.
‘In Extreme Programming, you are told to do a good job (tests, refactoring, and

33
communication) focusing on what is important today.
 With good unit tests, you can easily refactor your code to do additional tests.
 Follow YAGNI.
 Follow the DRY(Don‘t Repeat Yourself) principle.
 For example,
 Do not have multiple copies of identical (or very similar) code.
 Do not have redundant copies of information.
 No wastage of time and resources on what may not be necessary.

Incremental Change
In any situation, big changes made all at once just do not work. Any problem is
solved with a series of the smallestchange that makes a difference.
In Extreme Programming, Incremental Change is applied in many ways.
 The design changes a little at a time.
 The plan changes a little at a time.
 The team changes a little at a time.

Embracing Change
The best strategy is the one that preserves the most options while actually solving your most
pressing problem.

Quality Work
Everyone likes doing a good job. They try to produce the quality that they are proud of. The
team
 Works well
 Enjoys the work
 Feels good in producing a product of value

Activities in Extreme Programming:

There are four basic activities in Extreme Programming.

34
 They are −
 Coding
Coding is the phase during which the actual code is created by implementing specific XP
practices such as coding standards, pair programming, continuous integration, and collective
code ownership
 Testing
Testing is the core of extreme programming. It is the regular activity that involves both unit
tests and acceptance tests
 Listening
Listening is all about constant communication and feedback.
 Designing
Designing is actually a part of the planning process. A good design brings logic and
structure to the system and allows avoiding unnecessary complexities and redundancies.

EXTREME PROGRAMMING PROCESS CYCLE

Extreme Programming is iterative and incremental and is driven by Time-Boxed
Cycles.
Extreme Programming has the following activity levels −
 Product Life Cycles
 Releases
 Iterations
 Tasks
 Development
 Feedback

Product Life Cycles

 This is also referred to as the Exploration phase.
 Product life cycle activities provide inputs for release cycles.

35
 Releases
This is also referred to as the Commitment phase.
 Release planning sessions provide inputs for iteration cycles.
In this activity −
The whole team gathers so that −
 Progress is reviewed.
 New requirements can be added and/or existing requirements can be changed or
removed.
 Customer presents stories.
 Stories are discussed.
Iterations
 This is also referred to as the Steering phase.
 Iteration planning sessions provide inputs for task cycles.
 The iteration Plan is the primary deliverable of this activity.
Tasks
 Task development provides inputs for development episodes.
 The developers Sign- up for the tasks and begin development episodes to
implement the stories. They ensure the tasks for the iteration are complete. The
developers also ensure that the stories for the iteration are complete with
acceptance tests.
Development
 Development produces the product.
Feedback
 Pairs constantly communicate within themselves and outward to the team as
well. On-line customer is also involved in the communication on a continuous
basis.

36
 PANIMALAR INSTITUTE OF TECHNOLOGY
DEPARTMENT OF INFORMATION TECHNOLOGY
CS8494- SOFTWARE ENGINEERING
LECTURE NOTES

SYLLABUS
UNIT II
REQUIREMENTS ANALYSIS AND SPECIFICATION
Software Requirements: Functional and Non-Functional, User requirements, System requirements, Software
Requirements Document – Requirement Engineering Process: Feasibility Studies, Requirements elicitation
and analysis, requirements validation, requirements management-Classical analysis: Structured system
Analysis, Petri Nets- Data Dictionary.

2.1 Software Requirements

2.2 Functional and Non-Functional Requirements
2.2.1 Functional requirements
2.2.2 Non – Functional Requirements
2.2.3 Requirements Specification
2.2.4 User Requirements
2.2.5 System Requirements
2.2.6 The Software Requirements Document
2.3 Requirement Engineering Process
2.3.1 Feasibility Studies
2.3.2 Requirements Elicitation and Analysis
2.3.3 Requirements Validation
2.3.4 Requirements Management
2.4 Classical analysis
2.4.1 Structured system Analysis
2.4.2 Petri Nets
2.5 Data Dictionary.

2.1 Software Requirements

Software Requirements: It is a field within software engineering that deals with establishing
the needs of stakeholders that are to be solved by software.
The requirements for a system are the descriptions of what the system should do— the
services that it provides and the constraints on its operation. These requirements reflect the needs of
customers for a system that serves a certain purpose such as con-trolling a device, placing an order, or
finding information. The process of finding out, analyzing, documenting and checking these services
and constraints is called requirements engineering (RE).
Types of requirements:

Types of requirements

User requirements System requirements Software specification

(i) User Requirements:

•User requirements are statements, in a natural language plus diagrams, of what services the
system is expected to provide to system users and the constraints under which it must operate.
•It is written for customers.

(ii) System requirements:

 System requirements are more detailed descriptions of the software system’s functions,
services, and operational constraints.
 The system requirements document (sometimes called a functional specification)
should define exactly what is to be implemented.

(iii) Software specification:

It is a detailed software description that can serve as a basic for design and implementation. Itis
written for software developers.
2.2 Functional and Non-Functional Requirements

2.2.1 Functional requirements

 The functional requirements for a system describe what the system should do.
 These are statements of services the system should provide, how the system should react to
particular inputs, and how the system should behave in particular situations.
 For example, functional requirements for the MHC-PMS system, used to maintain information
about patients receiving treatment for mental health problems:
1. A user shall be able to search the appointments lists for all clinics.
2. The system shall generate each day, for each clinic, a list of patients who are expected to
attend appointments that day.
3. Each staff member using the system shall be uniquely identified by his or her eight-digit
employee number.

2.2.2 Non – Functional Requirements

 Non-functional requirements are requirements that are not directly concerned with the specific
services delivered by the system to its users.
 They may define constraints on the system implementation such as the capabilities of I/O
devices or the data representations used in inter-faces with other systems.
 Non-functional requirements, such as performance, security, or availability, usually specify or
constrain characteristics of the system as a whole. Failing to meet a non-functional requirement can
mean that the whole system is unusable.
 For example, if an aircraft system does not meet its reliability requirements, it will not be certified
as safe for operation; if an embedded control system fails to meet its performance requirements, the
control functions will not operate correctly.
 Fig: Types of Non-Functional Requirements

1. Product requirements - These requirements specify or constrain the behavior of the software.
Examples include performance requirements on how fast the system must execute and how
much memory it requires, reliability requirements that set out the acceptable failure rate,
security requirements, and usability requirements.
2. Organizational requirements - These requirements are broad system requirements derived
from policies and procedures in the customer’s and developer’s organization.
Examples include operational process requirements that define how the sys-tem will be used,
development process requirements that specify the programming language, the development
environment or process standards to be used, and environmental requirements that specify the
operating environment of the system.
3. External requirements - Requirements that are derived from factors external to the system and
its development process. These may include regulatory requirements that set out what must be
done for the sys-tem to be approved for use by a regulator, such as a central bank; legislative
requirements that must be followed to ensure that the system operates within the law; and
ethical requirements that ensure that the system will be acceptable to its users and the general
public.
 Fig: Examples of Non – Functional Requirements

Figure shows examples of product, organizational, and external requirements taken from the MHC-
PMS.

Fig: Metrics for Specifying Non – Functional Requirements

Domain Requirements

 Domain requirements are derived from the application domain of the system rather than from
the specific needs of system users.
 Domain requirements reflect the environment in which the system operates so, when we talk
about an application domain we mean environments such as train operation, medical records,
e-commerce etc.
 Domain requirements are important because they often reflect fundamentals of the application
domain. If these requirements are not satisfied, it may be impossible to make the system work
satisfactorily.
2.2.3 Requirements Specification

 Requirements specification is the process of writing down the user and system requirements in
a requirements document.
 Ideally, the user and system requirements should be clear, unambiguous, easy to understand,
complete, and consistent.

Fig: Ways of Writing a System Requirements Specification

2.2.4 User Requirements

 The user requirements for a system should describe the functional and non-functional
requirements so that they are understandable by system users without detailed technical
knowledge.
 They should only specify the external behavior of the system and should avoid system design
characteristics.
 Various problems can arise when requirements are written in natural language sentences in a
text document:

1. Lack of clarity - It is sometimes difficult to use language in a precise and unambiguous way
without making the document wordy and difficult to read.
2. Requirements confusion - Functional requirements, non-functional requirements, system goals
and design information may not be clearly distinguished.
3. Requirements amalgamation - Several different requirements may be expressed together as a
single requirement.
Figure 1 illustrates this confusion. This example is taken from an actual requirements document for a
CASE tool for editing software design models. The user may specify that a grid should be displayed so
that entities may be accurately positioned in a diagram.

Fig:1 A user Requirements for an Editor Grid

Figure 2 illustrates how these guidelines may be used. It includes two requirements for the embedded
software for the automated insulin pump

Fig: 2 Example Requirements for the Insulin Pump Software System

2.2.5 System Requirements

 System requirements are expanded versions of the user requirements that are used by software
engineers as the starting point for the system design.
 They add detail and explain how the user requirements should be provided by the system.
 Ideally, the system requirements should simply describe the external behavior of the system
and its operational constraints. They should not be concerned with how the system should be
designed or implemented.
 Fig:3 System Requirements Specification using a Standard Form

2.2.6 The Software Requirements Document

The software requirements document (sometimes called the software requirements specification or
SRS) is an official statement of what the system developers should implement.
It should include both the user requirements for a system and a detailed specification of the system
requirements.

Fig 5: Users of a Requirements Document

STRUCTURE OF SRS
1. Introduction
1.1 Purpose
1.2 Scope
1.3 Overview
2. General Description
2.1 User Manual
3. Functional Requirements
3.1 Description
3.2 Technical Issues
4. Interface Requirements
4.1 GUI
4.2 Hardware Interface
4.3 Software Interface
5. Performance Requirements
6. Design Constraints
7. Other Non functional Attributes
7.1 Security
7.2 Reliability
7.3 Availability
7.4 Maintainability
7.5 Reusability
8. Operational Scenarios
9. Preliminary Schedule

Example: SRS Document for Attendance Management System

1. INTRODUCTION
1.1 Purpose
The purpose of developing attendance management system is to computerized the tradition way of
taking attendance. Another purpose for developing this software is to generate the report automatically
at the end of the session or in the between of the session. The purpose of this document is that the
requirements mentioned in it should be utilized by software developer to implement the system.
1.2 Scope
This system allows the teacher to maintain attendance record of the classes to which it is teaching.
With the help of this system Teacher should be in a position to send e-mail to the students who remain
absent for the class. The system provides a cumulative report at every month end for the corresponding
class.
1.3 Overview
This system provides an easy solution to the teacher to keep track of student attendance, and statistics

2. General Description
This attendance maintenance system replaces the traditional, manual attendance system by which a lot
of paper work will be reduced. The teacher should able to view photograph of student along with his
attendance in his laptop. This is the primary feature of this system. Another feature is that Teacher can
be allowed to edit particular record at desired time. The system should produce monthly attendance
report. And there should be facility to send an e-mail/warning to the student remaining absent in the
class. Every Teacher should have laptop with wireless internet connection. A teacher may teach to
different classes and a separate record for the corresponding classes should be maintained.

2.1 User manual

The system should provide Help option in which how to operate the system should be explained. Also
hard copy of this document should be given to the user in a booklet form.

3. FUNCTIONAL REQUIREMENTS
The identity of student is verified and then marked present at particular date and time. The system
should display student photograph along with their names for the corresponding class. The student
may be marked present or absent students. A statistical report should display individuals report or a
cumulative report whenever required.
3.1 Description
The identity of student is verified and then marked present at particular date and time. The system
should display student photograph along with their names for that corresponding class. The student
may be marked present or absent depending upon his display individuals report or a cumulative report
whenever requirement.
3.2 Technical Issues
The system should be implemented in VC++.

4. Interface Requirements
4.1 GUI
GUI 1: Main menu should provide option such as File, Edit, Report, help.
GUI 2: In File menu one can create a new record file or can open an existing record file.. GUI 3: The
display of record
GUI 4: Report option should display statistical report. It may be particular student or for the whole
class.
GUI 5: Help option should describe functionality of the system. It should be written in simple HTML.
4.2 Hardware Interface
Hardware Interface 1: The system should be embedded in the laptops.
Hardware Interface 2: The laptop should use wireless Ethernet Card to send departmental database
server.
4.3 Software Interface:
Software Interface 1 : Attendance maintenance system.

Software Interface 2 : The attendance database should be transmitted to departmental database server.
Software Interface 3 : E-mail message generator which generates standard message of absence.
Software Interface 4 : Report generators.

5. Performance Requirements
• This system should work concurrently on multiple processors between college hours. The
system should support 50 users.
• The email should be send within one hour after class gets over.
• The system should support taking attendance of maximum 10 students per class.
6. Design Constraints
The system should be designed within 6 months.

7. Other Non Functional Attributes

7.1 Security
The teacher should provide password to log on to the system.He/she should be able to see the record of
his/her class.
7.2 Reliability
Due to wireless connectivity, reliability cannot be guaranteed.
7.3 Availability
The system should be available during college hours.
7.4 Maintainability
There should be a facility to add or delete or update teachers and students for each semester
7.5 Reusability
There should be a facility to add or delete or update teachers and students for each semester.
8. Operational Scenarios:

There will be student database, teacher database. The student database will contain students name,
class, attendance, email address, address, and phone number. The teacher database will contain
teachers name, class taught, e-mail address, phone number.

9. Preliminary Schedule
The system has to be implemented within 6 months.

2.3 Requirement Engineering Process

 The goal of the requirements engineering process is to create and maintain a system
requirements document.
 The overall process includes four high-level requirements engineering sub-processes.
 These are concerned with assessing whether the system is useful to the business (feasibility
study); discovering requirements (elicitation and analysis); converting these requirements into
some standard form (specification); and checking that the requirements actually define the
system that the customer wants (validation).

The below figure illustrates the relationship between these activities. It also shows the documents
produced at each stage of the requirements engineering process. The activities are concerned with the
discovery, documentation and checking of requirements.
 Fig: The Requirements Engineering Process

An alternative perspective on the requirements engineering process is presented in figure. This

presents the process as a three-stage activity where the activities are organized as an iterative process
around a spiral.

Fig: Spiral Model of Requirements Engineering Processes

2.3.1 Feasibility Studies

 For all new systems, the requirements engineering process should start with a feasibility study.
 The input to the feasibility study is a set of preliminary business requirements, an outline
description of the system and how the system is intended to support business processes.
 The results of the feasibility study should be a report that recommends whether or not it is
worth carrying on with the requirements engineering and system development process.

 A feasibility study is a short, focused study that aims to answer a number of questions:
1. Does the system contribute to the overall objectives of the organization?
2. Can the system be implemented using current technology and within given cost and
schedule constraints?
3. Can the system be integrated with other systems which are already in place?

2.3.2 Requirements Elicitation and Analysis

 After an initial feasibility study, the next stage of the requirements engineering process is
requirements elicitation and analysis.
 In this activity, software engineers work with customers and system end-users to find out about
the application domain, what services the system should provide, the required performance of
the system, hardware constraints, and so on.

 Requirements elicitation and analysis may involve a variety of different kinds of people in an
organization.
 A system stakeholder is anyone who should have some direct or indirect influence on the
system requirements.
 Stakeholders include end-users who will interact with the system and anyone else in an
organization who will be affected by it.
 Other system stakeholders might be engineers who are developing or maintaining other related
systems, business managers, domain experts, and trade union representatives.

Fig: The Requirements Elicitation and Analysis Process

The process activities are:

 1. Requirements discovery - This is the process of interacting with stakeholders of the
system to discover their requirements.
2. Requirements classification and organization - This activity takes the unstructured
collection of requirements, group’s related requirements, and organizes them into
coherent clusters.
3. Requirements prioritization and negotiation - When multiple stake-holders are
involved, requirements will conflict. This activity is concerned with prioritizing
requirements and finding and resolving requirements conflicts through negotiation.
4. Requirements specification - The requirements are documented and input into the next
round of the spiral.

Eliciting and understanding requirements from system stakeholders is a difficult process for several
reasons:

1. Stakeholders often don’t know what they want from a computer system except in the most
general terms; they may find it difficult to articulate what they want the system to do; they
may make unrealistic demands because they don’t know what is and isn’t feasible.
2. Stakeholders in a system naturally express requirements in their own terms and with
implicit knowledge of their own work.

3. Different stakeholders have different requirements and they may express these in different
ways. Requirements engineers have to discover all potential sources of requirements and
discover commonalities and conflict.
4. Political factors may influence the requirements of a system.

5. The economic and business environment in which the analysis takes place is dynamic.

Requirements Discovery

 Requirements discovery is the process of gathering information about the required system and
existing systems, and distilling the user and system requirements from this information.
 Sources of information during the requirements discovery phase include documentation,
system stakeholders, and specifications of similar systems.

Viewpoints

A viewpoint is a way of organizing the requirements for a software system, based on some perspective
such as an end-user perspective or a manager's perspective.

There are three generic types of viewpoint:

1. Interactor viewpoints that represent people or other systems that interact directly with the
system. In the bank ATM system, examples of interactor viewpoints are the bank’s customers
and the bank’s account database.
2. Indirect viewpoints that represent stakeholders who do not use the system themselves but who
influence the requirements in some way. In the bank ATM system, examples of indirect
viewpoints are the management of the bank and the bank security staff.
 3. Domain viewpoints that represent domain characteristics and constraints that influence the
system requirements. In the bank ATM system, an example of a domain viewpoint would be
the standards that have been developed for inter-bank communications.

Fig: Viewpoint Hierarchy for Library System

Interactor viewpoints represent stakeholders that interact directly with the system; indirect viewpoints
represent stakeholders that are affected by the system but who are not end-users; domain viewpoints
represent requirements that come from the application domain.

Interviewing

 Formal or informal interviews with system stakeholders are part of most requirements
engineering processes.
 In these interviews, the requirements engineering team puts questions to stakeholders about the
system that they currently use and the system to be developed.
 Requirements are derived from the answers to these questions.

Interviews may be of two types:

1. Closed interviews, where the stakeholder answers a pre-defined set of questions.

2. Open interviews, in which there is no pre-defined agenda. The requirements
engineering team explores a range of issues with system stakeholders and hence
develops a better understanding of their needs.

Scenarios
 Scenarios can be particularly useful for adding detail to an outline requirements description.
 A scenario starts with an outline of the interaction.
  During the elicitation process, details are added to this to create a complete description of that
interaction.
 A scenario may include:

1. A description of what the system and users expects when the scenario starts.
2. A description of the normal flow of events in the scenario.
3. A description of what can go wrong and how this is handled.
4. Information about other activities that might be going on at the same time.
5. A description of the system state when the scenario finishes.

Scenario-based elicitation involves working with stakeholders to identify scenarios and to capture
details to be included in these scenarios.
Scenarios may be written as text, supplemented by diagrams, screen shots, etc.

As an example of a simple text scenario, consider how the MHC-PMS may be used to enter data for a
new patient shown in figure. When a new patient attends a clinic, a new record is created by a medical
receptionist and personal information (name, age, etc.) is added to it. A nurse then interviews the
patient and collects medical history. The patient then has an initial consultation with a doctor who
makes a diagnosis and, if appropriate, recommends a course of treatment. The scenario shows what
happens when medical history is collected.

Fig: Scenario for Collecting Medical History in MHC-PMS

Use-Cases
Use cases are documented using a high-level use case diagram. The set of use cases represents all of
the possible interactions that will be described in the system requirements. Actors in the process, who
may be human or other systems, are represented as stick figures. Each class of interaction is
represented as a named ellipse. Lines link the actors with the interaction.

Fig: Use-Cases for the MHC-PMS

Ethnography
Ethnography is an observational technique that can be used to understand operational processes and
help derive support requirements for these processes.
Ethnography is particularly effective for discovering two types of requirements:
1. Requirements that are derived from the way in which people actually work, rather than the
way in which process definitions say they ought to work. For example, air traffic
controllers may switch off a conflict alert system that detects aircraft with intersecting
flight paths, even though normal control procedures specify that it should be used.

2. Requirements that are derived from cooperation and awareness of other people’s activities.
For example, air traffic controllers may use an awareness of other controllers’ work to
predict the number of aircrafts that will be entering their control sector. They then modify
their control strategies depending on that predicted workload. Therefore, an automated
ATC system should allow controllers in a sector to have some visibility of the work in
adjacent sectors.

Fig: Ethnography and Prototyping for Requirements Analysis

Ethnography can be combined with prototyping. The ethnography informs the development of the
prototype so that fewer prototype refinement cycles are required. Furthermore, the prototyping focuses
the ethnography by identifying problems and questions that can then be discussed with the
ethnographer.

2.3.3 Requirements Validation

Requirements validation is the process of checking that requirements actually define the system that
the customer really wants.
Requirements validation is important because errors in a requirements document can lead to extensive
rework costs when these problems are discovered during development or after the system is in service.
During the requirements validation process, different types of checks should be carried out on the
requirements in the requirements document. These checks include:

1. Validity checks - A user may think that a system is needed to perform certain functions.
However, further thought and analysis may identify additional or different functions that
are required. Systems have diverse stakeholders with different needs and any set of
requirements is inevitably a compromise across the stake-holder community.
2. Consistency checks - Requirements in the document should not conflict. That is, there
should not be contradictory constraints or different descriptions of the same system
function.
3. Completeness checks - The requirements document should include requirements that define
all functions and the constraints intended by the system user.
4. Realism checks - Using knowledge of existing technology, the requirements should be
checked to ensure that they can actually be implemented. These checks should also take
account of the budget and schedule for the system development.
5. Verifiability - To reduce the potential for dispute between customer and contractor, system
requirements should always be written so that they are verifiable. This means that you
should be able to write a set of tests that can demonstrate that the delivered system meets
each specified requirement.

There are a number of requirements validation techniques that can be used individually or in
conjunction with one another:

1. Requirements reviews - A requirements review is a manual process that involves people from
both client and contractor organizations.
They check the requirements document for anomalies and omissions. The review process may
be managed in the same way as program inspections.
Requirements reviews can be informal or formal. Informal reviews simply involve contractors
discussing requirements with as many system stakeholders as possible.
In a formal requirements review, the development team should ‘walk’ the client through the
system requirements explaining the implications of each requirement. The review team should
check each requirement for consistency and should check the requirements as a whole for
completeness.
2. Prototyping - In this approach to validation, an executable model of the system in question is
 demonstrated to end-users and customers. They can experiment with this model to see if it
meets their real needs.
3. Test-case generation - Requirements should be testable. If the tests for the requirements are
devised as part of the validation process, this often reveals requirements problems. If a test is
difficult or impossible to design, this usually means that the requirements will be difficult to
implement and should be reconsidered.

2.3.4 Requirements Management

The requirements for large software systems are always changing. One reason for this is that these
systems are usually developed to address ‘wicked’ problems—problems that cannot be completely
defined. Because the problem cannot be fully defined, the soft-ware requirements are bound to be
incomplete.
During the software process, the stake-holders’ understanding of the problem is constantly changing.
The system requirements must then also evolve to reflect this changed problem view.

Once a system has been installed and is regularly used, new requirements inevitably emerge. It is hard
for users and system customers to anticipate what effects the new system will have on their business
processes and the way that work is done.

Requirements management is the process of understanding and controlling changes to system

requirements.

Enduring and Volatile Requirements

Requirements evolution during the RE process and after a system has gone into service is inevitable.
Developing software requirements focuses attention on software capabilities, business objectives and
other business systems. As the requirements definition is developed, you normally develop a better
understanding of users’ needs. This feeds information back to the user who may then propose a change
to the requirements. Furthermore, it may take several years to specify and develop a large system.
Over that time, the system’s environment and the business objectives change and the requirements
evolve to reflect this.

Fig: Requirements Evolution

From an evolution perspective, requirements fall into two classes:

 1. Enduring requirements - These are relatively stable requirements that derive from the
core activity of the organization and which relate directly to the domain of the system.
For example, in a hospital there will always be requirements concerned with patients,
doctors, nurses, treatments, etc. These requirements may be derived from domain
models that show the entities and relations which characterize an application domain.

2. Volatile requirements - These are requirements that are likely to change during the
system development process or after the system have been become operational.
Examples of volatile requirements are requirements resulting from government health-
care policies or healthcare charging mechanisms.

Harker and others (Harker et al., 1993) suggested that volatile requirements fall into five classes as
shown in the following table:

Requirement
Description
type
Requirements that change because of changes to the environment in which
Mutable the organization is operating. For example, in hospital systems, the
requirements funding of patient care may change and thus require different treatment
information to be collected.
Requirements that emerge as the customer's understanding of the system
Emergent
develops during the system development. The design process may reveal
requirements
new emergent requirements.
Requirements that result from the introduction of the computer system.
Consequential Introducing the computer system may change the organizations processes
requirements and open up new ways of working which generate new system
requirements.
Requirements that depend on the particular systems or business processes
Compatibility
within an organization. As these change, the compatibility requirements on
requirements
the commissioned or delivered system may also have to evolve.

Requirement Management Planning

Planning is an essential first stage in the requirements management process. The planning stage
establishes the level of requirements management detail that is required. During the requirements
management stage, you have to decide on:

1. Requirements identification - Each requirement must be uniquely identified so that it can be

cross-referenced with other requirements and used in traceability assessments.
2. A change management process - This is the set of activities that assess the impact and cost of
changes.
3. Traceability policies - These policies define the relationships between each requirement and
between the requirements and the system design that should be recorded. The traceability
 policy should also define how these records should be maintained.
4. Tool support - Requirements management involves the processing of large amounts of
information about the requirements. Tools that may be used range from specialist requirements
management systems to spreadsheets and simple database systems.

Traceability is the property of a requirements specification that reflects the ease of finding related
requirements.

There are three types of traceability information that may be maintained:

1. Source traceability information links the requirements to the stakeholders who proposed
the requirements and to the rationale for these requirements. When a change is proposed,
you use this information to discover the stakeholders so that they can be consulted about
the change.
2. Requirements traceability information links dependent requirements within the
requirements document. You use this information to assess how many requirements are
likely to be affected by a proposed change and the extent of consequential requirements
changes that may be necessary.
3. Design traceability information links the requirements to the design modules where these
requirements are implemented. You use this information to assess the impact of proposed
requirements changes on the system design and implementation.

Requirements management needs automated support and the software tools for this should be chosen
during the planning phase. You need tool support for:

1. Requirements storage - The requirements should be maintained in a secure, man-aged data

store that is accessible to everyone involved in the requirements engineering process.
2. Change management - The process of change management (Figure 2.23) is simplified if active
tool support is available.
3. Traceability management - As discussed above, tool support for traceability allows related
requirements to be discovered. Some tools are available which use natural language processing
techniques to help discover possible relation-ships between requirements.

Requirement Change Management

Change management is essential because you need to decide if the benefits of implementing new
requirements are justified by the costs of implementation. The advantage of using a formal process for
change management is that all change proposals are treated consistently and changes to the
requirements document are made in a controlled way.

Fig: Requirements Change Management

There are three principal stages to a change management process:

1. Problem analysis and change specification - The process starts with an identified requirements
problem or, sometimes, with a specific change proposal. During this stage, the problem or the
change proposal is analyzed to check that it is valid. This analysis is fed back to the change
requestor who may respond with a more specific requirements change proposal, or decide to
withdraw the request.
2. Change analysis and costing - The effect of the proposed change is assessed using traceability
information and general knowledge of the system requirements. The cost of making the change
is estimated both in terms of modifications to the requirements document and, if appropriate, to
the system design and implementation. Once this analysis is completed, a decision is made
whether or not to proceed with the requirements change.
3. Change implementation - The requirements document and, where necessary, the system design
and implementation, are modified. You should organize the requirements document so that you
can make changes to it without extensive rewriting or reorganization. As with programs,
changeability in documents is achieved by minimizing external references and making the
document sections as modular as possible. Thus, individual sections can be changed and
replaced without affecting other parts of the document.

2.4 Classical analysis

Structured System Analysis:

DATA FLOW DIAGRAM:

• DFD is also known as bubble chart . Its main purpose is to clarify the system requirements
and identify major transformations that will become programs in system design.
• It is the starting point of the design phase. A DFD consist of a series of bubbles joined by lines.
• The bubbles represent data transformations and the line represents data flow in the system.
• A DFD describes what data flow rather than how they are processed, so it does not depend on
hardware, software, data structure or file organization.
DFD symbols

There are mainly four symbols for DFD.

o A Square defines a source or destination of system data.

o An arrow identifies data flow, i.e.: data in motion. It is a pipeline
through whichinformation flows.
 o A circle represents a process that transforms incoming data flows into outgoing data.
o An open rectangle is a data store, ie: data at rest or a temporary repository of data.

Rules for constructing DFD:

o Processes should be named and numbered for easy reference.
o The direction of flow is from top to bottom and from left to right. Data flows
from sourceto the destination.
o Process should be numbered, if they are exploded into lower level details.
o The names of data stores, sources and destination should be in capital letters.
Process and data flow names first letter should be in capital letter.

Example 1: Data flow diagram for safe home system:

The SafeHome security function enables the homeowner to configure the security system when it is
installed, monitors all sensors connected to the security system, and interacts with the homeowner
through the Internet, a PC, or a control panel.
During installation, the SafeHome PC is used to program and configure the system. Each sensor is
assigned a number and type, a master password is programmed for arming and disarming the system,
and telephone number(s) are input for dialing when a sensor event occurs.
When a sensor event is recognized, the software invokes an audible alarm attached to the system.
After a delay time that is specified by the homeowner during system configuration activities, the
software dials a telephone number of a monitoring service, provides information about the location,
reporting the nature of the event that has been detected. The telephone number will be redialed every
20 seconds until telephone connection is obtained. The homeowner receives security information via a
control panel, the PC, or a browser, collectively called an interface. The interface displays prompting
messages and system status information on the control panel, the PC, or the browser window.

DFD level 0: Context level:

Example 2: Automated Railway Reservation
System DFD level 0

DFD level 1
DFD level 2

Example 3:Library Information System

DFD level 0
DFD level 1

DFD level 2
Example 4:Food Ordering System
DFD level 0

DFD level 1
DFD level 2
Petri Nets:

Petri nets are a well-known formal model which combines a rich mathematical theory with a
useful graphical notation.

Notations:

Consists of 4 types of components:

– Places represent possible states of the system;
– Transitions are events or actions which cause the change of state; And
– Every arc simply connects a place with a transition or a transition with a place.
– A change of state is denoted by state inside black dot.

Example:

Petri nets for traffic lights:

Advantages:
• Precise definition of problem
• Represent graphical overflow
• Useful in allocating resources to tasks

2.5 Data Dictionary

• A data dictionary is a collection of descriptions of the data objects or items in a data

model for the benefit of programmers and others who need to refer to them.
• Data dictionary contains the descriptions of all data objects consumed or produced by
the software.
It can store flowing information:
• Name the primary name of the data or control item, the data store or an external entity.
• Alias other names used for the first entry.
• Where-used/how-used a listing of the processes that use the data or control item and
how it is used (e.g., input to the process, output from the process, as a store, as an external entity.
• Content description a notation for representing content.
Supplementary information other information about data types, preset values (if known),
restrictions or limitations, and so forth.
 Example: Any reservation system:

Name : Passenger
Alias : none
Where used/how used : Passenger query (input),Ticket (ticket).
Description:
Passenger = Passenger_name + Passenger_address
Passenger _name = Passenger_last name + Passenger_First name +
Passenger_Middlename
Passenger_address = Local _address + Community_address
Local _address = House_nmae + Street_nmae
Community_address = City_name + State_nmae

Advantages:
• Support name management and avoid duplication.
• Store of linking analysis, design and implementation
• Automated tools (CASE) can be used to maintain data dictionary.