UNIT 1

1.1 Software Development Life Cycle

Software Development Life Cycle is the application of standard business practices to building
software applications. It’s typically divided into six to eight steps: Planning, Requirements,
Design, Build, Document, Test, Deploy, Maintain. Some project managers will combine, split,
or omit steps, depending on the project’s scope. These are the core components recommended
for all software development projects.

SDLC is a way to measure and improve the development process. It allows a fine-grain
analysis of each step of the process. This, in turn, helps companies maximize efficiency at
each stage. As computing power increases, it places a higher demand on software and
developers. Companies must reduce costs, deliver software faster, and meet or exceed their
customers’ needs. SDLC helps achieve these goals by identifying inefficiencies and higher
costs and fixing them to run smoothly.

1. Planning

In the Planning phase, project leaders evaluate the terms of the project. This includes
calculating labor and material costs, creating a timetable with target goals, and creating the
project’s teams and leadership structure.

Planning can also include feedback from stakeholders. Stakeholders are anyone who stands to
benefit from the application. Try to get feedback from potential customers, developers, subject
matter experts, and sales reps.

Planning should clearly define the scope and purpose of the application. It plots the course
and provisions the team to effectively create the software. It also sets boundaries to help keep
the project from expanding or shifting from its original purpose.

2. Define Requirements

Defining requirements is considered part of planning to determine what the application is

supposed to do and its requirements. For example, a social media application would require
the ability to connect with a friend. An inventory program might require a search feature.

Requirements also include defining the resources needed to build the project. For example, a
team might develop software to control a custom manufacturing machine. The machine is a
requirement in the process.

3. Design and Prototyping

The Design phase models the way a software application will work. Some aspects of the
design include:

Architecture – Specifies programming language, industry practices, overall design,

and use of any templates or boilerplate
User Interface – Defines the ways customers interact with the software, and how the
software responds to input
Platforms – Defines the platforms on which the software will run, such as Apple,
Android, Windows version, Linux, or even gaming consoles
Programming – Not just the programming language, but including methods of
solving problems and performing tasks in the application
 Communications – Defines the methods that the application can communicate with
other assets, such as a central server or other instances of the application
Security – Defines the measures taken to secure the application, and may include SSL
traffic encryption, password protection, and secure storage of user credentials

Prototyping can be a part of the Design phase. A prototype is like one of the early versions of
software in the Iterative software development model. It demonstrates a basic idea of how the
application looks and works. This “hands-on” design can be shown to stakeholders. Use
feedback o improve the application. It’s less expensive to change the Prototype phase than to
rewrite code to make a change in the Development phase.

4. Software Development

This is the actual writing of the program. A small project might be written by a single
developer, while a large project might be broken up and worked by several teams. Use an
Access Control or Source Code Management application in this phase. These systems help
developers track changes to the code. They also help ensure compatibility between different
team projects and to make sure target goals are being met.

The coding process includes many other tasks. Many developers need to brush up on skills or
work as a team. Finding and fixing errors and glitches is critical. Tasks often hold up the
development process, such as waiting for test results or compiling code so an application can
run. SDLC can anticipate these delays so that developers can be tasked with other duties.

Software developers appreciate instructions and explanations. Documentation can be a formal

process, including wiring a user guide for the application. It can also be informal, like
comments in the source code that explain why a developer used a certain procedure. Even
companies that strive to create software that’s easy and intuitive benefit from the
documentation.

Documentation can be a quick guided tour of the application’s basic features that display on
the first launch. It can be video tutorials for complex tasks. Written documentation like user
guides, troubleshooting guides, and FAQ’s help users solve problems or technical questions.

5. Testing

It’s critical to test an application before making it available to users. Much of the testing can
be automated, like security testing. Other testing can only be done in a specific environment –
consider creating a simulated production environment for complex deployments. Testing
should ensure that each function works correctly. Different parts of the application should also
be tested to work seamlessly together—performance test, to reduce any hangs or lags in
processing. The testing phase helps reduce the number of bugs and glitches that users
encounter. This leads to a higher user satisfaction and a better usage rate.

6. Deployment

In the deployment phase, the application is made available to users. Many companies prefer to
automate the deployment phase. This can be as simple as a payment portal and download link
on the company website. It could also be downloading an application on a smartphone.

Deployment can also be complex. Upgrading a company-wide database to a newly-developed

application is one example. Because there are several other systems used by the database,
integrating the upgrade can take more time and effort.
7. Operations and Maintenance

At this point, the development cycle is almost finished. The application is done and being
used in the field. The Operation and Maintenance phase is still important, though. In this
phase, users discover bugs that weren’t found during testing. These errors need to be resolved,
which can spawn new development cycles.

In addition to bug fixes, models like Iterative development plan additional features in future
releases. For each new release, a new Development Cycle can be launched.

Fig.1 Phase in Software lifecycle model

2. Process
Project management process is an administration process for the planning and control of
the services or the implementation of a project
The results of one of these processes are:
1. delivery of the project product
2. achievement of the project objectives
3. documentation of the learning processes
2.2 Project Management Process consists of the following 4 stages:

⚫ Feasibility study
• Project Planning
• Project Execution
• Project Termination

Fig.1.1 Process
1.1.1 Feasibility Study
 ⚫ Feasibility study explores system requirements to determine project feasibility.
1.1.2 Project Planning
A detailed plan stating a stepwise strategy to achieve the listed objectives is an integral part of
any project. Planning consists of the following activities:
• Set objectives or goals
• Develop strategies
• Develop project policies
• Determine courses of action
• Making planning decisions
• Set procedures and rules for the project
• Develop a software project plan
• Prepare budget
• Conduct risk management

• Document software project plans

⚫ This step also involves the construction of a work breakdown structure(WBS). It also
includes size, effort, schedule, and cost estimation using various techniques.
1.1.3 Project Execution
⚫ Amodel(SDLC)
project is executed by choosing an appropriate software development lifecycle

⚫ Itandincludes a number of steps including requirements analysis, design, coding, testing

implementation, testing, delivery, and maintenance.
⚫ There are a number of factors that need to be considered while doing so including the
size of the system, the nature of the project, time and budget constraints, domain
requirements, etc.
⚫ An inappropriate SDLC can lead to the failure of the project.
1.1.4 Project Termination:
⚫ There can be several reasons for the termination of a project.
⚫ Though expecting a project to terminate after successful completion is
conventional, but at times, a project may also terminate without completion.
⚫ Projects have to be closed down when the requirements are not fulfilled according to
given time and cost constraints.
⚫ Some of the reasons for failure include:
• Fast-changing technology
• Project running out of time
• Organizational politics
• Too much change in customer requirements
 • Project exceeding budget or funds
• Once the project is terminated, a post-performance analysis is done. Also, a final
report is published describing the experiences, lessons learned, recommendations for
handling future projects.
1.2 Tailoring the Process
⚫ Tailoring is the process of referencing framework documents, standards and other
relevant sources and utilizing those elements that provide processes, tools and
techniques that are suitable for that particular organization.
⚫ It also includes modifying existing processes currently in use by the organization.
⚫ The result of tailoring is that the project management methodology will be suitable
for use in specific types of projects, and a tailored methodology will reflect the size,
complexity, and duration of the project as appropriate for the organizational context
along with adaptation to the industry within which the project is undertaken.
⚫ tailoring at two levels:
⚫ Summary
⚫ Detailed.
1.2.1 Summary-Level Tailoring
In summary-level tailoring, depending on the project characteristics, the project manager
applies overall guidelines for tailoring the standard process. That is, it provides some general
rules regarding certain types of detailed activities. To perform this step, the project manager
first identifies certain characteristics of the project. For development projects, the following
characteristics are used for tailoring:
⚫ Experience and skill level of the team and the project manager
⚫ Clarity of the requirements
⚫ Project duration
⚫ Application criticality
1.2.2 Detailed Tailoring
Detailed tailoring covers execution of activities, their review, and documentation needs.
Tailoring guidelines may specify an activity as optional, in which case the project manager
can decide whether or not to execute the activity. Similarly, preparation of some documents
may be optional, in which case the project manager decides whether or not the project needs
the document. For review, the general alternatives are Do group review, do one-person review,
or Do not review. In addition, a project manager may add some new activities or may repeat
some activities.
⚫ When detailed tailoring is finished, the sequence of activities to be performed in the
process for the project is defined. These definitions are then used to plan and schedule
activities and form the basis of project execution. The tailoring performed is
highlighted in the project plan, so the process definition and tailoring also are
reviewed when the plan is reviewed.

⚫ Process discipline is the adherence to well-thought-out and well-defined processes that

are executed daily. The rules are often related to the work of process engineers and
 local leaders, e.g. line leaders, and production supervisors. Or rather, the lack of a
particular type of work in this case.
1.3 Process Improvement Discipline
⚫ Asreducebusinesses try to accelerate growth while running lean, there’s always a desire to
costs through process improvement. Like the examples above, this could
include:
• Improving product quality
• Upgrade service quality
• Improve delivery times
• Reduce billing cycles
• Make production more efficient

1.3.1 LEAN Technology

⚫ LEAN Tech, also known as LEAN manufacturing, was a process that originated with
Toyota. It was implemented to streamline the company’s production chain and
dramatically reduce operating and overhead costs.
⚫ The key idea is to base process improvement on the customer perspective; taking the
time to understand what they value from the product and then using LEAN process
improvement to eliminate unnecessary waste, errors and other things that drive up
costs. By focusing on value, the entire process is organized to drive more of what the

customer is willing to pay for.

1
1.3.2 Six Sigma
Six Sigma is a process improvement example that focuses on achieving the maximum level
of obtainable quality within an organization. At the Six Sigma level, that is a rating of near
100% perfection (or 99.9966%).
The Six Sigma approach looks closely at the root cause of problems, defects, and variations
that reduce the effectiveness of processes. At its heart, there’s a philosophy of constant
improvement that is in place to improve results consistently and progressively until that max
level of perfection is achieved.
1.3.3 Total Quality Management (TQM)
Total quality management (TQM) is a project management technique or strategy that is
implemented to assure that an awareness of quality is embedded in all phases of the project
from conception to completion. Used in industries from manufacturing to aerospace, total
quality management requires the careful and consistent review of all phases of a project, and
the coordinated effort of all involved. Communication is key to the process. Standards must be
developed, procedures well defined, and all involved must follow strict adherence to the plan
to assure its success.
1.3.3.1 The first paradigm Total Quality Management
The first paradigm of the strategy, “total,” calls for an integrated system of dependent
variables. Here, planning is of the utmost importance. In the planning stage obstacles to
success can be identified, confronted, and conquered. Procedures for inspection, evaluating,
reporting, and rectifying anomalies are established that will assure consistency and quality
will be developed and implemented. All parties involved, from workers to management must
become familiar with the process and committed to its success.
1.3.3.2 The second paradigm Total Quality Management
The second paradigm of the total quality management (TQM) strategy, “quality,” requires that
once a standard has been established it must never be violated. This necessitates a certain
amount of cross training, so that one party along the chain of project management can spot the
errors that might have occurred at a prior stage in the process. This not only assures quality,
but also tends to inspire greater commitment and conscientiousness among the individuals
involved.
1.3.3.3 The Third paradigm Total Quality Management
The third paradigm of total quality management (TQM) is management itself. In order to
ensure success, the strategy must function as a cohesive element that unites the individual
efforts of all involved.
The system must be managed properly in order to ensure the quality of the strategy itself.
Therefore, it is the role of project management role to oversee the training of all involved in
the process, to ascertain whether the process is being strictly adhered to, and to develop and
implement corrective measures designed to rectify any problems that might divert the strategy
from its goal.
1.4 The Importance of a Disciplined Process
• A disciplined software process serves two main purposes: Helps
developers better understand what they are doing
 • Helps managers make more accurate predictions about how long a project will take
• Predictability is crucial for setting reasonable goals and planning
resource allocation.

1.4.1 Understanding
• As software developers work through a disciplined process, they
are developing a complex mental roadmap of: The values of the
client
• The concepts that are important to the client
• Software patterns for achieving the desired behavior
• Implementation methods
⚫ Common sense and experience both support the importance of this understanding.
1.4.2 Common Sense
• Suppose that a software development process has been in progress for
several months or years. Then: One of the development team members
has changed jobs so that a replacement is needed, or
• The project is behind schedule so management has allocated more
people to work on the project.
⚫ Sobeena added
new member, who knows neither the process nor the client, has
to the team.
⚫ Will he/she be as effective as the other team members?
⚫ Not likely.
1.4.3 Experience
• Brooks has discussed management problems arising from adding people
to a project that is behind schedule in order to catch up: Often, the result
is that the project slips
• further behind schedule.
• The reason: The new people do not have a mental roadmap.
• In order to acquire it, experienced team members will have to dedicate
some time to bringing them up to speed.
⚫ This may seem obvious, but managers have to go through a similar
process to learn how to manage effectively.
• A lot of facts are obvious, but that does not mean that you will see them
when they are important: You do not see things that are obvious until
you have had experiences that stress their importance.
• You also need to recognize that they are important.
 1. Classical Waterfall Model

1. Feasibility Study:
The main goal of this phase is to determine whether it would be financially and technically feasible to
develop the software.
The feasibility study involves understanding the problem and then determining the various possible
strategies to solve the problem. These different identified solutions are analyzed based on their benefits and
drawbacks, The best solution is chosen and all the other phases are carried out as per this solution strategy.
2. Requirements Analysis and Specification:
The requirement analysis and specification phase aims to understand the exact requirements of the customer
and document them properly. This phase consists of two different activities.
● Requirement gathering and analysis: Firstly all the requirements regarding the software are gathered
from the customer and then the gathered requirements are analyzed. The goal of the analysis part is
to remove incompleteness (an incomplete requirement is one in which some parts of the actual
requirements have been omitted) and inconsistencies (an inconsistent requirement is one in which
some part of the requirement contradicts some other part).
● Requirement specification: These analyzed requirements are documented in a software requirement
specification (SRS) document. SRS document serves as a contract between the development team
and customers. Any future dispute between the customers and the developers can be settled by
examining the SRS document.
3. Design:
The goal of this phase is to convert the requirements acquired in the SRS into a format that can be coded in a
programming language. It includes high-level and detailed design as well as the overall software
architecture. A Software Design Document is used to document all of this effort (SDD).
4. Coding and Unit Testing:
In the coding phase software design is translated into source code using any suitable programming language.
Thus each designed module is coded. The unit testing phase aims to check whether each module is working
properly or not.
5. Integration and System testing:
Integration of different modules is undertaken soon after they have been coded and unit tested. Integration of
various modules is carried out incrementally over several steps. During each integration step, previously
planned modules are added to the partially integrated system and the resultant system is tested. Finally, after
all the modules have been successfully integrated and tested, the full working system is obtained and system
testing is carried out on this.
System testing consists of three different kinds of testing activities as described below.
● Alpha testing: Alpha testing is the system testing performed by the development team.
● Beta testing: Beta testing is the system testing performed by a friendly set of customers.
● Acceptance testing: After the software has been delivered, the customer performs acceptance testing
to determine whether to accept the delivered software or reject it.
6. Maintenance:
Maintenance is the most important phase of a software life cycle. The effort spent on maintenance is 60% of
the total effort spent to develop a full software. There are three types of maintenance.
● Corrective Maintenance: This type of maintenance is carried out to correct errors that were not
discovered during the product development phase.
● Perfective Maintenance: This type of maintenance is carried out to enhance the functionalities of the
system based on the customer’s request.
● Adaptive Maintenance: Adaptive maintenance is usually required for porting the software to work in
a new environment such as working on a new computer platform or with a new operating system.
Advantages of Waterfall Model
● Classical waterfall model is easy to understand and simple to use.
● In the waterfall model, only one phase is executed at a time or phases cannot overlap.
● In this model, each phase is clearly defined.
● Waterfall model works best for a small project, where requirements are clearly defined.
● It has clearly understood milestones.
● Each Process, actions and results are well documented.
Disadvantages of Waterfall Model
Below are the list of Shortcomings of Waterfall Model:
1. Idealistic Model: The classical waterfall model is an idealistic one since it assumes that no
development error is ever committed by the engineers during any of the life cycle phases. However,
in practical development environments, the engineers do commit a large number of errors in almost
every phase of the life cycle.

2. Waterfall model assumes that all requirements are defined correctly at the beginning of the
 project, and on the basis of that, the development work starts. However, that is rarely the case in real
life projects. The customer keeps changing the requirements as their development proceeds. Thus, it
becomes difficult to accommodate later requirements change request made by the customer.

3. Phases are sequential: Classical waterfall model assumes, that all the phases are sequential.
However, that is rarely the case.

For example, for efficient utilization of manpower in a company, the members assigned the testing
work may start their work immediately after the requirements specification to design the system test
cases. Consequently, it is safe to say that in a practical software development scenario, the different
phases might overlap, rather than having a precise point in time at which one phase stops and the
other starts.

2. Iterative Waterfall Model

It is not possible to strictly follow the classical waterfall model for software development work. In
this context, we can view the iterative waterfall model as making necessary changes to the classical
waterfall model so that it becomes applicable to practical software development projects.

In Iterative waterfall model, the feedback paths are provided from every phase to its preceding
phase as shown in Figure
The feedback paths allow for correction of the errors committed during a phase, as and when
these are detected in a later phase.

For example, if during a testing a design error is identified, then the feedback path allows the
design to be reworked and the changes to be reflected in the design documents. However,
observe that there is no feedback path to the feasibility stage. This means that the feasibility
study errors cannot be corrected.
When to use Iterative Waterfall Model
 ● The requirement of the defined and clearly understood.
● New technology is being learned by the development team.
● There are some high risk features and goals which might in the future.
Advantages of Iterative Waterfall Model
● Feedback Path: iterative waterfall allows the mechanism of error connection because
there is a feedback path from one phase to its preceding phase which it lacks in the
Waterfall Model.
● Simple: iterative waterfall model is simple to understand and use. It is the most widely
used software development model evolved so far.
● Parallel development: can be done.

Disadvantage of Iterative Waterfall Model

● More resource: may be required to implement the iterative waterfall model.
● Difficult to include change requests: In the iterative waterfall model, all the
requirements must be clearly defined before starting of the development phase but
sometimes customer requirement changes which is difficult to incorporate change
requests that are made after development phase starts.
● Not support Intermediate delivery: Project has to be fully completed before it
delivered to the customer.
● Risk handling: Project is prone to many types of risk but there is no risk handling
mechanism.
● Not suitable for a small project.
3. Prototyping Model

