Unit-2-System Analysis-Part - One
Unit-2-System Analysis-Part - One
-Generic products: [This type of software product are developed by a organization and sold on open
market to any customer], (System software, application software )
-Customized (or bespoke) products: This type of software products are developed by a software
contractor and especially for a customer.
-Embedded Product: Combination of both hardware and software
QUALITIES / SKILLS POSSESSED BY A GOOD SOFTWARE ENGINEER:
1. General Skill (Analytical skill, Problem solving skill, Group work skill)
2. Programming Skill (Programming language , Data structure , Algorithm , Tools( Compiler, Debugger))
3. Communication skill (Verbal , Written, Presentation)
4. Design Skill (s/w engineer must be familiar with several application domain)
FACTOR IN EMERGENCE OF SOFTWARE ENGINEERING:
1. People who are developing software were consistently wrong in their estimation of time, effort and cost.
2. Reliability and maintainability was difficult of achieved
3. Fixing bug in a delivered software was difficult
4. Delivered software frequently didn’t work
5. Changes in ration of h/w to s/w cost
6. Increased cost of software maintenance
7. Increased demand of software
8. Increased demand for large and more complex software system 9. Increasing size of software
PROJECT MANAGEMENT
Management Activities
Writing the proposals for projects
Project Planning and scheduling
Estimating the project cost
Reviewing the project
Project Evaluation
Report writing and presentation
PROJECT MANAGEMENT
The term system is derived from Greek word ‘systema’ which means “An organized relationship among all
functioning units/components”
System exist because its designed to achieve one or more objectives
System is an orderly grouping of interdependent components i.e. collection of components/parts/units in
organized manner.
Components are linked together according to a plan to achieve a specific objective/Aim/Goal.
Example: Computer System, Hotel system, Library System, University system etc.
PROPERTIES / CHARACTERISTICS OF A SYSTEM
Control
The control element guides the system.
It is the decision–making subsystem that controls the pattern of activities governing input, processing, and output.
The behavior of a computer System is controlled by the Operating System and software. In order to keep system in
balance, what and how much input is needed is determined by Output Specifications.
Feedback
Feedback provides the control in a dynamic system.
Positive feedback is routine in nature that encourages the performance of the system.
Negative feedback is informational in nature that provides the controller with information for action.
ELEMENTS OF A SYSTEM
Environment
The environment is the “supersystem” within which an organization operates.
It is the source of external elements that strike on the system.
It determines how a system must function. For example, vendors and competitors of organization’s environment, may
provide constraints that affect the actual performance of the business.
Boundaries and Interface
A system should be defined by its boundaries. Boundaries are the limits that identify its components, processes, and
interrelationship when it interfaces with another system.
Each system has boundaries that determine its sphere of influence and control.
The knowledge of the boundaries of a given system is crucial in determining the nature of its interface with other systems
for successful design.
TYPES OF SYSTEM
Physical systems are tangible entities. We can touch and feel them.
Physical System may be static or dynamic in nature. For example, desks and chairs are the physical parts of
computer center which are static. A programmed computer is a dynamic system in which programs, data, and
applications can change according to the user's needs.
Abstract systems are non-physical entities or conceptual that may be formulas, representation or model of a real
system.
OPEN OR CLOSED SYSTEMS
An open system must interact with its environment. It receives inputs from and delivers outputs to the outside of
the system. For example, an information system which must adapt to the changing environmental conditions.
A closed system does not interact with its environment. It is isolated from environmental influences. A completely
closed system is rare in reality.
Open systems refer to systems that interact with other systems or the outside environment, whereas closed
systems refer to systems having relatively little interaction with other systems or the outside environment.
ADAPTIVE AND NON ADAPTIVE SYSTEM
Adaptive System responds to the change in the environment in a way to improve their performance and to
survive. For example, human beings, animals.
Non Adaptive System is the system which does not respond to the environment. For example, machines.
PERMANENT OR TEMPORARY SYSTEM
Permanent System persists for long time. For example, business policies.
Temporary System is made for specified time and after that they are demolished. For example, A DJ system is set
up for a program and it is dissembled after the program.
NATURAL AND MANUFACTURED SYSTEM
Natural systems are created by the nature. For example, Solar system, seasonal system.
Manufactured System is the man-made system. For example, Rockets, dams, trains.
DETERMINISTIC OR PROBABILISTIC SYSTEM
Deterministic system operates in a predictable manner and the interaction between system components is
known with certainty. For example, two molecules of hydrogen and one molecule of oxygen makes water.
Probabilistic System shows uncertain behavior. The exact output is not known. For example, Weather forecasting.
SOCIAL, HUMAN-MACHINE, MACHINE SYSTEM
System Analysis and Design is study in which we learn how to analyze an existing system and create a better one.
Identifying positives and Negatives
Understanding the features
How to reduce the cons and improve performance.
NEED OF SYSTEM ANALYSIS AND DESIGN
Managing information involves gathering and distributing necessary information and assimilating them on the project
management activities and processes. The information gathering techniques are repeated processes that are used to
create and organize data across different kinds of sources. There are four types of information gathering techniques
as follows:
Brainstorming: This method is used to get a list of all project lists. All ideas are generated with the help of a
facilitator through an open discussion and mass interviewing techniques. Commonly, the brainstorming technique
can be done during a scheduled meeting with peers, individual brainstorming, or even at an informal meeting.
Delphi technique: This technique in project management requires the presence of a facilitator that gives out
questionnaires to solicit different ideas.The responses are summarized and recirculated to the participants.
Root cause analysis: It is used in identifying problems and its underlying causes thus developing a preventive
action.
Interviewing: Stakeholders, participants, and experts are interviewed to identify risks.
S/W REQUIREMENT AND SPECIFICATION:
The aim of the requirements analysis and specification phase is to understand the exact requirements of the
customer and to document them properly. This phase consists of two distinct activities:
Requirements gathering and analysis, and
Requirements specification
REQUIREMENTS GATHERING AND ANALYSIS:-
The goal of the requirements gathering activity is to collect all relevant information from the customer regarding
the product to be developed and analyzed.
This phase is done to clearly understand the customer requirements so that incompleteness and inconsistencies
are removed.
This activity begins by collecting all relevant data regarding the product to be developed from the user and from
the customer through interviews and discussions.
REQUIREMENTS SPECIFICATION
After all ambiguities, inconsistencies, and incompleteness have been resolved and all the requirements properly
understood, the requirements specification activity can start.
During this activity, the user requirements are systematically organized into a Software Requirements
Specification (SRS) document.
The customer requirements identified during the requirements gathering and analysis activity are organized into a
SRS document.
The important components of this document are:
functional requirements of the system
nonfunctional requirements of the system
goal of implementation.
TYPES OF REQUIREMENT GATHERING TECHNIQUES
There are many tried and tested methods to eliciting requirements or gathering from customers each of which is
designed to target a specific avenue of thinking.
interviewing customers,
conducting focus groups,
circulating questionnaires, and
demonstrating prototypes.
BRAINSTORMING
Brainstorming is used in requirement gathering to get as many ideas as possible from group of people. Generally
used to identify possible solutions to problems, and clarify details of opportunities.
DOCUMENT ANALYSIS
Reviewing the documentation of an existing system can help when creating AS–IS process document, as well as
driving gap analysis for scoping of migration projects. In an ideal world, we would even be reviewing the
requirements that drove creation of the existing system – a starting point for documenting current requirements.
Nuggets of information are often buried in existing documents that help us ask questions as part of validating
requirement completeness.
FOCUS GROUP
A focus group is a gathering of people who are representative of the users or customers of a product to get
feedback.
The feedback can be gathered about needs/opportunities/ problems to identify requirements, or can be gathered
to validate and refine already elicited requirements.
This form of market research is distinct from brainstorming in that it is a managed process with specific
participants.
INTERFACE ANALYSIS
Interfaces for a software product can be human or machine. Integration with external systems and devices is just
another interface.
User centric design approaches are very effective at making sure that we create usable software. Interface analysis
– reviewing the touch points with other external systems is important to make sure we don’t overlook
requirements that aren’t immediately visible to users.
INTERVIEW
Interviews of stakeholders and users are critical to creating the great software. Without understanding the goals
and expectations of the users and stakeholders, we are very unlikely to satisfy them.
We also have to recognize the perspective of each interviewee, so that, we can properly weigh and address their
inputs. Listening is the skill that helps a great analyst to get more value from an interview than an average analyst.
OBSERVATION
By observing users, an analyst can identify a process flow, steps, pain points and opportunities for improvement.
Observations can be passive or active (asking questions while observing).
Passive observation is better for getting feedback on a prototype (to refine requirements), where active
observation is more effective at getting an understanding of an existing business process.
Either approach can be used.
PROTOTYPING
Prototyping is a relatively modern technique for gathering requirements. In this approach, you gather preliminary
requirements that you use to build an initial version of the solution - a prototype.
You show this to the client, who then gives you additional requirements. You change the application and cycle
around with the client again.
This repetitive process continues until the product meets the critical mass of business needs or for an agreed
number of iterations.
REQUIREMENT WORKSHOPS
Workshops can be very effective for gathering requirements. More structured than a brainstorming session,
involved parties collaborate to document requirements.
One way to capture the collaboration is with creation of domain-model artifacts (like static diagrams, activity
diagrams). A workshop will be more effective with two analysts than with one.
REVERSE ENGINEERING
When a migration project does not have access to sufficient documentation of the existing system, reverse
engineering will identify what the system does. It will not identify what the system should do, and will not identify
when the system does the wrong thing.
SURVEY/QUESTIONNAIRE
When collecting information from many people – too many to interview with budget and time constraints – a
survey or questionnaire can be used. The survey can force users to select from choices, rate something (“Agree
Strongly, agree…”), or have open ended questions allowing free-form responses. Survey design is hard – questions
can bias the respondents.
FEASIBILITY ANALYSIS
A feasibility study evaluates the viability of a given project or system in software engineering. Therefore, one of
the four steps of the Software Project Management Process is the feasibility study.
As the name implies, a feasibility study is a software product measurement in terms of how useful product
development will be for the business from a practical standpoint.
A feasibility study is conducted for various reasons, including determining if a software product is appropriate in
terms of development, implementation, and project value to the business.
TYPES OF FEASIBILITY STUDY
Operational Feasibility
Technical Feasibility
Schedule Feasibility
Legal Feasibility
Economic Feasibility
OPERATIONAL FEASIBILITY
In this phase, the degree of service to needs is assessed and how easy the product will be to operate and maintain
after deployment. Other operational scopes include assessing product usability, determining whether a software
development team's offered solution is appropriate, etc.
TECHNICAL FEASIBILITY
To construct a project, resources, including hardware and software and necessary technologies, are studied and
assessed. This technical feasibility analysis determines if the resources and technology for project development are
available.
A feasibility study also examines the technical skills and capabilities of the technical team, whether current
technology can be used or not, if maintenance and up-gradation of the chosen technology are simple or not, and
so on.
SCHEDULE FEASIBILITY
In a Schedule Feasibility Study, the proposed project's timelines/deadlines are analysed, including how long teams
will take to complete the final project. This has a significant impact on the organisation because the project's goal
may be lost if not completed on time.
LEGAL FEASIBILITY
The legality of a study project is examined in Legal Feasibility. This involves examining legal impediments to project
execution, such as data protection regulations or social media legislation, project certificate, licensing, and
copyright, among other things.
Overall, a Legal Feasibility Study investigates whether a proposed enterprise meets legal and ethical standards.
ECONOMIC FEASIBILITY
The project's cost and benefit are assessed in an economic feasibility study. This feasibility study contains a
detailed analysis of the project's development costs, covering all essential costs for final development, such as
hardware and software resources, design and development costs, and operations costs.
After that, it is determined if the initiative will be financially advantageous to the organization.
IMPORTANCE OF FEASIBILITY ANALYSIS
A feasibility study's usefulness originates from an organization's need to "get it right" before devoting resources,
time, or money. A feasibility study may uncover new ideas that change the project's scope. It's preferable to make
these selections ahead of time rather than rushing into a project and discovering it won't work.
A feasibility study is beneficial to a project because it gives you and other stakeholders a clear picture of what is
being proposed.
Determines why not to proceed.
Aids project decision-making and increases success rates by assessing several aspects.
Determines whether or not the project is worthwhile.
Reduces the number of business options
Provides useful data for making a "go/no-go" judgement.
Discovers fresh possibilities
Improves the attention of project teams
IMPORTANCE OF FEASIBILITY ANALYSIS
The findings of your feasibility study are summarized in a feasibility report, which usually includes the components below.