Step 1: Requirement Gathering and Analysis: This is the initial step in designing a
prototype model. In this phase, users are asked about what they expect or what they want from
the system.
Step 2: Quick Design: This is the second step in the Prototyping Model. This model covers
the basic design of the requirement through which a quick overview can be easily described.
Step 3: Build a Prototype: This step helps in building an actual prototype from the
knowledge gained from prototype design.
Step 4: Initial User Evaluation: This step describes the preliminary testing where the
investigation of the performance model occurs, as the customer will tell the strengths and
weaknesses of the design, which was sent to the developer.
Step 5: Refining Prototype: If any feedback is given by the user, then improving the client’s
response to feedback and suggestions, the final system is approved.
Step 6: Implement Product and Maintain: This is the final step in the phase of the
Prototyping Model where the final system is tested and distributed to production, here the
program is run regularly to prevent failures.
When Prototyping model is used?
This model is used when the customers do not know the exact project requirements
beforehand. In this model, a prototype of the end product is first developed, tested, and refined
as per customer feedback repeatedly till a final acceptable prototype is achieved which forms
the basis for developing the final product.
Advantages of Prototyping Model
● The customers get to see the partial product early in the life cycle. This ensures a
greater level of customer satisfaction and comfort.
● New requirements can be easily accommodated as there is scope for refinement.
● Missing functionalities can be easily figured out.
● Errors can be detected much earlier thereby saving a lot of effort and cost, besides
enhancing the quality of the software.
● The developed prototype can be reused by the developer for more complicated projects
in the future.
● Flexibility in design.
● Early feedback from customers and stakeholders can help guide the development
process and ensure that the final product meets their needs and expectations.
● Prototyping can be used to test and validate design decisions, allowing for adjustments
to be made before significant resources are invested in development.
● Prototyping can help reduce the risk of project failure by identifying potential issues
and addressing them early in the process.
Disadvantages of the Prototyping Model
● Costly concerning time as well as money.
● There may be too much variation in requirements each time the prototype is evaluated
 by the customer.
● Poor Documentation due to continuously changing customer requirements.
● It is very difficult for developers to accommodate all the changes demanded by the
customer.
● There is uncertainty in determining the number of iterations that would be required
before the prototype is finally accepted by the customer.
● After seeing an early prototype, the customers sometimes demand the actual product to
be delivered soon.
● Developers in a hurry to build prototypes may end up with sub-optimal solutions.

4. Incremental development

Incremental development is based on the idea of developing an initial implementation,

exposing this to user comment and evolving it through several versions until an
adequate system has been developed (Figure 2.2). Specification, development, and
validation activities are interleaved rather than separate, with rapid feedback across
activities.
Incremental software development, which is a fundamental part of agile approaches, is
better than a waterfall approach for most business, e-commerce, and personal systems.
Incremental development reflects the way that we solve problems. We rarely work out
a complete problem solution in advance but move toward a solution in a series of
steps, backtracking when we realize that we have made a mistake. By developing the
software incrementally, it is cheaper and easier to make changes in the software as it is
being developed.
Each increment or version of the system incorporates some of the functionality that is
needed by the customer. Generally, the early increments of the system include the most
important or most urgently required functionality. This means that the customer can
evaluate the system at a relatively early stage in the development to see if it delivers
what is required. If not, then only the current increment has to be changed and,
possibly, new functionality defined for later increments.
 Incremental development has three important benefits, compared to the waterfall model:
1. The cost of accommodating changing customer requirements is reduced. The amount of
analysis and documentation that has to be redone is much less than is required with the
waterfall model.
2. It is easier to get customer feedback on the development work that has been done.
Customers can comment on demonstrations of the software and see how much has
been implemented. Customers find it difficult to judge progress from software design
documents.
3. More rapid delivery and deployment of useful software to the customer is possible, even
if all of the functionality has not been included. Customers are able to use and gain
value from the software earlier than is possible with a waterfall process.

5. RAD Model

The RAD model is a type of incremental process model in which there is an extremely short
development cycle. When the requirements are fully understood and the component-based
construction approach is adopted then the RAD model is used.
The critical feature of this model is the use of powerful development tools and techniques. A
software project can be implemented using this model if the project can be broken down into
small modules wherein each module can be assigned independently to separate teams. These
modules can finally be combined to form the final product. Development of each module
involves the various basic steps as in the waterfall model i.e. analyzing, designing, coding, and
then testing, etc.
This model consists of 4 basic phases:
1. Requirements Planning – This 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 to be 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.

The process involves building a rapid prototype, delivering it to the customer, and taking
feedback. After validation by the customer, the SRS document is developed and the design is
finalized.
Advantages of Rapid Application Development Model (RAD)
● 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 periods.
● The progress and development of the project can be measured through the various
stages.
Disadvantages of Rapid application development model (RAD)
● 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.

6. Spiral Model
 The Spiral Model is a risk-driven model, meaning that the focus is on managing risk
through multiple iterations of the software development process. It consists of the
following phases:
1. Objectives Defined: In first phase of the spiral model we clarify what the project aims
to achieve, including functional and non-functional requirements.
2. Risk Analysis: In the risk analysis phase, the risks associated with the project are
identified and evaluated.
3. Engineering: In the engineering phase, the software is developed based on the
requirements gathered in the previous iteration.
4. Evaluation: In the evaluation phase, the software is evaluated to determine if it meets
the customer’s requirements and if it is of high quality.
5. Planning: The next iteration of the spiral begins with a new planning phase, based on
the results of the evaluation.
The software process is represented as a spiral, rather than a sequence of activities with
some backtracking from one activity to another. Each loop in the spiral represents a
phase of the software process. Thus, the innermost loop might be concerned with
system feasibility, the next loop with requirements definition, the next loop with
system design, and so on.
Each loop in the spiral is split into four sectors:

1. Objective setting Specific objectives for that phase of the project are defined.
Constraints on the process and the product are identified and a detailed management
plan is drawn up. Project risks are identified. Alternative strategies, depending on these
risks, may be planned.

2. Risk assessment and reduction For each of the identified project risks, a detailed
analysis is carried out. Steps are taken to reduce the risk. For example, if there is a
risk that the requirements are inappropriate, a prototype system may be developed.
 3. Development and validation After risk evaluation, a development model for the
system is chosen. For example, throwaway prototyping may be the best development
approach if user interface risks are dominant. If safety risks are the main
consideration, development based on formal transformations may be the most
appropriate process, and so on. If the main identified risk is sub-system integration, the
waterfall model may be the best development model to use.

4. Planning The project is reviewed and a decision made whether to continue with
a further loop of the spiral. If it is decided to continue, plans are drawn up for the
next phase of the project.
Advantages of the Spiral Model
1.Risk Handling
2.Good for large projects
3.Flexibility in Requirements
4.Customer Satisfaction
5.Iterative and Incremental Approach
6.Emphasis on Risk Management
7.Improved Communication
8.Improved Quality

Disadvantages of the Spiral Model

Below are some main disadvantages of the spiral model.
1. Complex: The Spiral Model is much more complex than other SDLC models.
2. Expensive: Spiral Model is not suitable for small projects as it is expensive.
3. Too much dependability on Risk Analysis: The successful completion of the project
is very much dependent on Risk Analysis. Without very highly experienced experts, it
is going to be a failure to develop a project using this model.
4. Difficulty in time management: As the number of phases is unknown at the start of
the project, time estimation is very difficult.
5. Complexity: The Spiral Model can be complex, as it involves multiple iterations of
the software development process.
6. Time-Consuming: The Spiral Model can be time-consuming, as it requires multiple
evaluations and reviews.
7. Resource Intensive: The Spiral Model can be resource-intensive, as it requires a
significant investment in planning, risk analysis, and evaluations.
7. Component assembly model
 The component-based assembly model uses object-oriented technologies. In
object-oriented technologies, the emphasis is on the creation of classes. Classes are the
entities that encapsulate data and algorithms. In component-based architecture, classes
(i.e., components required to build application) can be uses as reusable components.
This model uses various characteristics of spiral model. This model is evolutionary by
nature. Hence, software development can be done using iterative approach. In CBD
model, multiple classes can be used. These classes are basically the prepackaged
components. The model works in following manner:
● Step-1: First identify all the required candidate components, i.e., classes with the help
of application data and algorithms.
● Step-2: If these candidate components are used in previous software projects then they
must be present in the library.
● Step-3: Such preexisting components can be excited from the library and used for
further development.
● Step-4: But if the required component is not present in the library then build or create
the component as per requirement.
● Step-5: Place this newly created component in the library. This makes one iteration of
the system.
● Step-6: Repeat steps 1 to 5 for creating n iterations, where n denotes the number of
iterations required to develop the complete application.
Characteristics of Component Assembly Model:
● Uses object-oriented technology.
● Components and classes encapsulate both data and algorithms.
● Components are developed to be reusable.
● Paradigm similar to spiral model, but engineering activity involves components.
● The system produced by assembling the correct components.

8. Agile process model

Agile development model is also a type of Incremental model. Software is developed
in incremental, rapid cycles. This results in small incremental releases with each
release building on previous functionality. Each release is thoroughly tested to ensure
software quality is maintained. It is used for time critical applications. Extreme
Programming (XP) and Scrum are currently the most well known agile development
life cycle models.
8.1 Extreme Programming:
XP is a lightweight, efficient, low-risk, flexible, predictable, scientific, and fun way to
develop software. eXtreme Programming (XP) was conceived and developed to
address the specific needs of software development by small teams in the face of vague
and changing requirements. Extreme Programming is one of the Agile software
development methodologies. It provides values and principles to guide the team
behavior. The team is expected to self-organize. Extreme Programming provides
specific core practices where- Each practice is simple and self-complete. Combination
of practices produces more complex and emergent behavior.
Extreme Programming in a Nutshell Extreme Programming involves-
• Writing unit tests before programming and keeping all of the tests running at all times.
The unit tests are automated and eliminate defects early, thus reducing the costs.
• Starting with a simple design just enough to code the features at hand and redesigning
when required.
• Programming in pairs (called pair programming), with two programmers at one screen,
taking turns to use the keyboard. While one of them is at the keyboard, the other
constantly reviews and provides inputs.
• Integrating and testing the whole system several times a day.
• Putting a minimal working system into the production quickly and upgrading it whenever
required.
• Keeping the customer involved all the time and obtaining constant feedback. Iterating
facilitates the accommodating changes as the software evolves with the changing
requirements.
 Advantages:
• Slipped schedules: Short 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.
• Production and post-delivery defects: Emphasis is on the unit tests to detect and fix the
defects early.
• 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.
Cohesion of multi-disciplines fosters the team spirit.
The fundamental principles of Extreme Programming are-
• Rapid feedback
• Assume simplicity
• Incremental change
• Embracing change
• Quality work
8.2 Scrum Model
Scrum is an agile way to manage a project, usually software development. Agile software
development with Scrum is often perceived as a methodology; but rather than viewing Scrum
as methodology, think of it as a framework for managing a process.

Scrum team: A typical scrum team has between five and nine people, but Scrum projects
can easily scale into the hundreds. However, Scrum can easily be used by one-person
teams and often is. This team does not include any of the traditional software
engineering roles such as programmer, designer, tester or architect. Everyone on the
project works together to complete the set of work they have collectively committed to
complete within a sprint. Scrum teams develop a deep form of camaraderie and a
feeling that “we’re all in this together.”
Product owner: The product owner is the project’s key stakeholder and represents users,
customers and others in the process. The product owner is often someone from product
management or marketing, a key stakeholder or a key user.
Scrum Master: The Scrum Master is responsible for making sure the team is as
productive as possible. The Scrum Master does this by helping the team use the Scrum
process, by removing impediments to progress, by protecting the team from outside,
and so on.
Product backlog: The product backlog is a prioritized features list containing every
desired feature or change to the product. Note: The term “backlog” can get confusing
because it’s used for two different things. To clarify, the product backlog is a list of
desired features for the product. The sprint backlog is a list of tasks to be completed in
a sprint.
Sprint planning meeting: At the start of each sprint, a sprint planning meeting is held,
during which the product owner presents the top items on the product backlog to the
team. The Scrum team selects the work they can complete during the coming sprint.
That work is then moved from the product backlog to a sprint backlog, which is the list
 of tasks needed to complete the product backlog items the team has committed to
complete in the sprint.
Daily Scrum: Each day during the sprint, a brief meeting called the daily scrum is
conducted. This meeting helps set the context for each day’s work and helps the team
stay on track. All team members are required to attend the daily scrum.
Sprint review meeting: At the end of each sprint, the team demonstrates the completed
functionality at a sprint review meeting, during which, the team shows what they
accomplished during the sprint. Typically, this takes the form of a demonstration of the
new features, but in an informal way; for example, PowerPoint slides are not allowed.
The meeting must not become a task in itself nor a distraction from the process.
Sprint retrospective: Also at the end of each sprint, the team conducts a sprint
retrospective, which is a meeting during which the team (including its Scrum Master
and product owner) reflect on how well Scrum is working for them and what changes
they may wish to make for it to work even better.
Scrum is an iterative framework to help teams manage and progress through a complex
project. It is most commonly used in Software Development by teams that implement
the Agile Software Development methodology. However it is not limited to those
groups. Even if your team does not implement Agile Software Development, you can
still benefit from holding regular scrums with your teams.
Advantages of Agile model:
• Customer satisfaction by rapid, continuous delivery of useful software.
• People and interactions are emphasized rather than process and tools. Customers, developers
and testers constantly interact with each other.
• Working software is delivered frequently (weeks rather than months). Face-to-face
conversation is the best form of communication.
• Close, daily cooperation between business people and developers. Continuous attention to
technical excellence and good design.
• Regular adaptation to changing circumstances.
• Even late changes in requirements are welcomed
Disadvantages of Agile model:
• In case of some software deliverables, especially the large ones, it is difficult to assess the
effort required at the beginning of the software development life cycle.
• There is lack of emphasis on necessary designing and documentation.
• The project can easily get taken off track if the customer representative is not clear what
final outcome that they want.
• Only senior programmers are capable of taking the kind of decisions required during the
development process. Hence it has no place for newbie programmers, unless combined with
experienced resources.
When to use Agile model:
• When new changes are needed to be implemented. The freedom agile gives to change is very
important. New changes can be implemented at very little cost because of the frequency of
new increments that are produced.
• To implement a new feature the developers need to lose only the work of a few days, or even
only hours, to roll back and implement it.
• Unlike the waterfall model in agile model very limited planning is required to get started
with the project. Agile assumes that the end users’ needs are ever changing in a dynamic
business and IT world. Changes can be discussed and features can be newly effected or
removed based on feedback. This effectively gives the customer the finished system they want
or need.
• Both system developers and stakeholders alike, find they also get more freedom of time and
options than if the software was developed in a more rigid sequential way. Having options
gives them the ability to leave important decisions until more or better data or even entire
hosting programs are available; meaning the project can continue to move forward without
fear of reaching a sudden standstill.
Scaling of agile methods
There are two perspectives on the scaling of agile methods:
1. A ‘scaling up’ perspective, which is concerned with using these methods for
developing large software systems that cannot be developed by a small team.
2. A ‘scaling out’ perspective, which is concerned with how agile methods can be
introduced across a large organization with many years of software development
experience.

Process activities
1. Software specification
In this process, detailed description of a software system to be developed with its functional
and non-functional requirements.

2. Software design and implementation (Software Development)

Software development is defined as the process of designing, creating, testing, and
maintaining computer programs and applications. This diverse field combines creativity,
engineering expertise, and problem-solving abilities to produce software that satisfies
particular requirements and goals. Software developers, also known as programmers or
coders, use a variety of programming languages and tools to create solutions for end-users or
businesses.
Software developers develop the software, which itself is a set of instructions in order to
perform a specific task. software have three types.
Types of Softwares
There are three basic types of Software
1. System Software
System software is software that directly operates computer hardware and provides basic
functionality to users as well as other software for it to run smoothly.
2. Application Software
Application software is a software that is designed for end-user to complete a specific task. It
is a product or programm that is only intended to meet the needs of end users. It includes word
processors, spreadsheets, database management, inventory, and payroll software, among other
things.
3. Programming Software
Programming software is a software that is designed for programmers to develop program. It
consists of code editor, compiler, interpreter, debugger etc.
3. Software validation
Verification and Validation is the process of investigating whether a software system satisfies
specifications and standards and fulfills the required purpose.
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 fulfills the requirements that we have.
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.

4. Software evolution
The software evolution process includes fundamental activities of change analysis, release
planning, system implementation, and releasing a system to customers.
1. The cost and impact of these changes are accessed to see how much the system is
affected by the change and how much it might cost to implement the change.
2. If the proposed changes are accepted, a new release of the software system is planned.
3. During release planning, all the proposed changes (fault repair, adaptation, and new
functionality) are considered.
4. A design is then made on which changes to implement in the next version of the
system.
5. The process of change implementation is an iteration of the development process
where the revisions to the system are designed, implemented, and tested.

Waterfall Model Spiral Model Prototyping Model Incremental Model

 Requirements analysis
The requirements can be made in the
Requirements must be Requirements analysis
analysis and gathering later stages of the
clearly understood and can be made in the
can be done in iteration development cycle.
defines at the beginning later stages of the
because requirements Because requirements
only. development cycle.
get changed quite often. get changed quite
often.

The development team

The development team The development team The development team
having the adequate
having the adequate having the adequate having the adequate
experience of working
experience of working experience of working experience of working
on the similar project
on the similar project is on the similar project is on the similar project
is chose to work on
chose to work on this allowed in this process is allowed in this
this type of process
type of process model model. process model.
model

There is no user There is no user There is user There is user

involvement in all the involvement in all the involvement in all the involvement in all the
phases of development phases of development phases of development phases of development
process. process. process. process.

When the
requirements are
reasonably well
Due to iterative nature defined and the
When developer is development effort
When the requirements of this model, the risk
unsure about the suggests a purely
are reasonably well identification and
efficiency of an linear effort and when
defined and the rectification is done
algorithm or the limited set of software
development effort before they get
adaptability of an functionality is needed
suggests a purely linear problematic. Hence for
operating system then quickly then the
effort then the waterfall handling real time
the prototyping model incremental model is
model is chosen. problems the spiral
is chosen. chosen.
model is chosen.
 Unit 1
Professional software development
-What is software?

-What are the attributes of good software?

-What is software engineering?

-What are the fundamental software engineering

activities?
Software specification
Software development
Software validation
Software evolution.
• Professional software development

-What is the difference between software engineering and computer

science?

-What is the difference between software engineering and system

engineering?

-What are the key challenges facing software engineering?

-What are the costs of software engineering?

Development and Testing cost.

-What are the best software engineering techniques and methods?

 Software engineering
-Software engineering is an engineering discipline that is
concerned with all aspects of software production from the
early stages of system specification through to maintaining
the system after it has gone into use.
-Essential attributes of good software
1. Maintainability
2. Dependabilty and security
3. Efficiency
4. Accessability
 Software engineering diversity
There are many different types of application including:
1. Stand-alone applications
2. Interactive transaction-based applications
3. Embedded control systems
4. Batch processing systems
5. Entertainment systems
6. Systems for modeling and simulation
7. Data collection systems
8. Systems of systems
 Software Process
A software process is a set of related activities that leads to the production of a
software product.
These activities may involve the development of software from scratch in a standard
programming language like Java or C.
There are four activities that are fundamental to software engineering:
1. Software specification- The functionality of the software and constraints on its
operation must be defined.
2. Software design and implementation- The software to meet the specification
must be produced.
3. Software validation- The software must be validated to ensure that it does what
the customer wants.
4. Software evolution- The software must evolve to meet changing customer needs.
 Software Process
Process descriptions may also include:
1. Products- which are the outcomes of a process activity. For
example, the outcome of the activity of architectural design may be a
model of the software architecture.
2. Roles- which reflect the responsibilities of the people involved in
the process. Examples of roles are project manager, configuration
manager, programmer, etc.
3. Pre- and post-conditions- which are statements that are true
before and after a process activity has been enacted or a product
produced.
SDLC
 Tailoring the Process
⚫ Tailoring is the process of referencing framework documents, standards
and other relevant sources and utilizing those elements that provide
processes, tools and techniques that are suitable for that particular
organization.
⚫ It also includes modifying existing processes currently in use by the organization.

⚫ Tailoring at two levels:

⚫ Summary
⚫ Detailed.
 Tailoring the Process
1. Summary-Level Tailoring
In summary-level tailoring, depending on the project characteristics, the project manager applies
overall guidelines for tailoring the standard process. That is, it provides some general rules
regarding certain types of detailed activities. To perform this step, the project manager first
identifies certain characteristics of the project. For development projects, the following
characteristics are used for tailoring:
⚫ Experience and skill level of the team and the project manager
⚫ Clarity of the requirements
⚫ Project duration
⚫ Application criticality
 Tailoring the Process
2. Detailed Tailoring
Detailed tailoring covers execution of activities, their review, and documentation needs.
Tailoring guidelines may specify an activity as optional, in which case the project manager
can decide whether or not to execute the activity. Similarly, preparation of some
documents may be optional, in which case the project manager decides whether or not the
project needs the document.

When detailed tailoring is finished, the sequence of activities to be performed in the

process for the project is defined. These definitions are then used to plan and schedule
activities and form the basis of project execution. The tailoring performed is highlighted in
the project plan, so the process definition and tailoring also are reviewed when the plan is
reviewed.
 Process Improvement Discipline

⚫ As businesses try to accelerate growth while running

lean, there’s always a desire to reduce costs through
process improvement. Like the examples above, this
could include:

• Improving product quality

• Upgrade service quality
• Improve delivery times
• Reduce billing cycles
• Make production more efficient
1. Classical Waterfall Model
2. The Iterative Waterfall
Model
3. Incremental development
4. Prototype Model
5. RAD Model
6. Spiral Model
 Boehm’s spiral model
The software process is represented as a spiral, rather than a sequence of activities with some backtracking
from one activity to another. Each loop in the spiral represents a phase of the software
process. Thus, the innermost loop might be concerned with system feasibility, the
next loop with requirements definition, the next loop with system design, and so on.
Each loop in the spiral is split into four sectors:

1. Objective setting Specific objectives for that phase of the project are defined.
Constraints on the process and the product are identified and a detailed management plan is drawn up.
Project risks are identified. Alternative strategies, depending on these risks, may be planned.

2. Risk assessment and reduction For each of the identified project risks, a detailed
analysis is carried out. Steps are taken to reduce the risk. For example, if there is a
risk that the requirements are inappropriate, a prototype system may be developed.

3. Development and validation After risk evaluation, a development model for the
system is chosen. For example, throwaway prototyping may be the best development approach if user
interface risks are dominant. If safety risks are the main
consideration, development based on formal transformations may be the most
appropriate process, and so on. If the main identified risk is sub-system integration, the waterfall model
may be the best development model to use.

4. Planning The project is reviewed and a decision made whether to continue with
a further loop of the spiral. If it is decided to continue, plans are drawn up for the
next phase of the project.
7. Component assembly model
 8. Agile Method
.concept
.inception
.iteration/construction
.release
.production
.retirement
Agile Principles
Agile project management
 Scrum Approach
Advantages of scrum approach:
1. Freedom, adaption
2. High quality, low risk product
3. Reduce development time up to 40%
4. Budget friendly and time saving

Disadvantages of scrum approach:

1. More efficient for small team size.
2. No changes in the sprint.
Scrum Approach
 Scaling of agile methods

There are two perspectives on the scaling of agile methods:

1. A ‘scaling up’ perspective, which is concerned with using these methods for
developing large software systems that cannot be developed by a small team.

2. A ‘scaling out’ perspective, which is concerned with how agile methods can be
introduced across a large organization with many years of software development
experience.
 Process activities

1. Software specification
2. Software design and implementation
3. Software validation
4. Software evolution
 1. Software Specification
Figure: The requirements engineering process
2. Software design and implementation
Figure: A general model of the design process
3. Software validation
Figure: Stages of testing
 3. Software validation
Figure: Testing phases in a plan-driven software process
4. Software Evolution

Figure: System Evolution

 Requirements Engineering
Phases of Requirement Engineering
1. Feasibility Study
2. Requirements Elicitation
3. Requirements Specification
4. Requirements Validation
5. Requirements Management

1. Feasibility Study: Assessing the viability of the project.

The feasibility study mainly concentrates on below five mentioned areas below.
Among these Economic Feasibility Study is the most important part of the feasibility
analysis and the Legal Feasibility Study is less considered feasibility analysis.
1.1 Technical Feasibility: In Technical Feasibility current resources both hardware
software along required technology are analyzed/assessed to develop the project. This
technical feasibility study reports whether there are correct required resources and
technologies that will be used for project development. Along with this, the feasibility
study also analyzes the technical skills and capabilities of the technical team, whether
existing technology can be used or not, whether maintenance and up-gradation are
easy or not for the chosen technology, etc.
1.2 Operational Feasibility: In Operational Feasibility degree of providing service to
requirements is analyzed along with how easy the product will be to operate and
maintain after deployment. Along with this other operational scopes are determining
the usability of the product, Determining suggested solution by the software
development team is acceptable or not, etc.
1.3 Economic Feasibility: In the Economic Feasibility study cost and benefit of the
project are analyzed. This means under this feasibility study a detailed analysis is
carried out will be cost of the project for development which includes all required
costs for final development hardware and software resources required, design and
development costs operational costs, and so on. After that, it is analyzed whether the
project will be beneficial in terms of finance for the organization or not.
1.4 Legal Feasibility: In legal feasibility, the project is ensured to comply with all
relevant laws, regulations, and standards. It identifies any legal constraints that could
impact the project and reviews existing contracts and agreements to assess their effect
on the project’s execution. Additionally, legal feasibility considers issues related to
intellectual property, such as patents and copyrights, to safeguard the project’s
innovation and originality.
1.5 Schedule Feasibility: In schedule feasibility, the project timeline is evaluated to
determine if it is realistic and achievable. Significant milestones are identified, and
deadlines are established to track progress effectively. Resource availability is
assessed to ensure that the necessary resources are accessible to meet the project
schedule. Furthermore, any time constraints that might affect project delivery are
considered to ensure timely completion. This focus on schedule feasibility is crucial
for the successful planning and execution of a project.

2. Requirements Elicitation and Analysis: Gathering knowledge about the project

domain and requirements.
It is related to the various ways used to gain knowledge about the project domain and
requirements. The various sources of domain knowledge include customers, business
manuals, the existing software of the same type, standards, and other stakeholders of
the project.
Requirements elicitation is the process of gathering information about the needs and
expectations of stakeholders for a software system. This is the first step in the
requirements engineering process and it is critical to the success of the software
development project. The goal of this step is to understand the problem that the
software system is intended to solve and the needs and expectations of the
stakeholders who will use the system.
Stakeholders range from end-users of a system through managers to external
stakeholders such as regulators, who certify the acceptability of the system. For
example, system stakeholders for the mental healthcare patient information system
include:
1. Patients whose information is recorded in the system.
2. Doctors who are responsible for assessing and treating patients.
3. Nurses who coordinate the consultations with doctors and administer some
treatments.
4. Medical receptionists who manage patients’ appointments.
5. IT staff who are responsible for installing and maintaining the system.
 6. A medical ethics manager who must ensure that the system meets current ethical
guidelines for patient care.
7. Healthcare managers who obtain management information from the system.
8. Medical records staff who are responsible for ensuring that system information
can be maintained and preserved, and that record keeping procedures have been
properly implemented.
3. Requirements Specification: Producing formal software requirement models.
This activity is used to produce formal software requirement models. All the
requirements including the functional as well as the non-functional requirements and
the constraints are specified by these models in totality. During specification, more
knowledge about the problem may be required which can again trigger the elicitation
process. The models used at this stage include ER diagrams, data flow
diagrams(DFDs), function decomposition diagrams(FDDs), data dictionaries, etc.
Once the requirements are specified, they must be reviewed and validated by the
stakeholders and development team to ensure that they are complete, consistent, and
accurate.
4. Requirements Validation: Ensuring the requirements are accurate and complete.
Verification: It refers to the set of tasks that ensures that the software correctly
implements a specific function.
Validation: It refers to a different set of tasks that ensures that the software that has
been built is traceable to customer requirements. If requirements are not validated,
errors in the requirement definitions would propagate to the successive stages
resulting in a lot of modification and rework.

Verification is checking that the requirements are complete, consistent, and accurate.
It involves reviewing the requirements to ensure that they are clear, testable, and free
of errors and inconsistencies. This can include reviewing the requirements document,
models, and diagrams, and holding meetings and walkthroughs with stakeholders.
Validation is the process of checking that the requirements meet the needs and
expectations of the stakeholders. It involves testing the requirements to ensure that
they are valid and that the software system being developed will meet the needs of the
stakeholders. This can include testing the software system through simulation, testing
with prototypes, and testing with the final version of the software.
5. Requirements Management: Handling changes and closing the requirement phase.
Requirement management is the process of analyzing, documenting, tracking,
prioritizing, and agreeing on the requirement and controlling the communication with
relevant stakeholders. This stage takes care of the changing nature of requirements. It
should be ensured that the SRS is as modifiable as possible to incorporate changes in
requirements specified by the end users at later stages too. Modifying the software as
per requirements in a systematic and controlled manner is an extremely important part
of the requirements engineering process.

Requirements management is the process of managing the requirements throughout

the software development life cycle, including tracking and controlling changes, and
 ensuring that the requirements are still valid and relevant. The goal of requirements
management is to ensure that the software system being developed meets the needs
and expectations of the stakeholders and that it is developed on time, within budget,
and to the required quality.

Types of Requirements

1. Functional Requirements:
o Definition: Specify what the system should do. They describe the interactions
between the system and its environment, independent of the implementation.
o The functional requirements for a system describe what the system should
do. These requirements depend on the type of software being developed, the
expected users of the software, and the general approach taken by the
organization when writing requirements.
o When expressed as user requirements, functional requirements are usually
described in an abstract way that can be understood by system users.
However, more specific functional system requirements describe the system
functions, its inputs and outputs, exceptions, etc., in detail.
o Functional system requirements vary from general requirements covering what
the system should do to very specific requirements reflecting local ways of
working
or an organization’s existing systems.
o Examples: User login process, data processing logic, and report generation
capabilities.
2. Non-Functional Requirements:
o Definition: Outline the quality attributes or constraints the system must
exhibit. They are not about specific behaviours but how the system performs
under certain conditions or constraints.
 o These are basically the quality constraints that the system must satisfy
according to the project contract. Nonfunctional requirements, not related to
the system functionality, rather define how the system should perform The
priority or extent to which these factors are implemented varies from one
project to other. They are also called non-behavioral requirements. They
basically deal with issues like:
o Portability
o Security
o Maintainability
o Reliability
o Scalability
o Performance
o Reusability
o Flexibility

o Examples: Performance metrics (response time, throughput), security

standards, usability, scalability, and compatibility.

3. Domain Requirements:
Definition: Domain requirements are specific to the domain or industry in which the
software operates. They include terminology, rules, and standards relevant to that
particular domain.
Domain requirements reflect the unique needs and constraints of a particular industry.
They ensure that the software is relevant and compliant with industry-specific regulations
and standards.

Examples:
● Healthcare: The software must comply with HIPAA regulations for handling patient
data.
● Finance: The system should adhere to GAAP standards for financial reporting.
● E-commerce: The software should support various payment gateways like PayPal,
Stripe, and credit cards.
Classifications of Software Requirements
Other common classifications of software requirements can be:
System Requirements:
o Definition: Detailed specifications describing the software system’s functions,
features, and constraints. These can be further divided into software and
hardware requirements.
o are more detailed descriptions of the software system’s functions, services, and
operational constraints.
o The system requirements document (sometimes called a functional
specification) should define exactly what is to be implemented. It may be part
of the contract between the system buyer and the software developers.
o Examples: Hardware specifications (CPU, memory, disk space), software
dependencies (operating systems, middleware), system integrations, and
system behaviors.
User Requirements:
o Definition: Express the needs and desires of the end-users in terms of tasks
they need to perform with the system, often documented in natural language or
through use cases.
o User requirements are statements, in a natural language plus diagrams, of what
services the system is expected to provide to system users.
o User requirements define the results and qualities the user wants.
o A user requirement concerned with security, such as a statement limiting
access to authorized users, may appear to be a nonfunctional requirement.
o Examples: Ability to export data into various formats, user-friendly interfaces
for on-technical users, and custom notification settings.
 SRS(Software Requirement Specification)
SRS Template:

Characteristics of a good SRS document:

1. Correctness:
User review is used to ensure the correctness of requirements stated in the SRS. SRS
is said to be correct if it covers all the requirements that are actually expected from the
system.

2. Completeness:
Completeness of SRS indicates every sense of completion including the numbering of
all the pages, resolving the to be determined parts to as much extent as possible as
well as covering all the functional and non-functional requirements properly.

3. Consistency:
Requirements in SRS are said to be consistent if there are no conflicts between any set
of requirements. Examples of conflict include differences in terminologies used at
separate places, logical conflicts like time period of report generation, etc.

4. Unambiguousness:
A SRS is said to be unambiguous if all the requirements stated have only 1
interpretation. Some of the ways to prevent unambiguousness include the use of
modelling techniques like ER diagrams, proper reviews and buddy checks, etc.

5. Ranking for importance and stability:

There should a criterion to classify the requirements as less or more important or more
specifically as desirable or essential. An identifier mark can be used with every
requirement to indicate its rank or stability.

6. Modifiability:
SRS should be made as modifiable as possible and should be capable of easily
accepting changes to the system to some extent. Modifications should be properly
indexed and cross-referenced.
7. Verifiability:
A SRS is verifiable if there exists a specific technique to quantifiably measure the
extent to which every requirement is met by the system. For example, a requirement
starting that the system must be user-friendly is not verifiable and listing such
requirements should be avoided.

8. Traceability:
One should be able to trace a requirement to design component and then to code
segment in the program. Similarly, one should be able to trace a requirement to the
corresponding test cases.

9. Design Independence:
There should be an option to choose from multiple design alternatives for the final
system. More specifically, the SRS should not include any implementation details.

10. Testability:
A SRS should be written in such a way that it is easy to generate test cases and test
plans from the document.

11. Understandable by the customer:

An end user maybe an expert in his/her specific domain but might not be an expert in
computer science. Hence, the use of formal notations and symbols should be avoided
to as much extent as possible. The language should be kept easy and clear.

12. Right level of abstraction:

If the SRS is written for the requirements phase, the details should be explained
explicitly. Whereas, for a feasibility study, fewer details can be used. Hence, the level
of abstraction varies according to the purpose of the SRS.

Requirement Elicitation Techniques

1. Brainstorming
Brainstorming, as a requirements elicitation technique, embodies a dynamic group
activity focused on generating a wide array of ideas, solutions, and requirements for a
project.
This technique is especially valuable in the initial phases of a project, where the goal
is to explore various possibilities and identify innovative solutions without the
constraints of criticism or feasibility considerations.
2. 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
develop a better understanding of their needs.
3. Surveys/Questionnaires
Surveys and questionnaires stand as highly scalable and efficient techniques for
requirement elicitation, enabling data collection from a broad audience in a relatively
short period of time.
This method is particularly useful when the project stakeholders are numerous or
geographically dispersed, and there’s a need to gather a wide range of opinions,
preferences, and requirements for the system under development.
4. Prototyping
Prototyping is a dynamic and interactive requirements elicitation technique that
involves creating preliminary versions of a software system to explore ideas, uncover
requirements, and gather feedback from users and stakeholders.
This approach allows for a tangible exploration of the system’s functionality and
design before developing the full system.
5. Scenarios
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.
6. Use Cases
Use Case technique combines text and pictures to provide a better understanding of
the requirements.
The use cases describe the ‘what’, of a system and not ‘how’. Hence, they only give a
functional view of the system.
The components of the use case design include three major things – Actor, use cases,
and use case diagram.
1. Actor: It is the external agent that lies outside the system but interacts with it in some
way. An actor may be a person, machine, etc. It is represented as a stick figure. Actors
can be primary actors or secondary actors.
● Primary actors: It requires assistance from the system to achieve a goal.
● Secondary actor: It is an actor from which the system needs assistance.
2. Use cases: They describe the sequence of interactions between actors and the system.
They capture who(actors) do what(interaction) with the system. A complete set of use
cases specifies all possible ways to use the system.
3. Use case diagram: A use case diagram graphically represents what happens when an
actor interacts with a system. It captures the functional aspect of the system.
● A stick figure is used to represent an actor.
● An oval is used to represent a use case.
● A line is used to represent a relationship between an actor and a use case.
The success of an elicitation technique used depends on the maturity of the analyst,
developers, users, and the customer involved.

Example: Use case diagram of Medical Health Care

7. Ethnography
Ethnography comes from anthropology, literally means "writing the culture"
• Essentially seeks to explore the human factors and social organization of activities
understand work.
• Studies have shown that work is often richer and more complex than is suggested by
simple models derived from interviews
• Social scientists are trained in observation and work analysis
• Discoveries are made by observation and analysis, workers are not asked to explain
what they do
• Collect what is ordinary/what is it that people do (aim at making the implicit
explicit)
• Study the context of work and watch work being done

Data Flow Diagram

A Data Flow Diagram (DFD) is a graphical representation of the "flow" of data
through an information system.
• It is common practice to draw a System Context Diagram first which shows the
interaction between the system and outside entities.
• The DFD is designed to show how a system is divided into smaller portions and to
highlight the flow of data between those parts.
• Level 0 DFD i.e. Context level DFD should depict the system as a single.
• Primary input and primary output should be carefully identified.
•Information flow from continuity must be maintained from level to level.
DFD four Symbols:
 Types of DFD:
1) Logical DFD
It illustrates how data flows in the system
- What system should do
2) Physical DFD
Physical data flow diagram shows how the data flow is actually implemented in the
system.
- How system should work
Rules for creating Data Flow Diagrams (DFD) include the following.
● Data cannot flow directly between two entities.
● Data flow must be from entity to a process or a process to an entity.
● There can be multiple data flows between one entity and a process.
● Each process should have at least one input and one output.
● Each data store should have at least one data flow in and one data flow out.
Levels of Data Flow Diagram (DFD)
Data Flow Diagram (DFD) uses hierarchy to maintain transparency thus multilevel Data
Flow Diagram (DFD’s) can be created. Levels of Data Flow Diagram (DFD) are as follows:
1. 0-level DFD
It is also known as a context diagram. It’s designed to be an abstraction view, showing the
system as a single process with its relationship to external entities. It represents the entire
system as a single bubble with input and output data indicated by incoming/outgoing arrows.
2. 1-Level DFD
This level provides a more detailed view of the system by breaking down the major processes
identified in the level 0 DFD into sub-processes. Each sub-process is depicted as a separate
process on the level 1 DFD. The data flows and data stores associated with each sub-process
are also shown. In 1-level DFD, the context diagram is decomposed into multiple
bubbles/processes. In this level, we highlight the main functions of the system and
breakdown the high-level process of 0-level DFD into subprocesses.
3. 2-level DFD
This level provides an even more detailed view of the system by breaking down the
sub-processes identified in the level 1 DFD into further sub-processes. Each sub-process is
depicted as a separate process on the level 2 DFD. The data flows and data stores associated
with each sub-process are also shown.

Data Dictionary
A data dictionary is an alphabetic list of the names included in the system models. As well as
the name, the dictionary should include an associated description of the named entity and, if
the name represents a composite object, a description of the composition.
• Other information such as the date of creation, the creator and the representation of the
entity may also be included depending on the type of model being developed.
Ex.
Data element- Order

Description- Record comprising fields

Order identification Customer name Customer address
..
Package name
Package price

Product specification document

• Planning
This section outlines who is involved in the development of the product and who is
accountable for decisions that need to be made. It also outlines the intended problem
to solve.
• Scope
The scope section outlines the product’s features and functionality, performance
targets and metrics that define success, any constraints and limitations, and key
assumptions and risks.
• Product design
 For most software products you will need a high-level architecture design, the user
interface mockups, process maps for any changing workflow, and technical designs.
You’ll also need to compliance with any relevant standards and regulations.
• Testing plan
It is likely you will have a standard method for testing your software, so this section
just needs to note any differences or adaptations from the norm. Possibly, you will
need to establish the product’s warranty and support policy.

• Release plan
The release plan should include required steps to release the product to customers. It
may involve training for teams, a tie-in with sales and marketing activity, or
something else relevant to the market your product is entering.
• Managing the product
Managing the product involves defining the product’s lifecycle, outlining the
maintenance and upgrade plan, and establishing the product’s support and training
needs. It’s essential to ensure that the product continues to meet the customer’s needs
and expectations throughout its lifecycle and to identify opportunities for
improvement.

Process Modelling: Structural English, Decision Tree, Decision Table

Structural English:
Decision Tree:
Decision Table:
 Requirements Engineering
1. User Requirements-
User requirements are statements, in a natural language plus diagrams, of what
services the system is expected to provide to system users.
User requirements define the results and qualities the user wants.
A user requirement concerned with security, such as a statement limiting access to
authorized users, may appear to be a nonfunctional requirement.

2. 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. It may be part of the contract
between the system buyer and the software developers.
Requirements Engineering
 1. Functional requirements
The functional requirements for a system describe what the system should do. These
requirements depend on the type of software being developed, the expected users of
the software, and the general approach taken by the organization when writing
requirements.
When expressed as user requirements, functional requirements are
usually described in an abstract way that can be understood by system users.
However, more specific functional system requirements describe the system
functions, its inputs and outputs, exceptions, etc., in detail.
Functional system requirements vary from general requirements covering what
the system should do to very specific requirements reflecting local ways of working
or an organization’s existing systems.
2. Non-functional requirements
Metrics for specifying non-functional requirements
The software requirements document
The software requirements document
The software requirements document
Requirements specification
 SRS Characteristics
1. Correctness
2. Completeness
3. Consistency
4. Unambiguousness
5. Ranking for importance and stability
6. Modifiability
7. Verifiability
8. Traceability
9. Design Independence
10. Testability
11. Understandable by the customer
12. Right level of abstraction
Requirements engineering processes
Requirements elicitation and analysis
 Requirements discovery
Stakeholders range from end-users of a system through managers to external stakeholders such as
regulators, who certify the acceptability of the system. For example,
system stakeholders for the mental healthcare patient information system include:

1. Patients whose information is recorded in the system.

2. Doctors who are responsible for assessing and treating patients.
3. Nurses who coordinate the consultations with doctors and administer some
treatments.
4. Medical receptionists who manage patients’ appointments.
5. IT staff who are responsible for installing and maintaining the system.
6. A medical ethics manager who must ensure that the system meets current ethical guidelines for patient
care.
7. Healthcare managers who obtain management information from the system.
8. Medical records staff who are responsible for ensuring that system information
can be maintained and preserved, and that record keeping procedures have been
properly implemented.
Requirement Elicitation Techniques
1. Brainstorming
2. Interviewing
3. Surveys/Questionnaires
4. Prototyping
5. Scenarios
6. Use Cases
7. Ethnography
 1. Brainstorming
Brainstorming, as a requirements elicitation technique, embodies a dynamic
group activity focused on generating a wide array of ideas, solutions, and
requirements for a project.

This technique is especially valuable in the initial phases of a project, where the
goal is to explore various possibilities and identify innovative solutions without
the constraints of criticism or feasibility considerations.
 2. 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
develop a better understanding of their needs.
 3. Surveys/Questionnaires
Surveys and questionnaires stand as highly scalable and efficient
techniques for requirement elicitation, enabling data collection
from a broad audience in a relatively short period of time.

This method is particularly useful when the project stakeholders

are numerous or geographically dispersed, and there’s a need to
gather a wide range of opinions, preferences, and requirements for
the system under development.
 4. Prototyping
Prototyping is a dynamic and interactive requirements
elicitation technique that involves creating preliminary
versions of a software system to explore ideas, uncover
requirements, and gather feedback from users and
stakeholders.

This approach allows for a tangible exploration of the

system’s functionality and design before developing the full
system.
 5. Scenarios

• 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.
6. Use cases
7. Ethnography
 Requirements validation
• 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

2. Consistency checks

3. Completeness checks

4. Realism checks

5. Verifiability
 Requirements validation

• There are a number of requirements validation techniques that can

be used individually or in conjunction with one another:

1. Requirements reviews
2. Prototyping
3. Test-case generation
Requirements management
1. The business and technical environment
2. The people
3. Large systems
 1. Requirements management planning

1. Requirements identification
2. A change management process
3. Traceability policies
4. Tool support
2. Requirements change management
 Data Flow Diagram
• A Data Flow Diagram (DFD) is a graphical representation of the "flow" of data through an
information system.
• It is common practice to draw a System Context Diagram first which shows the interaction
between the system and outside entities.
• The DFD is designed to show how a system is divided into smaller portions and to highlight
the flow of data between those parts.
• Level 0 DFD i.e. Context level DFD should depict the system as a single.
• Primary input and primary output should be carefully identified.
•Information flow from continuity must be maintained from level to level
 Data Flow Diagram
Types of DFD:

1) Logical DFD
It illustrates how data flows in the system
What system should do

2) Physical DFD
Physical data flow diagram shows how the data flow is
actually implemented in the system.
How system should work
 Data Flow Diagram

Four basic symbols

1. External entity
2. Process
3. Transition
4. Data Store
 Data Dictionary
A data dictionary is an alphabetic list of the names included in the system
models. As well as the name, the dictionary should include an associated
description of the named entity and, if the name represents a composite
object, a description of the composition.

• Other information such as the date of creation, the creator and the
representation of the entity may also be included depending on the type
of model being developed.
 Data Dictionary
Data element- Order

Description- Record comprising fields

Order identification Customer name Customer address
..
Package name
Package price
 Product Specification

A product specification is a document that outlines the characteristics,

features, and functionality of a product. It serves as a blueprint for
designing, developing, and testing the product.

The aim of a product specification document is to ensure that everyone

involved in the product development process understands what is required
and that the end product meets the customer’s needs and expectations.
 Product specification document

•Planning
•Scope
•Product design
•Testing plan
•Release plan
•Managing the product
Structured English
Decision Tree
Decision Table
 Unit 3
Software Project Management and Organization

Three vital aspects of software project management:

1. Software Development Team
• Product owner
• Project manager
• UX / UI designers
• Business analyst
• Software developers
Fig.2.1 Software Development Team
• Team lead / Tech lead
• Scrum master
• Product owner, in the case of an outsourced project, this is the client with a vision of how the end-product
should look, who are the end-users and what it should do.
• Project manager is a person responsible for managing and leading the whole team. Their role is to
efficiently optimize the work of the team, ensure the product is meeting the requirements and identify the
goals for the team.
• Software architect is a highly-skilled software developer that has to think through all the aspects of the
project and is responsible for making high level design choices, as well as select technical standards (for
instance, determines the technology stack to use).
• Developers or product engineers are team members that apply their knowledge of engineering and
programming languages in software development.
• Experience designers ensure that the product is easy and pleasant to use. They conduct user interviews,
market research, and design a product with end-users in mind.
• QA or tester is responsible for the Quality Assurance and makes sure the product is ready to use.
• Business Analyst’s role is to uncover the ways to improve the product. They interact with stakeholders to
understand their problems and needs, and later document and analyze them to find a solution.
2. A Leadership
2.1 Factors Affecting Style

2.2 Types of Leadership Style

• Autocratic:
• Leader makes decisions without reference to anyone else
• High degree of dependency on the leader
• Can create de-motivation and alienationof staff
• May be valuable in some types of business where decisions need to be madequickly and decisively
• Democratic:
Encourages decision making from different perspectives – leadership may be emphasised throughout the
organisation
• Consultative: process of consultation before decisions are taken
• Persuasive: Leader takes decision and seeks to persuade others that thedecision
is correct
• May help motivation and involvement
• Workers feel ownership of the firm and its ideas
• Improves the sharing of ideas
and experiences within the business
• Can delay decision making
• Laissez-Faire:
 ‘Let it be’ – the leadership responsibilities are shared by all
 Can be very useful in businesses where creative ideas are important
 Can be highly motivational, as people have control over their working life
 Can make coordination and decision making time-consuming and lacking in overalldirection
 Relies on good teamwork and good interpersonal relations
• Paternalistic:
• Leader acts as a ‘father figure’
• Paternalistic leader makes decision but may consult
• Believes in the need to support staff
2.3 Theories of Leadership
Trait theories
Is there a set of characteristics that determine a good leader?

• Personality?
• Dominance and personal presence?
• Charisma?
• Self-confidence?
• Achievement?
• Ability to formulate a clear vision?

Contingency Theories
Leadership as being more flexible – different leadership styles used at different timesdepending on the
circumstance.
Suggests leadership is not a fixed series of characteristics that can be transposed intodifferent contexts
May depend on
• Type of staff
• History of the business
• Culture of the business
• Quality of the relationships
• Nature of the changes needed
• Accepted norms within the institution

3. Personality Traits
In psychology, the Big Five personality traits are five broad domains or dimensions of personality that are
used to describe human personality. The theory based on the Big Five factors is called the five-factor
model(FFM).
1. Openness: Curiosity, imagination, and valuing variety.
2. Conscientiousness: Being collected, analytical, and meticulous.
3. Social responsibility: Desiring fair outcomes and having concern for others.
4. Ability to learn: Persistence and focus.
5. Pragmatism: Prioritizing logic and addressing root causes.

PROJECT ORGANIZATION:
• The main objective of Project organization is to establish the relationship among:
• The work to be done
• The people doing
• The work
• the work place(s)
A project organization is a structure that facilitates the coordination and implementation of project
activities. Its main reason is to create an environment that fosters interactions among the team members
with a minimum amount of disruptions, overlaps and conflict. One of the important decisions of project
management is the form of organizational structure that will be used for the project.
Each project has its unique characteristics, and the design of an organizational structure should
consider the organizational environment, the project characteristics in which it will operate, and the level of
authority the project manager is given. A project structure can take on various forms with each form having
its own advantages and disadvantages. One of the main objectives of the structure is to reduce uncertainty
and confusion that typically occurs at the project initiation phase. The structure defines the relationships
among members of the project management and the relationships with the external environment. The
structure defines the authority by means of a graphical illustration called an organization chart.
A properly designed project organization chart is essential to project success. An organization
chart shows where each person is placed in the project structure. An organization chart is drawn in pyramid
form where individuals located closer to the top of the pyramid have more authorityand responsibility than
members located toward the bottom. It is the relative locations of the individuals on the organization chart
that specifies the working relationships, and the lines connecting the boxes designate formal supervision
and lines of communication between the individuals.

Fig 2.7 Project Organization

Creating the project structure is only a part of organizing the project; it is the actual
implementation and application that takes the most effort. The project organization chart
establishes the formal relationships among project manager, the project team members, the
development organization, the project, beneficiaries and other project stakeholders. This
organization must facilitate an effective interaction and integration among all the major project
participants and achieve open and effective communication among them.

The project manager must create a project structure that will meet the various project needs at
different phases of the project. The structure cannot be designed too rigid or too lose, since the
project organization's purpose is to facilitate the interaction of people to achieve the project
ultimate goals within the specified constraints of scope, schedule, budget and quality. The
objective in designing a project structure is to provide a formal environment that the project
manager can use to influence team members to do their best in completing their assignment and
duties. The structure needs to be designed to help develop collaboration among individual team
members; all in a cost-effective way with a minimum of duplication of effort and overlaps.
The organization chart has a limited functionality; it only shows the hierarchical relationship
among the team members but does not shows how the project organization will work, it is for
that reason that the design should consider factors that will facilitate the operation of the
structure; these include communications, information flows, coordination and collaboration
among its members.
2.2 FACTORS IN DESIGNING A PROJECT STRUCTURE
There are two design factors that significantly influence the process of developing a project
management structure. These are the level of specialization, and the need for coordination. The
project manager should consider these factors at the moment of designing the project
organization in order to maximize the effectiveness of the structure.

Specialization affects the project structure by the degree of specialty in technical areas or
development focus; projects can be highly specialized and focus on a specific area of
development or have different broad specializations in many areas of development. For large
projects that have multiple specializations or technical areas, each area may have a different
need; from differences in goals, approaches and methodologies, all of which influence the way
the project will implement its activities. A project that has two components, a reconstruction
and education, will need to manage different approaches based on the specialization of each
one. In the education component, the needs is for a structure more open and informal, where
the time horizon is longer, with more emphasis on sharing and generation of new ideas in order
to achieve innovation and creativity. In a reconstruction component, there are specific goals, a
need for a rigid, hierarchical structure, and there is a defined time horizon with little sharing of
ideas. While specialization allows each project component to maximize their productivity to
attain their departmental goals, the dissimilarities may lead to conflict among the members or
leads of each component. In general, the greater the differences, the more problems project
managers have in getting them to work together.

Coordination is required to bring unity to the various elements that make up a project. The
project work is organized around a work breakdown structure (WBS) that divides the overall
project goals into specific activities or tasks for each project area or component; the
project manager must design an organizational structure that ensure that the various components
are integrated so that their efforts contribute to the overall project goal. Integration is the degree
of collaboration and mutual understanding required among the various project components to
achieve project goals. Most projects are characterized by the division of labor and task
interdependencies, creating the need for integration to meet project objectives. This need is
greatest when there are many project components that have different specializations. The goal
of the project management structure is the achievement of harmony of individual efforts toward
the accomplishment of the group goals. The project manager's principal responsibility is to
develop integrating strategies to ensure that a particular component or activity is organized in a
way that all of the components, parts, subsystems, and organizational units fit together as a
functioning, integrated whole according to the project master plan.

2.5.1 TYPES OF PROJECT ORGANIZATIONS STRUCTURES

The several factors to consider when deciding on the design of project organizational structures,
especially within an existing organization, the factor that has a significant is the extent of
authority and responsibility top management is prepared to delegate to the project manager. An
important function of the organizations’ top management is to design an organization that fully
supports project management. This is done by redesigning the organization to emphasize the
nature of the projects and adapting how roles and responsibilities are assigned.

The organization needs to define the project manager’s job, degree of authority and autonomy,
and relationship to both the organization, other projects and to other units in the organization.
Upper management also should specify communication channels, methods of conflict
resolution between the project and the rest of the organization. Development organizations are
usually organized around programmatic focus areas such as health or education. These areas
are usually called program units and are centered on a specific development field. In this
environment a project has three organization structures available for design and all are defined
by the level of organizational authority given to the project manager:
 Programmatic based, in which project managers have authority only
within the program focus or area
 Matrix based, in which the project manager shares responsibility with
other program unit managers
 Project based, in which project managers have total authority.

Programmatic Based

The programmatic focus refers to a traditional structure in which program sector managers have
formal authority over most resources. It is only suitable for projects within one program sector.
However, it is not suitable for projects that require a diverse mix of people with different
expertise from various program sectors. In a programmatic based organization, a project team
is staffed with people from the same area. All the resources needed for the project team come
from the same unit. For instance, if the project is related to the health area, the project resources
come from the health unit.
The most obvious advantage of programmatic based projects is that there are clear lines of
authority, in large projects the project managers tend to also be the program unit manager. There
is no need to negotiate with other program units for resources, since all

Director

Program Manager
Program Manager Program Manager

Staff Staff Staff Staff Staff Staff Staff Staff Staff Staff

Staff Staff

Fig.2.8 Programmatic organization

of the staff needed for the project will come from the same program area. Another advantage of
this type of organization is that the team members are usually familiar with each other, since
they all work in the same area. The team members also tend to bring applicable knowledge of
the project.

A major disadvantage of the programmatic based organization is that the program area may not
have all of the specialists needed to work on a project. A nutrition project with a water
component, for instance, may have difficulty acquiring specialty resources such as civil
engineers, since the only people available will work in their own program unit. Another
disadvantage is that project team members may have other responsibilities in the program unit
since they may not be needed full- time on a project. They may be assigned to other projects,
but it is more typical that they would have support responsibilities that could impact their ability
to meet project deadlines.

Matrix Based
Matrix based project organizations allow program units to focus on their specific technical
competencies and allow projects to be staffed with specialists from throughout the organization.
For instance, nutrition specialists may report to one program unit, but would be allocated out to
work on various projects. A health specialist might report to the health unit, but be temporarily
assigned to a project in another project that needs health expertise. It is common for people to
report to one person in the programmatic unit, while working for one or two project managers
from other projects in different programmatic units.
The main advantage of the matrix based organization is the efficient allocation of all resources,
especially scarce specialty skills that cannot be fully utilized by only one

Director

Program Manager Program Manager

Staff Staff
Project Manager Staff
Staff Staff

Project Manager Staff Staff Staff

Project Manager Staff Staff

Fig 2.9 Matrix based organization

project. For instance, monitoring and evaluation specialists may not be utilized full-time on a
project, but can be fully leveraged by working on multiple projects.

The matrix based organization is also the most flexible when dealing with changing
programmatic needs and priorities. Additional advantages to matrix management are: it allows
team members to share information more readily across the unit boundaries, allows for
specialization that can increase depth of knowledge and allow professional development and
career progression to be managed. It is easier for a program unit manager to loan an employee
to another manager without making the change permanent. It is therefore easier to accomplish
work objectives in an environment when task loads are shifting rapidly between programmatic
units.

The main disadvantage is that the reporting relationships are complex. Some people might
report to programmatic unit managers for whom little work is done, while actually working for
one or more project managers. It becomes more important for staff members to develop strong
time management skills to ensure that they fulfill the work expectations of multiple managers.
This organization also requires communication and cooperation between multiple
programmatic unit managers and project managers since that all be competing for time from the
same resources.

Matrix management can put some difficulty on project managers because they must work
closely with other managers and workers in order to complete the project. The programmatic
managers may have different goals, objectives, and priorities than the project managers, and
these would have to be addressed in order to get the job done. An approach to help solve this
situation is a variation of the Matrix organization which includes a coordinating role that either
supervises or provides support to the project managers. In some organizations this is know as
the Project Management Office (PMO), dedicated to provide expertise, best practices, training,
methodologies and guidance to project managers.

Director

PMO
Program Manager Program Manager

Staff Staff
Staff
Staff Staff

Staff Staff Staff

Staff Staff

Fig. 2.10 Project management office

The PMO unit also defines and maintains the standards of project management processes within
the organization. The PMO strives to standardize and introduce economies of scale in the
implementation of projects. The PMO is the source of documentation, guidance and metrics on
the practice of project management and implementation. The PMO can also help in the
prioritization of human resources assigned to projects.

Project Based

In this type of organization project managers have a high level of authority to manage and
control the project resources. The project manager in this structure has total authority over the
project and can acquire resources needed to accomplish project objectives from within or
outside the parent organization, subject only to the scope, quality, and budget constraints
identified in the project.

In the project-based structure, personnel are specifically assigned to the project and report
directly to the project manager. The project manager is responsible for the performance
appraisal and career progression of all project team members while on the project. This leads to
increased project loyalty. Complete line authority over project efforts affords the project
manager strong project controls and centralized lines of communication. This leads to rapid
reaction time and improved responsiveness. Moreover, project personnel are retained on an
exclusive rather than shared or part-time basis. Project teams develop a strong sense of project
identification and ownership, with deep loyalty efforts to the project and a good understanding
of the nature of project’s activities, mission, or goals.
 Pure project-based organizations are more common among large and
complicated projects. These large projects can absorb the cost of
maintaining an organization whose structure has some duplication of
effort and the less than cost-efficient use of resources. In fact, one major
disadvantage of the project-based organization is the costly and
inefficient use of personnel. Project team members are generally
dedicated to one project at a time, even though they may rarely be
needed on a full-time basis over the life cycle of the project. Project
managers may tend to retain their key personnel long after the work is
completed, preventing their contribution to other projects and their
professional development.

Fig.2.10 project-based organizations

In this type of organization, limited opportunities exist for knowledge

sharing between projects, and that is a frequent complaint among team
members concerning the lack of career continuity and opportunities for
professional growth. In some cases, project personnel may experience a
great deal of uncertainty, as organizations or donor’s priorities shift or the
close of the project seems imminent.
One disadvantage is duplication of resources since scarce resources must
be duplicated on different projects. There can also be concerns about how
to reallocate people and resources when projects are completed. In a
programmatic focus organization, the people still have jobs within the
program unit. In a project-based organization it is not always clear where
everyone is reassigned when the project is completed. Another
disadvantage is that resources may not be needed as a full time for the
entire length of the project, increasing the need to manage short term
contracts with consultants and other subject matter experts.

A variety of this pure project approach is temporarily project-based

organizations. This organization consists of a project team pulled together
temporarily from their program unit andled by a project manager that does
not report to a programmatic unit. The project manager has the full
authority and supervision of the project team.
Another design is based on a mixed structure that includes a matrix,
programmatic focus and project based; this mix reflects the need for more
flexibility in a development organization to accommodate different
requirements. For example a health program may have a couple of
 projects short term and long term all reporting to the program manager.
An education project may be organized on a matrix using resources part-
time from other units, and a large water project organized as a fully
project-based were all staff report to the project manager. It is not unusual
to find this type of mixed designs on development organizations.

Project Planning Bottom-up vs. Top-down:

A Software Project is the complete methodology of

programming advancement from requirement gathering to
testing and support, completed by the execution procedures, in a
specified period to achieve intended software product.
When it comes to projects, there are two schools of thought
 Top-down
 bottom-up

Fig 2.11 top down and bottom up approach

Top-down approach

with the final deliverable (project goal) and break it down into
smaller, more manageable tasks. These tasks can be further
broken down into subtasks — great details — and then assigned
to individual teams and/or team members within that team.

Example: You need to update the FAQ section on your website.

This is a task your team has completed in the past. The scope is
clear, the timeline defined, the subtasks straightforward. A
perfect time for a simple, top-down approach.Top-down tends to
be more autocratic (we are telling you what to do, now go do it).
Bottom-up approach

The bottom-up approach to project management means that you

begin with brainstorming possible solutions to meet that final
deliverable. In other words, you know what the project goal is,
but are not sure (yet) how to get there. A bottom-up approach
involves all members of the team working together to determine
the necessary tasks to reach that final end product.

Example: You are embarking on an entirely new product

based on feedback from your customers. You need input from
the entire team as this is a process you’ve never been through
before. A bottom-up approach works best in this situation.

Bottom-up tends to be more democratic (we are not sure how to

do it, but as a team, we’ll figureit out).

In this blog post, we’ll review different styles of

management/leadership, discuss the pros and cons of top-down
vs. bottom-up for project management, and share how
monday.com can helpnavigate whatever approach you choose!
What are top-down/bottom-up leadership styles?

When it comes to management and leadership styles, there are

also two different approaches. Again, surprise surprise, top-
down vs. bottom-up. At monday.com, we are strong advocates
for a top-down approach to managing and leading. In fact,
leading through a bottom-up approach is one of the 5 pitfalls
first-time (and sometimes more experienced) managers tend to
make.

We suggest including a real-time “stand-up” meeting as one of

a manager’s daily tasks. These quick, specific meetings provide
a high-level update on the plan, checking in with each team
member to ensure they are on track to accomplishing their goals
— understanding roadblocks, what’s important, and what’s not
needed to meet the end goal.

If one approaches leading through a bottom-up style, it becomes

muddy real quick. It’s challenging to understand where a project
stands by just looking at task completion status — you are
missing the data that supports that specific task.

Managing from the bottom up is like knowing the completion of

a mountain climb by countingthe steps you’ve made towards the
top — the chances you’ve made the right assumptions for this
count is like winning the lottery. Counting visible checkpoints is
better and the only thing you really need.

Generally speaking, this top-down approach to leadership works well in

designers and software
development as a “reverse product engineering” style means a better
 final product.which is better: top-down or bottom-up it depends.

A top-down approach to project management tends to work better

when there is a clear direction and an overall understanding of how a
project fits into the larger goals of the organization. With repeatable
projects — projects teams have successfully completed before — a
top-down approach often makes the most sense as a process has
already been established.

A good project manager is able to quickly identify the big-picture

tasks, while the team focuses on the day-to-day deliverables.

Possible downside: Some of the finer project details may be

overlooked.

A bottom-up approach to project management tends to work better for

brand new projects, ones where your team does not have prior
experience. This approach means that teams can begin to brainstorm
and identify unknown risks.

Using this approach means more of the team will have input into the
process — a freeflow of ideas and information is created. This, in
turn, often means there will be more “out of the box” type thinking
as individuals think through various solutions to the task(s) at hand.

Typically, a bottom-up approach means there are more details (and

maybe even more tasks).

Possible downside: Time-consuming and resource-heavy.

When it comes to estimating task duration, a critical component to

any project plan, managers often use both a bottom-up and a top-
down approach:

 Bottom-up: Allows teams to estimate how long each sub-task will

take. This timethen rolls up into an overall time-to-project-
completion estimate.
 Top-down: Starting with an estimate of how long the entire project
will take, thenbreaking it down into the various tasks.

Leveraging both a bottom-up and top-down approach concurrently

means ensures a more accurate overall time estimate.

Activities

Software Project Management consists of many activities, that

includes planning of the project, deciding the scope of product,
estimation of cost in different terms, scheduling of tasks, etc.

The list of activities are as follows:

1. Project planning and Tracking

2. Project Resource Management
3. Scope Management
4. Estimation Management
5. Project Risk Management
6. Scheduling Management
7. Project Communication Management
8. Configuration Management

Now we will discuss all these activities -

1. Project Planning: It is a set of multiple processes, or we can

say that it a task that performed before the construction of the
product starts.

2. Scope Management: It describes the scope of the project.

Scope management is important because it clearly defines what
would do and what would not. Scope Management create the
project to contain restricted and quantitative tasks, which may
merely be documented and successively avoids price and time
overrun.

3. Estimation management: This is not only about cost

estimation because whenever we start to develop software, but
we also figure out their size(line of code), efforts, time as well as
cost.

If we talk about the size, then Line of code depends upon user or software
requirement.

If we talk about effort, we should know about the size of the

software, because based on thesize we can quickly estimate
how big team required to produce the software.

If we talk about time, when size and efforts are estimated, the
time required to develop thesoftware can easily determine.

And if we talk about cost, it includes all the elements such as:

o Size of software
o Quality
 o Hardware
o Communication
o Training
o Additional Software and tools
o Skilled manpower

4. Scheduling Management: Scheduling Management in

software refers to all the activities to complete in the specified
order and within time slotted to each activity. Project managers
definemultiple tasks and arrange them keeping various factors in
mind.

For scheduling, it is compulsory -

o Find out multiple tasks and correlate them.
o Divide time into units.
o Assign the respective number of work-units for every job.
o Calculate the total time from start to finish.
o Break down the project into modules.

5. Project Resource Management: In software Development,

all the elements are referred to as resources for the project. It
can be a human resource, productive tools, and libraries.

Resource management includes:

o Create a project team and assign responsibilities to every team member

o Developing a resource plan is derived from the project plan.
o Adjustment of resources.

6. Project Risk Management: Risk management consists of

all the activities like identification, analyzing and preparing the
plan for predictable and unpredictable risk in the project.

Several points show the risks in the project:

o The Experienced team leaves the project, and the new team joins it.
o Changes in requirement.
o Change in technologies and the environment.
o Market competition.

7. Project Communication Management: Communication is

an essential factor in the success of the project. It is a bridge
 between client, organization, team members and as well as other
stakeholders of the project such as hardware suppliers.

From the planning to closure, communication plays a vital

role. In all the phases, communication must be clear and
understood. Miscommunication can create a big blunder inthe
project.

8. Project Configuration Management: Configuration

management is about to control thechanges in software like
requirements, design, and development of the product.

The Primary goal is to increase productivity with fewer errors.

Some reasons show the need for configuration management:

o Several people work on software that is continually update.

o Help to build coordination among suppliers.

o Changes in requirement, budget, schedule need to accommodate.

o Software should run on multiple systems.

Tasks perform in Configuration management:

o Identification
o Baseline
o Change Control
o Configuration Status Accounting
o Configuration Audits and Reviews

People involved in Configuration Management:

Fig 2.11 Configuration Management

Project Scheduling and staffing
A schedule in your project’s time table actually consists of sequenced activities
and milestones that are needed to be delivered under a given period of time.
Project schedule simply means a mechanism that is used to communicate and
know about that tasks are needed and has to be done or performed and which
organizational resources will be given or allocated to these tasks and in what time
duration or time frame work is needed to be performed. Effective project
scheduling leads to success of project, reduced cost, and increased customer
satisfaction. Scheduling in project management means to list out activities,
deliverables, and milestones within a project that are delivered. It contains more
notes than your average weekly planner notes. The most common and important
form of project schedule is Gantt chart.

Process :

The manager needs to estimate time and resources of project while scheduling
project. All activities in project must be arranged in a coherent sequence that
means activities should be arranged in a logical and well-organized manner for
easy to understand. Initial estimates of project can be made optimistically which
means estimates can be made when all favorable things will happen and no
threats or problems take place.
The total work is separated or divided into various small activities or tasks during
project schedule. Then, Project manager will decide time required for each
activity or task to get completed. Even some activities are conducted and
performed in parallel for efficient performance. The project manager should be
aware of fact that each stage of project is not problem-free.
Staffing is the art of acquiring, developing, and maintaining a satisfactory and
satisfied workforce. Staffing is that function by which a manager builds an
organization through the recruitment, selection, and development of the
individual, which also includes a series of activities. It ensures that the
organization has the right number of people at the right places, at the right time,
and performing the right thing.
1. Manpower Planning
Human resource management is a process of determining the number and type of
personnel required for filling the vacant job in an organization. Manpower
requirements involve two kinds of analysis, i.e., workload analysis and workforce
analysis. Workload analysis involves determining the number and type of
employees required to perform various jobs and achieve organizational
objectives. Workforce analysis shows the number and type of human resources
available with an organization.

2. Recruitment
After estimating manpower requirements, the second step in the process of
staffing is recruitment. Recruitment refers to a process of searching for
prospective employees and encouraging them to apply for jobs in the
organization. It involves identifying various resources of human force and
attracting them to apply for the job.
3. Selection
Selection is the process of choosing and appointing the right candidates for
various job positions in the organization.
4. Placement and Orientation
After selection, an appropriate job is assigned to each selected person. Placement
is the process of matching the candidates with the jobs in the organization. Under
this process, every selected candidate is assigned a job most suitable for him. The
purpose of placement is to fit the right person to the right job so that the
efficiency of work is high and the employees get personal satisfaction.
5. Training and Development
People are in search of careers and not jobs. Every individual must be given a
chance to rise to the top. The most favourable way for this to happen is to
promote employee learning. For this, organizations either provide training
themselves within the organization or through external institutions.
6. Performance appraisal
After training the employees and having them on the job for some time, there
should be an evaluation done on their performance. Every organization has its
means of appraisal whether formal or informal. Appraisal refers to the evaluation
of the employees of the organization based on their past or present performance
by some pre-decided standards.
7. Promotion and Career planning
The managers should take care of the activities that serve the long-term interests
of the employees. They should be encouraged from time to time, which will help
the employees to grow and find their true potential.
8. Compensation
Every organization needs to set up plans for the salary and wages of the
employees. There are several ways to develop payment plans for the employees
depending upon the significance of the job.

Project Duration: Schedule Monitoring Tools

PERT Chart:

• PERT (Project Evaluation and Review Technique) is a

representation of Activity Network where activities are represented by boxes
and arrows represents their dependencies. In a PERT chart pessimistic, likely,
and optimistic estimates are made for each task instead of making a single
estimate. This makes critical path analysis in PERTcharts very complex.
• The PERT chart representation of the above demo
activity project of figure 4.5 is shown in figure 4.6. PERT charts are a more
complicated form of activity chart. With the use of PERT chart monitoring the
timely progress of activities is possible.
Steps in PERT
• Step 1: Identify all the project’s activities.
• First, define all the major phases, milestones, and tasks needed to
complete the project.
• Step 2: Identify dependencies
If you determine some tasks or activities have dependencies, you will want
to depictthose tasks with directional arrows. This will ensure your team
knows the sequence they need to tackle each task.

• Step 3: Draw your chart.

The next step is to take the events and milestones (numbered nodes) you’ve
identified and draw them out. Then write out the tasks and activities that the
team must completebetween each node, using directional arrows or divergent
arrows accordingly.
• Step 4: Establish timelines for all activities.
You should now set a timeframe when the team will need to complete those
tasks along with all arrows. For example, in our mockup above, you can see
the “Train sales” activity has a timeframe of 1 day. This can represent the
estimated timeframeand/or deadline you set for the activity.

Fig. 2.19 Dependency

Fig 2.20 PERT chart

1) Optimistic Time(O)- Minimum Time

2) Pessimistic Time(P)-Maximum Time
3) Most Probable Time(M)- Normal Time

Expected time of activity (TH)= (O+4M+P)/6

Gantt chart
A Gantt chart is a project management tool that illustrates a project plan. It typically includes two
sections: the left side outlines a list of tasks, while the right side has a timeline with schedulebars that
visualize work. The Gantt chart can also include the start and end dates of tasks, milestones,
dependencies between tasks, and assignees. To keep up with the demands of modernsoftware
development, roadmap tools like Jira Software include features like a collapsible taskstructure and
resource management panels. These roadmap tools help teams maintain a coherentproject strategy
despite the iterative nature of the software development process.

Origins of the Gantt chart

In the early part of the 20th century, Henry Gantt revolutionized project management with
Gantt charts. At that time, they were written out on pieces of paper. With the rise of
computers in the 1980s, Gantt charts became increasingly complex and elaborate. Today,
Gantt charts are still one of the most widely used project management tools.

Today, Gantt chart tools are often referred to as roadmap tools. Jira includes two roadmap
tools to create Gantt charts for your projects: Roadmaps, which creates plans around Jira
issues assigned to a team, and Advanced Roadmaps, which does the same thing across
teams and organizations.
What is a Gantt chart used for?
Project managers use Gantt charts for three main reasons:
Build and manage a comprehensive project
Gantt charts visualize the building blocks of a project and organize it into smaller, more
manageable tasks. The resulting small tasks are scheduled on the Gantt chart's timeline,
along with dependencies between tasks, assignees, and milestones.
Determine logistics and task dependencies
Gantt charts can be employed to keep an eye on the logistics of a project. Task
dependencies ensure that a new task can only start once another task is completed. If a task
is delayed (it happens to the best of us), then dependent issues are automatically
rescheduled. This can be especially useful when planning in a multi-team environment.
Monitor progress of a project
As teams log time towards issues in your plan, you can monitor the health of your projects
and make adjustments as necessary. Your Gantt chart can include release dates, milestones,
or other important metrics to track your project’s progress.
The benefits of using a Gantt chart
There are two main reasons why Gantt charts are loved throughout the project
management world. They make it easier to create complicated plans, especially those that
involve multiple teams and changing deadlines. Gantt charts help teams to plan work
around deadlines and properly allocate resources.
Projects planners also use Gantt charts to maintain a bird’s eye view of projects. They
depict, among other things, the relationship between the start and end dates of tasks,
milestones, and dependent tasks. Modern Gantt chart programs such as Jira Software with
Roadmaps and Advanced Roadmaps synthesize information and illustrate how choices
impact deadlines.
Disadvantages of Gantt Chart
• Require more efforts for Creating and Managing the Chart
• Updating a Chart is Very Time Consuming
• All Tasks are not visible in a single view of a Gantt
• Need to scroll and Click additional buttons to view remaining items
• Stacks represents only the time and not the hours of the work
• Not easy to re align the tasks from on section to another
• Not easy to calculate the aggregates
 Steps to Building an Effective Software
Development Team
1. Define the kind of development team type that fits for your project
-Generalists
-Specialists
-Hybrid team
2. Decide on the software development team size
- Complexity of your project
- Budget
- Deadline
- Available resources
3. Establish clear roles and goals
 Personality Traits
In psychology, the Big Five personality traits are five broad domains or dimensions of
personality that are used to describe human personality. The theory based on the Big
Five factors is called the five-factor model(FFM).

1.Openness: Curiosity, imagination, and valuing variety.

2.Conscientiousness: Being collected, analytical, and meticulous.
3.Social responsibility: Desiring fair outcomes and having concern for others.
4.Ability to learn: Persistence and focus.
5.Pragmatism: Prioritizing logic and addressing root causes.
 Types of Leadership Style
1. Autocratic
• Leader makes decisions without reference to anyone else
• High degree of dependency on the leader
• May be valuable in some types of business where decisions need to be made quickly
and decisively.
• Can create de-motivation and alienation of staff
2. Democratic
• Encourages decision making from different perspectives – leadership may be
emphasised throughout the organisation
• Consultative: process of consultation before decisions are taken
• Persuasive: Leader takes decision and seeks to persuade others that the decision is
correct
• May help motivation and involvement
• Workers feel ownership of the firm and its ideas
 Types of Leadership Style
3. Laissez-Faire
• ‘Let it be’ – the leadership responsibilities are shared by all
• Can be very useful in businesses where creative ideas are important
• Can be highly motivational, as people have control over their working life
• Can make coordination and decision making time-consuming and lacking
in overall direction
• Relies on good teamwork and good interpersonal relations
 Types of Leadership Style
4. Paternalistic
• Leader acts as a ‘father figure’
making decisions for other people rather than letting them take
responsibility for their own lives
• Paternalistic leader makes decision but may consult
• Believes in the need to support staff
 Change Leadership
• The most challenging aspect of business is leading and managing
change
• The business environment is subject to fast-paced economic and
social change
• Modern business must adapt and be flexible to survive
• Problems in leading change stem mainly from human resource
management
• Leaders need to be aware of how change impacts on workers
 Theories of Leadership
• Is there a set of characteristics that determine a
good leader?
• Personality?
• Dominance and personal presence?
• Charisma?
• Self confidence?
• Achievement?
• Ability to formulate a clear vision?
• Are such characteristics inherently gender
biased?
• Do such characteristics produce good
leaders?
• Is leadership more than just bringing about change?
• Does this imply that leaders are born not bred?
 Theories of Leadership
• Behavioural:
• Imply that leaders can be trained – focus on the way of doing
things
• Structure based behavioural theories – focus on the leader

instituting structures
– task orientated
Relationship based behavioural theories – focus on the
development and maintenance of relationships – process
orientated
 Contingency Theories
Leadership as being more flexible – different leadership styles used at
different times depending on the circumstance.
Suggests leadership is not a fixed series of characteristics that can be
transposed into different contexts
May depend on
• Type of staff

• History of the business

• Culture of the business

• Quality of the relationships

• Nature of the changes needed

• Accepted norms within the institution

 Contingency Theories
• Transformational: to a business or organisation
• Requires:
• Long term strategic planning

• Clear objectives

• Clear vision

• Leading by example – walk the walk

• Efficiency of systems and processes

• Invitational Leadership: Improving the atmosphere and

message sent out by the organisation
• Focus on reducing negative messages sent out through

the everyday actions of the business both externally and,

crucially, internally
 PROJECT ORGANIZATION

• The main objective of Project organization is to establish the relationship

among:
• The work to be done

• The people doing

• The work

• the work place(s)

A project organization is a structure that facilitates the coordination and

implementation of project activities. Its main reason is to create an
environment that fosters interactions among the team members with a
minimum amount of disruptions, overlaps and conflict.
 FACTORS IN DESIGNING A PROJECT STRUCTURE

There are two design factors that significantly influence the process of developing a
project management structure.
1. Specialization
- affects the project structure by the degree of specialty in technical areas or
development focus
- projects can be highly specialized and focus on a specific area of development or
have different broad specializations in many areas of development.
2. Coordination
- is required to bring unity to the various elements that make up a project.
- The project work is organized around a work breakdown structure (WBS) that
divides the overall project goals into specific activities or tasks for each project area
or component
 TYPES OF PROJECT ORGANIZATIONS STRUCTURES

1. Programmatic Based
Teams are organized by function. Group of people working with similar role.
Authority-driven decision making. Eg. Budgeting, Scheduling, Purchasing,
More skilled employees. Used for large projects.
Eg. Advertising, Engineering, Manufacturing
2. Project Based
Entire organization is focused on projects.
3. Matrix Based
Combines functional and project-based structures.
Project Planning Bottom-up vs. Top-down
 Activities
Software Project Management consists of many activities

1. Project planning and Tracking

2. Project Resource Management
3. Scope Management
4. Estimation Management
5. Project Risk Management
6. Scheduling Management
7. Project Communication Management
8. Configuration Management
 Activities

1. Project Planning: performed before the construction of the product starts.

2. Scope Management: Scope management is important because it clearly

defines what would do and what would not.

3. Estimation management: This is not only about cost estimation because

whenever we start to develop software, but we also figure out their size(line of
code), efforts, time as well as cost.
 Activities

4. Scheduling Management: Scheduling Management in software refers to all the

activities to complete in the specified order and within time slotted to each activity.
Project managers define multiple tasks.

5. Project Resource Management: In software Development, all the elements

are referred to as resources for the project. It can be a human resource,
productive tools, and libraries.
 Activities
6. Project Risk Management: Risk management consists of all the activities like
identification, analyzing and preparing the plan for predictable and unpredictable risk
in the project.

7. Project Communication Management: Communication is an essential factor in

the success of the project. It is a bridge between client, organization, team members
and as well as other stakeholders of the project such as hardware suppliers.
 Activities
8. Project Configuration Management: Configuration management is about
to control the changes in software like requirements, design, and development
of the product.

The Primary goal is to increase productivity with fewer errors.

 Project Scheduling and staffing
Project schedule simply means a mechanism that is used to communicate
and know about that tasks are needed and has to be done or performed
and which organizational resources will be given or allocated to these
tasks and in what time duration or time frame work is needed to be
performed.
 Staffing
Staffing is the art of acquiring, developing, and maintaining a satisfactory and satisfied
workforce. Staffing is that function by which a manager builds an organization through the
recruitment, selection, and development of the individual, which also includes a series of
activities.

•Staffing Process
•1. Manpower Planning
•2. Recruitment
•3. Selection
•4. Placement and Orientation
•5. Training and Development
•6. Performance appraisal
•7. Promotion and Career planning
•8. Compensation
 Project Review
What is a Project Review?

A Project Review is an assessment of the status of a project, at a particular point in time. The
first time in the project life cycle that a project review is undertaken is at the end of the first
project phase, called "Initiation". During this project review, a decision is made as to whether
or not the team has met the objectives and is approved to proceed to the next project phase,
being the "Planning" phase. Performing a project management review at the end of each phase
is critical to the success of the project, because it allows the Project Sponsor to control the
progress of the project and make sure that it passes through each Project Phase smoothly.

When do I complete a Project Review?

As soon as the project team believes they have completed a particular project phase, a project
review should be undertaken. There will usually be at least three project reviews during the
project life cycle: at the end of the Initiation, Planning and Execution project phases. The
template on this page will help you complete a project review for the "Initiation" project
phase. The items included in the project review form are targeted towards this phase
specifically.

Form is completed at the end of the Initiation project phase to tell the sponsor whether the
project has achieved its objectives to date.
First, a Project Management Review is conducted to measure the deliverables produced by the
project, then the results of the review are documented on this Project Review form which is
presented to the sponsor for approval.

Project Phase reviews are conducted at the end of the Initiation, Planning and Execution
phases within a project. This form helps you to complete a project review for the the
'Initiation' project phase.

The form helps you to document the results of your Project Review, by stating whether
the:

​ Project is currently delivering to schedule

​ Budget allocated was sufficient at this point
​ Deliverables have been produced and approved
​ Risks have been controlled and mitigated
​ Issues were identified and resolved
​ Changes were properly managed
​ Project is on
track The form helps you
to:

​ Document the results of your Project Review

​ Clearly communicate the progress of your project to your sponsor
​ List any risks or issues which have impacted the project
 ​ Show sponsor the deliverables produced to date
​ Seek approval to proceed to the next phase
By implementing Phase Reviews, you are putting in place the necessary "check-points" to
monitor and control the project, thereby ensuring its success.

THE PROJECT TRACKING MEETING

THE PROJECT TRACKING MEETING and its derivative actions serves as the primary
driving force behind the project. Here are responses to some frequently asked questions about
this control mechanism.

What is the primary purpose for project tracking meetings?

Project planning is about getting in control. Project tracking is about staying in control. The
No. 1 reason for project tracking meetings is to identify potential project problems before they
occur. The No. 2 reason is to ensure that recovery plans are put in place before unrecoverable
harm occurs. Project tracking is predominately focused on being proactive, not reactive.

How often should a project formally be tracked?

Project tracking meetings should occur once a week. (The exceptions are small-duration
projects that are only several weeks or less in duration, in which case, project tracking
meetings could occur more frequently.) Meeting less often than each week can delay the
discovery or discussion of serious problems, which can harm the successful outcome of the
project. Meeting more frequently than weekly can be quite unproductive and waste scarce
time, because it requires members of the project tracking meeting to spend additional time
preparing more than one progress status per week. It also requires the project tracking meeting
members to spend additional time in meetings rather than being free to work their plans.

Does it matter what day of the week the project tracking meeting is conducted?

Yes. Routine project tracking meetings are very important to the health of a project and
require participants to attend—on time and prepared. Therefore, avoid having meetings on
Mondays or Fridays; these days are often used as holidays or personal days for extended
weekends. Furthermore, meeting participants use Mondays to catch up on progress that may
have occurred over the weekend. This leaves Tuesdays, Wednesdays and Thursdays for the
meeting. My favorites are Tuesdays and Wednesdays, because I like to reserve the day after
the project tracking meeting for work and escalation meetings to address unresolved issues or
new issues identified from the meeting. This means that Thursday would be used as the
reserved day if the project tracking meeting were held on Wednesday.

What if project members find themselves assigned to more than one project?

If there are multiple ongoing projects across an organization and, referring to the answer to
the previous question, all project tracking meetings were held on Tuesdays and Wednesdays, it
seems that there would be too many meeting conflicts. However, most organizations seldom
experience this problem. In those cases where it does occur, the project managers need to
meet among themselves and carefully coordinate their project tracking meetings to avoid such
conflicts.
Who should attend project tracking meetings?

Everyone might attend for small projects of, say, 10 or fewer members. For all larger sized
projects, a representative from each organization or team would attend. Managers typically
should not own activities or tasks and, therefore, are optional attendees. However, the most
effective managers will attend as often as they can to support their employees who are
assigned to the project.

Is it overkill for the project tracking meeting participants to meet briefly every day?

The weekly, formal project tracking meeting is a must. However, here is an additional
technique that can work surprisingly well:The project manager can meet with participants of
the project tracking team for 15–30 minutes at the start of each workday to ensure that the
top-priority problems are receiving the attention they require. This mostly is an informal
meeting that requires little preparation, if any, from the participants.

These subjects are presented at tracking meetings in the order described here.

Project High-Priority Areas. The project manager displays the top three to five problems now
plaguing the project, while their “owners” report any late-breaking news. These problems are
currently impacting a major project milestone (often called an “issue”) or have the potential
(called a “risk”) to do so. The project manager tracks these high-priority areas daily, all other
project progress/problems are tracked weekly.

Overview of Project Progress. The project manager presents this information on a single chart
that lists the project's major milestones. The chart is first presented as a high-level view of the
project plan and is updated for each tracking meeting to illustrate the “big picture” of where
the project's progress is in relation to where it was planned to be. This chart has special
interest to the project's sponsor and client. It is expected to be a reasonably good view of the
forest without obstruction from all the trees. The chart likely will require updating by the end
of the tracking meeting after all participants have presented their status.

Progress of Project Activities. Each participant of a project tracking meeting presents their
status against their portion of the project plan. This status includes metrics to substantiate the
progress made, identifies their top three to five priorities and their corresponding status, and a
30-day outlook of what can be expected, including whether or not help is required.

Progress of Action Items. An action item is a project problem that is logged, assigned to an
owner to resolve, and then tracked until it is closed. The owners of action items present their
progress. Presentations of action items can be performed at the same time a participant has the
floor to present his or her progress of project activities.

Project Outlook. The project manager forecasts a 30-day outlook for the project. That is, 30
days from now, will the project be on schedule, within cost, and what is the overall likelihood
(high, medium, low) that the project will complete as planned? Although this information
initially should be prepared before the meeting, it is likely that it must be altered real-time
based on the latest information collected at the meeting.

Schedule Work/Escalation Meetings. The project manager spends the last moments of the
meeting declaring what project activities and action items require special attention over the
next
two to three days. If possible, these meetings should be scheduled now, preferably for the
following day. These meetings typically become priorities within the project.

THE MEETING AGENDA should be published and followed throughout the meeting. The
project manager has the authority to declare that only a subset of the participants present their
plan status, as well as which action items are presented. All status not presented must still be
submitted to the project manager at the end of the meeting. This allows the project manager to
study the status without subjecting everyone to presentations on other than the currently most
important areas of the project plan and action items.

The project manager must lead these meetings so that they run on schedule and are
productive. A beneficial technique is for the project manager to assign a scribe to record the
meeting notes so that the project manager is free to concentrate on effectively running the
meeting. This meeting and its derivative actions serve as the primary driving force behind the
project. As these meetings go … so goes the project

Project Recovery(Recovery Plan)

Recovering a project that is really troubled is not for the faint hearted. It is the opinion of this
author that recovery is not achievable and repeatable without a project recovery methodology.
The more complicated a project is, the greater the importance of a recovery methodology.

A number of project recovery methodologies exist. The majority of the project recovery
methodologies have a four-step process, namely (1) audit/identification of current status, (2)
analysis of the problems (fault finding), (3) negotiate the recommended actions, and (4)
implement the recovery plan.

Exhibit 3 depicts the high level project recovery methodology and associated actions:

Fig. 3.1 Exhibit 3: High-level project recovery methodology.

Step 1: Audit the project. The primary aim of this step is to review all the project
documentation to determine the current status. All the relevant stakeholders should be
interviewed to obtain their understanding in terms of expectations, issues, and risks. The
majority of the problems should be identified through the audit process.

Step 2: Analysis of the problems. Analyze every identified problem on the project. Identify
the burning platforms. Also ensure that the basics are put in place, such as redefining or
confirming
the scope of the project. Identify the real schedule and cost drivers. Suspend or eliminate
deliverables in the scope that are not immediate requirements for achieving the project
objectives and re-schedule it as far in the future as possible. Draw up a new plan aimed
specifically at the recovery effort. Be realistic in terms of what is achievable with the current
funds and resources.

Step 3: Negotiate the recommended actions with the major principals. The principals' support
is critical to implementing the recovery plan. Present the recovery plan to them, substantiate
each and every action in the plan, and negotiate where possible. This negotiation will also
create new expectations and ownership from the stakeholders and ensure that the new
baselines will be the ones that measurement is made against.

Step 4: Implement the recovery plan. Follow a sound project management methodology.
Control the project by means of the performance measurement baseline and manage issues
actively. Make sure communication channels are open to the stakeholders, keeping them
informed is a critical success factor for continued support; otherwise, they might get easily
disillusioned. Escalate major issues to ensure that the steering committee also takes ownership
in the project. Enforce discipline — this is no time to relax! Celebrate each and every
achievement, because this will motivate the team.

Saving the Project Objectives

The project recovery methodology as described above was implemented. The audit revealed
some of the obvious problems that exist on a troubled project. The scope was poorly defined
and did not include all of the intended deliverables of the project. The poor scope definition
resulted in an incomplete schedule and budget. Resources were not leveled or poorly planned.
Issue management was not done formally, resulting in a number of the warning signs not
recognized. There was no project management methodology defined, thus no real project
controls. The project budget was not fully developed, thus the project manager had no control
over the project costs. The development of the hectares and planting of the bananas were still
the major drivers of the project. This made it easier to recover. On further investigation, it also
appeared that the target set for the end of 2009 was to plant 1,000 hectares and not the 750
hectares as was stipulated in the project objectives. Thus recovering the schedule might not be
as difficult as thought in the beginning.

The following recommendations were made to the project steering committee:

Define the complete scope of the project; this will enable better planning and costing of the
project.

Return to the project objective to plant only 750 hectares by the end of 2009 and not the 1,000
hectares. Do not introduce actions now that will accelerate the planting schedule, but might
complicate the steady state farming in the future; in other words, stick to the 10 hectares per
week per farm. As soon as the planting rate of 10 hectares per week per farm is stabilized, one
can always launch one of the other farms earlier and ramp-up the planting rate to 30 hectares
per week over three farms. This will meet the schedule requirements.

Determine which deliverables are critical for providing the fruit and determining which
deliverables can be procured later. Thus, place all deliverables that are not directly related to
the planting rate subordinate to those that are. One such deliverable was a major IT
infrastructure that was not critical, but a major cost driver, and should be suspended or placed
on hold.

Introduce a project management methodology and execute the project according to it.

Micromanage the planting activities by having a planning meeting the day before, an
instruction meeting each morning before work commences, and a control meeting before the
planning meeting for the next day. Bring back discipline, which is what project management
is all about anyway.

The project steering committee accepted all these recommendations and the implementation
of the recovery plan commenced.

The recovery effort, with a lot of effort, started yielding the desired results within two months.
The planting occurred at the desired 10 hectares per farm per week and stabilized on 20
hectares planted per week. The third farm was introduced earlier and the rate increased to the
desired 30 hectares per week for the three farms. The forecasts indicated that the 750 hectare
target would be met before the target date and this without compromising the quality of the
fruit. Efforts were also put in place to train the project team members in project management
and the project management methodology to ensure that after the consultants depart, the
expertise remains. The project was under control and back on track — success!

Escalation Meetings
The Escalation Process clarifies the boundaries and channels of decision-making throughout
an organization in order so solve the problem quickly and with clarity. Designed around the
concept of a core project team with a clear project manager, this process outlines a path that
allows the core team to make decisions at lower levels of the org chart while having a
predefined path for exception management.

This might be called an escalation plan, or escalation workflow that moves a high-priority
issue up to a higher level. It minimizes the time it takes to escalate decisions that are beyond
their scope of authority. It is among the essential tools for an agile product development
process. Though it is used extensively for customer support, customer service agents, and
managing SLA timeframe, it can also be an essential tools for an agile product development
process.

Escalation Management in Four Steps

A project manager creates the process (or escalation matrix) in four steps:
 Fig. 3.2 Sample project escalation map
1. decision categories: these can include areas such as finance, staffing, tools, and
Define technical features/functionality. When defining the categories, the project manager
should be mindful of the right balance in the number of categories based on the complexity of
your organization. Project managers should to avoid too many issues to take to the next level
to overburden the process, and too few will not provide a meaningful escalation path. This is
especially important in new product development, where there is inherently more risk.
2. In each category, project managers should determine the appropriate escalation
procedure by functional responsibility. Project managers should start at the lowest level in the
organization, typically an individual contributor. Some decision categories can have parallel
communications (functional and cross-functional) and typically this flows from the project
manager.
3. Define the key organizational contributors and their decision-making authority
including the project manager. This can vary based on the size and complexity of the project.
In some cases, there will be dual communication paths (functional and project) to ensure rapid
decision- making.
4. The project manager then reviews with management to get agreement on the
categories, decision authority, and escalation procedure. It is the decision authority and the
process to raise an escalation should be signed off by management – this is most important.
What Are The Benefits of the Escalation Process for Project Managers?

Minimizes delays in delivering products to market.

Drives accountability in the decision-making process.
Saves time and energy by providing a clear escalation path for decision-making.
Educates new team members on how to make decisions quickly.

In general, the escalation should be resolved in hours/days not days/weeks.

Escalation Meeting

The Executive Escalation Meeting will meet and discuss how and when a specific decision or
a recommendation made at the level of the Euronext Derivatives Steering Committee is to be
implemented and may ask the Euronext Derivatives Steering Committee to reconsider the
decision or recommendation in question in light of constraints or difficulties linked to the
implementation or new facts discussed in the Executive Escalation Meeting.

Board Meeting means a meeting of the Board;

Open meeting or "public meeting" means a meeting at which the public may be present.

Annual Meeting means the annual meeting of the stockholders of the Company.

Product Requirements Lifecycle

The product requirements lifecycle includes the following phases:

Requirements gathering,

Requirements analysis,

Requirements verification / validation,

Requirements management and tracking,

Requirements specification (documentation).

We will now briefly describe each of these phases.

Gathering of Product Requirements

In this phase - we have to determine the sources of the product requirements and the approach
for their handling and management. It is important to identify all of the sources:
Objectives - also known as ‘Business concerns’ or ‘Critical Success Factors’, represent the
comprehensive goal of the product. Special attention should be paid to the cost of reaching the
target (through a feasibility study).

Domain knowledge - a production engineer needs to have knowledge of the product’s

application domain and to be ahead of others; to resolve conflicts in the requirements and to
be a mediator between all participants.

Stakeholders - some products might prove to be unsatisfactory, because of the different

perspectives of the stakeholders. The product engineer needs to identify a correct
representation and to manage these situations (different culture and politics).

Operating environment - product requirements come from the environment in which the
product is used on daily basis.

The organizational environment - the product will have to support the business environment
and the processes (conditions) that it will be used it. New product should not bring unplanned
changes, so it requires careful analysis by the product creators, before making a final decision.

When all sources are identified - the product engineer can start the requirements elicitation
(gathering). This area deals with the techniques for selection and extraction, which can be
particularly sensitive. For example, users may have difficulty in defining actions and
sometimes they omit important information. These techniques are not passive and require hard
work for the articulation of all requirements. The interview represents a traditional way of
collecting client’s requests. This technique has certain advantages and limitations.

It is necessary to prepare scenarios for the requirements elicitation:

Providing a framework for defining the questions: What if...? How is this done..? etc.

Using a technique known as Conceptual modeling - i.e. Case Modeling and Diagrams.

Also, holding meetings (brainstorming) and group work can be more efficient than individual
techniques of observation (observing how users will use the product and interact with it).

Requirements Analysis

After the process of requirements gathering - a process for their analysis is necessary.
Requirements analysis refers to the processes required in order to:
Identify and resolve the conflicts between the product requirements;

Detection of product features, and how the product will behave in real environments;

Elaboration of product requirements in the process of product development.

The traditional view of the analysis requires the use of conceptual modeling and other
methods for analysis, such as the Structured Analysis and Design Technique (SADT).

The most important thing is to accurately describe the clients’ requirements, in order to
facilitate their validation, verification of their implementation, and the cost estimates.

Requirements analysis includes:

The primary mechanism for requirement validation is a formal technical review. The review
team includes engineers, customers, and other stakeholders who are checking product
specification for content errors, areas that need clarification, insufficient information,
inconsistencies (a major problem when making large products or systems), conflicting
demands, or unrealistic requirements (which cannot be achieved).

Although requirement validation can be done in order to uncover potential errors, it is useful
to check each requirement according to a predefined list of questions. The following questions
are only a small part of what can be asked:

• Are the requirements clearly stated? Can they be misinterpreted?

• Are all the aspects of the product operation (functioning) covered?

• Is the source of the request identified (e.g. person, regulation, document)? Has the
final form of the requirement been verified from the original source?

• Is the requirement quantified?

• What other requirements are associated with this requirement? Are they clearly stated
using a reference matrix or other mechanism?

• Does the requirement affect domain restrictions?

• Can the requirement be tested? If it can, can we determine tests (so-called validation
criteria) for checking the requirement?
• Can the requirement be tracked in any product that will be created?

Product Requirements Management and Tracking

It was stated above that the product requirements are changing and that there might be a need
to change requirements throughout the product lifecycle. Requirement management is a set of
activities that helps the project team identify, control, and track requirements and their
changes at any point in the product's life. Also in this step - requirements prioritization and
re-ordering can be done.

The requirements management begins with identification. Each requirement is assigned a

unique identifier of the following form:

<type requirement> <requirement Id>

where < type requirement> can receive these possible values: F = functional requirement, B =
behavioral requirement, I = input requirement, O = output requirement etc. Thus, the
requirement identified by F09 denotes a function requirement number 9.

Once the requirements have been identified, monitoring (tracking) tables are developed. Each
tracking table links specific requirements to one or more aspects of the product or the
environment. Some of the many tracking charts are the following:

Properties Tracking Table - displays how the requirements relate to the visible features of the
product.

Source (reason) tracking table - identifies the source of each requirement.

Dependency Tracking Table - indicates how the requirements are related to each other.

Subsystem Tracking Table - categorizes requirements according to the subsystems they

belong to.

Product Requirements Documentation

After the gathering and the analysis of the product requirements - the product analyst and the
project team should specify all product requirements. Under the requirements specification -
there should be a composition (drafting) of a Product Requirements Document (PRD).
The product requirements document is comprised of: full product’s overview, the product
features, working environment etc. It is not solely dedicated to the product’s functions and
features, but it should list all functional and non-functional requirements (such as usability,
safety, reliability, etc.). While writing this document - we must consider the following aspects
of the product:

Define the main product principles (e.g. it should be reliable and ease of use).

Define the product’s purposes, i.e. the business values that it will bring for your customers
(ease of use, cheap price, new features).

Define your clients / customers, your competition, and your product development

team. Define the goals of the product, and tasks that can be fulfilled by using the

product.

Define the different user profiles, e.g. young adults, elderly people, wide audience etc.

The PRD document should be written in clear and concise style, so the product developer will
have a clear understanding about the function of the device, and can jump straight into the
design.

Product Requirement Types

There are particular types of requirements that each product should fulfill and here we list the
most relevant ones.

Functionality

Each product is developed with its main purposes (goals). For example - the cars are
designed to take us to the destination by driving, with certain technical characteristics, exterior
and interior features etc. The product’s functional requirements should include all technical
details in order to provide its uninterrupted functionality.

Quality

Quality is any element (feature), measureable or not, that gives things values beyond their
functionality and features. Typical quality requirements include: reliability of the product,
consistency, durability, availability, customer experience, look and feel, performance,
maintainability, materials / ingredients etc.
Usability

Usability requirements are created to ensure that the product will be easy to use.
Usability is a broad concept, but it can be split into more elementary ones - like intuitive and
easy to learn, so the users are able to flow through the tasks without being interrupted. Also -
they should increase the productivity and performance of the user while using the product.

Reliability

Reliability is one of the most important non-functional (quality) requirements.

Reliability is measured as time to failure, probability of failure and failure-free operation. It
also defines the mean time to repair and between repairs, coefficient of availability and
unavailability, failure rate etc.

Safety

Safety is often introduced as requirement in order to avoid, or reduce potential risks. In

physical products (items) - safety relates to well-being, health and life protection of the users,
while in the IT systems - it refers to protection of user’s personal data (e.g. credit card number
etc.).

Packaging

Packaging requirement refers to the product packaging and its purpose is to protect the
product for transport damages, and also for marketing (design) purposes. Packaging
requirements are subject to regulations in all countries worldwide. For example, European
Union has introduced Packaging Regulations Directive in 1998, and it must be obeyed in all
EU countries. It starts with massive containers, dangerous materials, chemicals and also
includes food products and small bags.

Understanding the Customer Problem to solve

As someone responsible for handling customers, you should know when to listen and when to
speak. This will enable you to understand the problem, the first step in solving any problem.

Meeting Basic Needs

These are the basic steps in understanding a customer’s problems −

Listen patiently to what the customer has to

say Write down all that is being said

Don’t interrupt if you have a query; note it down

Once the customer has finished narrating his problem, summarize your understanding from
your notes

Add to the notes you have taken if the customer has anything more or different to say

After understanding the problem, you should immediately decide whether you will be able to
solve the problem or need to escalate. Whatever your conclusion, assure the customer politely
and convincingly that his problem will be solved.

Thinking Out of the Box

Having a problem-solving attitude is essential for a customer service associate. As most

customers are inarticulate, out-of-the-box thinking is crucial to solve the problems. Also, even
after the problem has been defined, it is not necessary that it has a straightforward solution.
You may have to approach the problem from a unique way that has not been tried earlier.

Here are some scenarios where you may need to be innovative to offer a solution −

​ Not covered specifically in company or department guideline

​ Information needs to be gathered from another department
​ Customer is pushy and wants you to solve immediately
​ Customer has already made complaints that were not resolved

Going the Extra Mile

Every customer service department has a set of laid down norms, usually written. These norms
or rules are there to −
​ Define a team member’s responsibilities
​ Establish protocols for inter-departmental communication
​ Outline what a team member is not required to do
These guidelines are for safeguarding your professional interests. However, no one will stop
you from going an extra mile to help a customer. In fact, as the face of your organization, you
should do everything in your power to solve a customer’s problems. Even if it means doing
something you are not strictly required to do.
A satisfied customer is the best publicity any organization can have. Plus, a satisfied
customer will become loyal too, buying your products every time a need arises rather than
look for other options.

Section Overview

The initial investigation is the first step in the analysis phase of your project. It is a fact-
finding mission in which you aim to find out as much as you can about your user, the current
problem and what the user needs from a computer system in order to solve the problem. You
will use a variety of methods of fact-finding in order to give you as full a picture as possible.
What you find out from your investigation will form the basis of the rest of the analysis phase
and the design phase and it is therefore essential that it is thorough and well-planned. It is
extremely difficult to create an appropriate and useful computer system and to write a quality
project report without first carrying out a genuine, well-planned and comprehensive initial
investigation with a real user or users.

Make sure that you read ahead to the analysis and design phase guidelines so that you have a
clear idea of what you are aiming to find out.

As a starting point, you need your investigation to enable you to outline the following:

● Background to the problem/identify the problem

● Identify the user(s) having the problem
● Identify what the user(s) would need in order to be able to solve the problem
● Outline the limitations of the solution you propose
● Identify two or more possible ways of providing a solution
● Choose the best way of providing a solution and explain why it is the best way
● Identify the sources and destinations of the data used by the system and the processes
used on the data.
● Identify all the data used by the system data requirements and draw an ER model
if appropriate.
● Give a clear, comprehensive, specific list of objectives of the project (what the project will
need to do in order to be successful)
Possible Fact-Finding Methods
Observation

● Describe what or who you will observe and how many times.
● Describe what you expect to gain from this.
● Carry out the observation and document what you observed. Include the full transcript of
your observation(s) in an appendix and refer to where to find it in the write up of this
section. The summary, analysis and conclusions of your findings will be presented in the
Analysis section.

Collection of existing documentation

● Describe what documentation you expect to collect and how much of it. It is generally a
good idea to collect samples of your user’s current forms, reports and other documentation
as evidence of the existing data structures and form of storage and of the data flows in the
current system.
● Describe what you expect to gain from this.
● In this section include copies of the documentation that you collected.

Special checks (e.g. asking people to record how long it takes to carry out a particular task)

● Describe who will do the tasks and what you will ask them to do.
● Carry out the special checks and document what you found out.
Questionnaires

● Describe who you will give a questionnaire to, what questions you will you ask and
how many you will give out.
● Describe what you expect to gain from this. Why are you doing this instead of an
interview?
● Devise a sensible (but not complicated questionnaire) and include a blank copy of it in
this section.
● Include 2 or 3 examples of the completed questionnaires in an appendix and refer to where
to find them in the write up of this section. The summary, analysis and conclusions of the
information given by the questionnaires will be presented in the Analysis section.

Interviews
● Describe who you will interview.
● Describe what you expect to gain from this. Why are you doing this instead of using a
questionnaire?
● Produce a list of questions that you will ask in the interview. (You may need more than
one set of questions if you are interviewing different people for different reasons.)
● Do the interview(s) and document what you found out. Include the full transcript of your
interview(s) in an appendix and refer to where to find it in the write up of this section.
The summary, analysis and conclusions of your findings from the interview(s) will be
presented in the Analysis section.

Information Gathering Tools:

On Site Observation
 ​ What kind of system is it? What does it do?
​ Who runs the system? Who are the important people in it?
​ What is the history of the system? How did it get to its present stage of development?
​ What kind of system is it in comparison with other systems in the organization?
​ Is it a fast paced or slow system to external crises?

Observation Methods
Natural- A natural observation occurs in a setting such as the employee’s place of work.
Contrived- A contrived observation is set up by the observer in a place like a laboratory.

Obtrusive- An obtrusive observation takes place when the respondent knows he/she is being
observed

Unobtrusive- An unobtrusive observation takes place in a contrived way such as behind a one
way mirror
Direct- A direct observation takes place when the analyst actually observes the subject or the
system at work

Indirect- In an indirect observation the analyst uses mechanical devices such as cameras and
videotapes to capture information

Structured- In an structured observation the observer looks for and records a specific action

Unstructured- These methods place the observer in a situation to observe whatever be

pertinent at that time

Problems in On Site Observation

Intruding into the user’s area often results in adverse reactions by the staff, therefore adequate
preparation and training are important
•Attitudes and motivations cannot be readily observed

•Observations are subject to error due to the observer’s misinterpretation

Unproductive, long hours are often spent in an attempt to observe specific one time activities
or events

Interviews
It is a face to face interpersonal role situation, in which a person called the interviewer,
asks questions to another person, designed to gather information about a problem.

Advantages of Interview
It is a superior technique used for exploring areas

•It offers better opportunity to evaluate the validity of the information gathered.

•The interviewer can observe not only what they say and how they say.

​ •It is an effective technique for eliciting information about complex subjects

​ Many people enjoy being interviewed, regardless of the subject

Drawbacks of Interview
The major drawback of an interview is the long preparation time

The art of Interviewing

It is an art.

•The primary requirements for a successful interview are to create friendly atmosphere and to
put the respondent at ease.

•The interview proceeds with asking questions properly, obtaining reliable responses, and
recording them accurately and completely

Arranging the Interview

It should be arranged so that the physical location, time of interview, and order of
interviewing assure privacy and minimal interruption.

•Appointments should be made well in advance and interviewer should adhere to time period.

Guides to a Successful Interview

Following steps should be taken:
•Set the stage for the Interview.

•Establish rapport; put the Interviewee at ease.

 •Phrase questions clearly and succinctly.

•Be a good listener; avoid arguments.

•Evaluate the outcome of the interview.

Set the stage for the interview

-This is an ice breaking session, relaxed, informal phase where the analyst opens the
interview.

-The analyst adjusts his/her own image to counter that

of the interviewee Establishing Rapport

A. Do not deliberately mislead the user staff about the purpose of the interview.
B. Assure interviewees confidentiality that no information will be released to unauthorized
personnel
Avoid showing off your knowledge or sharing information from other sources.
D. Avoid acting like an expert consultant
E. Respect the time schedules
F. Do not promise anything you cannot deliver, such as advice
G. Dress and behave appropriately for the setting
H. Do not interrupt the interviewee
I. Avoid personal involvement in the affairs of the user’s department
Asking the questions
Obtaining and recording the response- The analyst should make an effort to
obtain information from the user
Data recording and the notebook- Many systems fail because of poor data
recording. So special care must be taken to record the data
Questionnaires
These are the questions to which individuals respond

Advantages of Questionnaires
•It is economical and requires less skills to administer than the interview.

•A questionnaire can be administered to large number of individuals simultaneously

•Questionnaires ensure uniformity of questions

•In a questionnaire respondents give opinion without fear

Respondents have time to think the questions over and do
calculations to provide more accurate data.

Types of Interviews and Questionnaires

1. The Unstructured Alternative

 2. The Structured Alternative

1. The Unstructured Alternative

It is a relatively nondirective information gathering technique.

•It allows respondents to answer questions freely in their own words.

•The responses are spontaneous rather than forced.

•System analyst should encourage the respondent to talk freely

2. The Structured Alternative

The questions are presented with exactly the same wording and in the same order

•Questions may be either closed or open ended.

•An open ended question requires no response direction or specific response

Closed questions are those in which the responses are presented as a set of
alternatives. There are five major varieties:

-Fill in the blanks:

-Dichotomous (yes/no type) questions:

-Ranking scales questions

-Multiple choice questions

-Rating scales questions

 PROJECT REVIEW
A Project Review is an assessment of the status of a project, at a particular point in
time. The first time in the project life cycle that a project review is undertaken is at
the end of the first project phase, called "Initiation".
The form helps you to document the results of your Project
Review, by stating whether the:
• Project is currently delivering to schedule
• Budget allocated was sufficient at this point
• Deliverables have been produced and approved
• Risks have been controlled and mitigated
• Issues were identified and resolved
• Changes were properly managed
• Project is on track
 THE PROJECT TRACKING MEETING

What is the primary purpose for project tracking meetings?

How often should a project formally be tracked?
Does it matter what day of the week the project tracking meeting is conducted?
What if project members find themselves assigned to more than one project?
Who should attend project tracking meetings?
 THE PROJECT TRACKING MEETING

The subjects are presented at tracking meetings:

Project High-Priority Areas
Overview of Project Progress
`Progress of Project Activities
Progress of Action Items
Project Outlook
Schedule Work/Escalation Meetings
The project manager must lead these meetings so that they run on
schedule and are productive.
Project Recovery
 Product Requirements Lifecycle

The product requirements lifecycle includes the following phases:

1) Requirements gathering,

2) Requirements analysis,

3) Requirements verification / validation,

4) Requirements management and tracking,

5) Requirements specification (documentation).

 1) Requirements gathering
Sources
- Objectives(Business concern)
- Domain knowledge
- Stakeholders
- Operating environment
- The organizational environment
 2) Requirements analysis
Identify and resolve the conflicts between the product requirements.
Detection of product features, and how the product will behave in
real environments.

3) Requirements Validation
Are the requirements clearly stated?
Are all the aspects of the product operation (functioning) covered?
Does the requirement affect domain restrictions?
Can the requirement be tested? If it can, can we determine tests
(so-called validation criteria) for checking the requirement?
 4) Product Requirements Management and Tracking

Requirement management is a set of activities that helps the project team

identify, control, and track requirements and their changes at any point in
the product's life. Also in this step - requirements prioritization and
re-ordering can be done.
 5) Product Requirements Documentation

Define the main product principles (e.g. it should be reliable and ease of use).

Define the product’s purposes, i.e. the business values that it will
bring for your customers (ease of use, cheap price, new features).
Define your clients / customers, your competition, and your
product development team. Define the goals of the product, and
tasks that can be fulfilled by using the product.
 Understanding the Customer Problem to solve
Listen patiently to what the customer has to say
Write down all that is being said
Don’t interrupt if you have a query; note it down

Once the customer has finished narrating his problem, summarize your
understanding from your notes

Add to the notes you have taken if the customer has anything more or different
to say
After understanding the problem, you should immediately decide
whether you will be able to solve the problem or need to escalate.
Whatever your conclusion, assure the customer politely and
convincingly that his problem will be solved.

Thinking Out of the Box

∙ Background to the problem/identify the problem
∙ Identify the user(s) having the problem
∙ Identify what the user(s) would need in order to be able to solve the problem
∙ Outline the limitations of the solution you propose
∙ Identify two or more possible ways of providing a solution
∙ Choose the best way of providing a solution and explain why it is the best way
∙ Identify the sources and destinations of the data used by the system and the
processes used on the data.
∙ Identify all the data used by the system data requirements and draw an ER
model if appropriate.
∙ Give a clear, comprehensive, specific list of objectives of the project (what the
project will need to do in order to be successful)
 Strategies for determining information
requirements
The systems development process transforms the existing (as is) system
into the proposed (to be) system

Requirements determination
The single most critical step of the entire SDLC

Changes can be made easily in this stage

Most (>50%) system failures are due to problems with requirements

Small batches of requirements can be identified and implemented incrementally
Information gathering tools
Sample SRS and Use case digrams for you reference

SRS Template
 SRS for Library Management System
1. Introduction
1.1 Purpose
The purpose of this document is to define the functional and non-functional requirements for a
Library Management System (LMS). The system will automate various library operations, including
book cataloging, member management, issue/return tracking, and report generation.
1.2 Scope
The Library Management System will be designed to manage the daily operations of a library. It will
allow librarians to manage books, members, and transactions efficiently, and provide members with a
user-friendly interface to search for and borrow books.
1.3 Definitions, Acronyms, and Abbreviations
● LMS: Library Management System
● Admin: The system administrator responsible for managing the overall system.
● Librarian: The user who manages book inventory, issues, returns, and library members.
● Member: A registered user of the library who can borrow and return books.
● ISBN: International Standard Book Number, a unique identifier for books.
1.4 References
● IEEE SRS Standard Template
● User Stories and Use Cases Document
1.5 Overview
This document outlines the system's architecture, features, user interfaces, and other technical
requirements for the Library Management System.
2. Overall Description
2.1 Product Perspective
The LMS is a web-based application that serves as a digital interface for managing library operations.
It will be accessed by librarians and library members via a web browser.
2.2 Product Features
● User Management: Manage library members, including registration, profile updates, and
membership status.
● Book Cataloging: Maintain a catalog of all books, including details like title, author, ISBN,
and availability.
● Book Issuance and Return: Track the issuance and return of books, including due dates and
fines.
● Search Functionality: Allow members to search for books by title, author, or genre.
● Reservation System: Enable members to reserve books that are currently on loan.
 ● Report Generation: Generate reports on book inventory, member activity, and transaction
history.
● Notifications: Send email or SMS notifications to members for due dates, overdue books, and
reservations.
2.3 User Classes and Characteristics
● Admin: Manages system configurations, user roles, and overall system maintenance.
● Librarian: Handles daily operations like managing books, issuing and returning books, and
member services.
● Member: Can search for, borrow, return, and reserve books. Members can also view their
borrowing history and dues.
2.4 Operating Environment
● Front-end: Web browsers (Chrome, Firefox, Safari) accessible via desktops, laptops, and
tablets.
● Back-end: Server hosting the application and database, accessible via RESTful APIs.
● Database: Relational database management system (e.g., MySQL, PostgreSQL).
● Communication: Email and SMS gateways for notifications.
2.5 Design and Implementation Constraints
● The system must be compatible with the latest versions of major web browsers.
● The system should be scalable to support a large number of books and members.
● Secure authentication and authorization mechanisms must be in place.
2.6 User Documentation
● User manual for librarians and admins.
● Online help and FAQs for members.
● Technical documentation for developers.
2.7 Assumptions and Dependencies
● The library has an existing database of books that can be imported into the system.
● Users have access to the internet and a web browser.
● Third-party services (e.g., email and SMS gateways) are available and reliable.
3. System Features
3.1 User Management
● Description: Manage the registration, profiles, and statuses of library members.
● Functional Requirements:
o The system shall allow librarians to add, update, and delete member records.
o The system shall allow members to register via an online form.
 o The system shall notify members of their registration status via email or SMS.
3.2 Book Cataloging
● Description: Manage the library's book inventory.
● Functional Requirements:
o The system shall allow librarians to add new books to the catalog by entering details
like title, author, ISBN, and genre.
o The system shall allow librarians to update and delete book records.
o The system shall maintain the availability status of each book.
3.3 Book Issuance and Return
● Description: Manage the process of issuing and returning books.
● Functional Requirements:
o The system shall allow librarians to issue books to members by updating the book's
status and recording the due date.
o The system shall allow members to return books and update the book's availability.
o The system shall calculate and record fines for overdue books.
3.4 Search Functionality
● Description: Allow members and librarians to search the book catalog.
● Functional Requirements:
o The system shall provide a search interface where users can search for books by title,
author, ISBN, or genre.
o The system shall display search results with details like availability and location
within the library.
3.5 Reservation System
● Description: Enable members to reserve books that are currently on loan.
● Functional Requirements:
o The system shall allow members to reserve a book that is currently issued to another
member.
o The system shall notify members when a reserved book becomes available.
o The system shall maintain a queue of reservations if multiple members reserve the
same book.

3.6 Report Generation

● Description: Generate various reports for library management.
● Functional Requirements:
 o The system shall allow librarians to generate reports on book inventory, including
available, issued, and reserved books.
o The system shall generate reports on member activity, such as books borrowed,
returned, and fines accrued.
o The system shall generate overdue book reports to assist in follow-ups with members.
3.7 Notifications
● Description: Notify members about important events related to their library account.
● Functional Requirements:
o The system shall send notifications for due dates, overdue books, and reservations via
email or SMS.
o The system shall send reminders to members before their membership expires.
o The system shall allow members to opt-in or opt-out of specific types of notifications.
4. External Interface Requirements
4.1 User Interfaces
● Login Screen
● Dashboard for Librarians
● Book Catalog Screen
● Member Profile Screen
● Search Interface
● Report Generation Interface
● Notifications Screen
4.2 Hardware Interfaces
● Servers: To host the application and database.
● Desktop and Mobile Devices: For accessing the LMS through a web browser.
4.3 Software Interfaces
● Database Management System: MySQL or PostgreSQL.
● Email and SMS Gateways: For sending notifications to users.
● RESTful APIs: For communication between the front-end and back-end.

4.4 Communication Interfaces

● Web: HTTP/HTTPS protocols for secure data transmission.
● Email/SMS: Used for sending notifications and alerts.
5. Non-Functional Requirements
5.1 Performance Requirements
● The system shall handle up to 5,000 concurrent users.
● The system shall process search queries and book transactions within 2 seconds.
5.2 Security Requirements
● The system shall enforce user authentication for all access to the system.
● The system shall encrypt sensitive data, including user passwords and financial information.
● The system shall have role-based access control to restrict certain features to specific user
roles.
5.3 Usability Requirements
● The system shall provide a user-friendly interface that is easy to navigate for all user types.
● The system shall be accessible to users with disabilities, adhering to WCAG 2.1 standards.
5.4 Reliability and Availability
● The system shall be available 99.9% of the time, excluding scheduled maintenance.
● The system shall have a backup mechanism to recover data in case of system failure.
5.5 Scalability
● The system shall be scalable to accommodate an increasing number of books, members, and
transactions.
5.6 Maintainability
● The system shall be designed with modular components to facilitate easy maintenance and
updates.
● The codebase shall be well-documented for future development and troubleshooting.
6. Other Requirements
6.1 Legal and Regulatory Requirements
● The system shall comply with data protection regulations such as GDPR.
● The system shall ensure that member data is stored and processed securely, with regular
audits.
6.2 Environmental Requirements
● The system shall promote the use of digital resources to reduce the reliance on paper-based
records.
This SRS provides a comprehensive guide for developing the Library Management System, detailing
the required features, system behavior, and technical considerations to ensure successful
implementation.
 SRS for Online Tiffin Delivery System
1. Introduction
1.1 Purpose
The purpose of this document is to define the requirements for an online tiffin delivery system. The
system will allow users to subscribe to daily meals, place orders, manage subscriptions, and track
deliveries.
1.2 Scope
The system will cater to customers who prefer homemade meals delivered to their doorstep. It will
include user registration, meal selection, subscription management, payment processing, and delivery
tracking.
1.3 Definitions, Acronyms, and Abbreviations
● SRS: Software Requirements Specification
● Admin: System administrator managing the backend
● User/Customer: Person ordering tiffin services
● Vendor: Tiffin provider preparing and delivering meals
● System: The Online Tiffin Delivery Platform
1.4 References
● IEEE SRS Standard Template
● User Stories and Use Cases Document
1.5 Overview
This document includes a detailed description of system functionality, interfaces, and performance
criteria.
2. Overall Description
2.1 Product Perspective
The system is a web-based platform accessible via desktop and mobile browsers. It will integrate with
payment gateways and use a GPS service for delivery tracking.
2.2 Product Features
● User Registration & Login: Users can create accounts using email, phone numbers, or social
media credentials.
● Meal Selection: Users can choose from a variety of meal plans (e.g., vegetarian,
non-vegetarian, diet-specific).
● Subscription Management: Users can subscribe to daily, weekly, or monthly tiffin services.
● Order Placement: Users can place one-time orders or modify their current subscriptions.
 ● Payment Gateway Integration: Supports multiple payment methods including credit/debit
cards, UPI, and digital wallets.
● Delivery Tracking: Users can track their orders in real-time.
● Feedback & Ratings: Users can rate meals and provide feedback.
2.3 User Classes and Characteristics
● Customers: Individuals using the platform to order tiffins.
● Vendors: Tiffin providers managing meal preparation and delivery.
● Admin: Manages the system, vendors, and customer issues.
2.4 Operating Environment
● Front-end: Web browsers (Chrome, Firefox, Safari) and mobile browsers.
● Back-end: Server hosting, database management system, GPS API for tracking.
● Payment Gateway: Integration with secure payment systems.
2.5 Design and Implementation Constraints
● Responsive design to support all devices.
● High availability to ensure users can access services at any time.
● Secure data management and encryption.
2.6 User Documentation
● User manual
● FAQs
● Helpdesk support
2.7 Assumptions and Dependencies
● Users must have internet access.
● Payment gateway availability.
● Reliable delivery personnel.
3. System Features
3.1 User Registration and Authentication
● Description: Users can register and log in using email or social media credentials.
● Functional Requirements:
o The system shall allow users to register by providing necessary details.
o The system shall send a verification email or SMS.
o The system shall enable password recovery.
3.2 Meal Plan Selection
● Description: Users can view and select available meal plans.
 ● Functional Requirements:
o The system shall display meal options based on user preferences.
o The system shall allow users to customize meal preferences.
3.3 Subscription Management
● Description: Users can manage their tiffin subscriptions.
● Functional Requirements:
o The system shall allow users to subscribe to daily, weekly, or monthly plans.
o The system shall allow users to pause or cancel subscriptions.
3.4 Order Placement
● Description: Users can place orders for tiffin delivery.
● Functional Requirements:
o The system shall allow one-time order placement.
o The system shall provide an estimated delivery time.
3.5 Payment Processing
● Description: Users can pay for their orders through the platform.
● Functional Requirements:
o The system shall integrate with a secure payment gateway.
o The system shall confirm payment and update the user’s account.
3.6 Delivery Tracking
● Description: Users can track their tiffin delivery in real-time.
● Functional Requirements:
o The system shall integrate with a GPS service for real-time tracking.
o The system shall notify users when their tiffin is out for delivery.
3.7 Feedback and Ratings
● Description: Users can provide feedback and rate their meals.
● Functional Requirements:
o The system shall allow users to submit feedback after meal delivery.
o The system shall display ratings on the vendor's profile.
4. External Interface Requirements
4.1 User Interfaces
● Login Screen
● Dashboard for Meal Selection
 ● Subscription Management Screen
● Order Placement Screen
● Payment Screen
● Delivery Tracking Screen
● Feedback Screen
4.2 Hardware Interfaces
● Servers to host the application and database.
● Mobile devices for tracking delivery using GPS.
4.3 Software Interfaces
● Database Management System: MySQL or PostgreSQL.
● Payment Gateway APIs: PayPal, Stripe, Razorpay.
● GPS API: Google Maps API.
4.4 Communication Interfaces
● RESTful APIs for communication between the front-end and back-end.
● Email and SMS services for user notifications.
5. Non-Functional Requirements
5.1 Performance Requirements
● The system shall handle up to 10,000 concurrent users.
● The system shall respond within 2 seconds for user actions.
5.2 Security Requirements
● The system shall enforce SSL/TLS encryption for all transactions.
● The system shall comply with GDPR for data protection.
5.3 Usability Requirements
● The system shall be accessible on both desktop and mobile devices.
● The system shall support multiple languages.
5.4 Reliability and Availability
● The system shall be available 99.9% of the time.
● The system shall have backup and recovery procedures.
5.5 Scalability
● The system shall be scalable to accommodate an increasing number of users and vendors.
5.6 Maintainability
● The system shall allow easy updates and maintenance.
 ● The codebase shall be well-documented for future development.
6. Other Requirements
6.1 Legal and Regulatory Requirements
● The system shall comply with local and international food delivery regulations.
● The system shall ensure vendors comply with health and safety standards.
6.2 Environmental Requirements
● The system shall promote eco-friendly packaging options.
This SRS serves as a comprehensive guide for developing the online tiffin delivery system. Each
section can be further expanded based on specific business needs or technical requirements.

Use Case Diagrams:

1. Medical Health care:

2. Online Tiffin Delivery System:

To create a use case diagram for an Online Tiffin Delivery System, we need to identify the key actors
and use cases.
Actors:
1. Customer - A person ordering tiffin online.
2. Admin - Manages the system, including menu updates and order tracking.
3. Delivery Person - Responsible for delivering the tiffin to the customer.
Use Cases:
1. Register/Login - Customers create an account or log in.
2. Browse Menu - Customers view available tiffin options.
3. Place Order - Customers place an order for tiffin.
4. Make Payment - Customers make payments for the order.
5. Track Order - Customers track the status of their order.
6. Update Menu - Admin updates the available tiffin options.
7. Manage Orders - Admin manages and tracks all customer orders.
8. Assign Delivery - Admin assigns orders to delivery persons.
9. Deliver Tiffin - Delivery person delivers the tiffin to the customer.
10. Confirm Delivery - Delivery person confirms that the tiffin has been delivered.
Diagram Overview:
1. Customer interacts with:
o Register/Login
o Browse Menu
o Place Order
o Make Payment
o Track Order
2. Admin interacts with:
o Update Menu
o Manage Orders
o Assign Delivery
3. Delivery Person interacts with:
o Deliver Tiffin
o Confirm Delivery
3. University Admission System:
To represent the University Admission System with a use case diagram, here are the key elements:
Actors:
1. Applicant - A person applying for admission.
2. Admin - University staff responsible for managing applications.
3. System Administrator - Maintains the system, including user accounts and system
configurations.
Use Cases:
1. Create Account - The applicant creates an account on the system.
2. Submit Application - The applicant fills out and submits the application form.
3. Upload Documents - The applicant uploads necessary documents (e.g., transcripts, test
scores).
4. Track Application Status - The applicant views the status of their submitted application.
5. Evaluate Application - Admin evaluates the application based on predefined criteria.
6. Make Admission Decision - Admin makes the final decision (accepted, rejected, waitlisted).
7. Send Notification - The system sends notifications to the applicant about their application
status.
8. Generate Reports - Admin generates reports on various admission statistics.
9. Manage User Accounts - System Administrator manages user accounts and permissions.
10. Backup and Recovery - System Administrator manages system backups and recovery
processes.
Diagram Overview:
1. Applicant interacts with:
o Create Account
o Submit Application
o Upload Documents
o Track Application Status
2. Admin interacts with:
o Evaluate Application
o Make Admission Decision
o Send Notification
o Generate Reports
3. System Administrator interacts with:
o Manage User Accounts
 o Backup and Recovery

You can create DFS, SRS and Use case diagrams for below topics for practice:
3. University Admission System
4. Cab booking system
5. Library Management System
6. Online Tiffin Delivery System
7. Medical Health care