1.What is System decomposition?

Decomposition is breaking a complex problem or system into parts that are easier to
conceive, understand, program, and maintain.
➢ In structured programming, algorithmic decomposition breaks a process down
into well-defined steps.
➢ Object-oriented decomposition, on the other hand, breaks a large system down
into progressively smaller classes or objects that are responsible for some part
of the problem domain.
Decomposition techniques works on “Divide and Conquer” approach in software
project estimation. By decomposition a project is divided into different components
and related software engineering activities. Cost and effort estimation can be
performed step by step on each component.
Software cost estimation is a form to solve the problems. Most of the times problem
to be solved is too complex to be solve in a single step. Than the problem is
decomposed in to number of components in order to achieve an accurate cost
estimate.

2.What are system design specifications?

System design specification is defined as a document which helps in describing
complete design for a system with scheduling, staffing and detailed cost. System
requirement documents are for user and the system design specification document
are for programmer for creating necessary programs.
Following are the sections that are included into the system design specification
which are as follows:
• Management summary: Management summary section is for company
executives and managers. It helps in providing current status report, development
efforts to date reviews of benefit and summarize the cost of project and also highlight
the risks and issues which should be addressed by the management.
• System components: The complete design for the new system is contained within
System components section. It also includes inputs, outputs, user interface, network
specification ad database and files.
3.What is the goal of system design?
The goal of system design is to allocate the requirements of a large system to
hardware and software components. The system design activity starts after the
system requirements analysis has been completed.
4,What are the benefits of Reusing Pattern Solutions?
Reuse knowledge from previous experience to current problem. In software
development, a pattern (or design pattern) is a written document that describes a
general solution to a design problem that recurs repeatedly in many projects. A
successful pattern should have established itself as leading to a good solution. In
object-oriented programming, a pattern can contain the description of certain objects
and object classes to be used, along with their attributes and dependencies, and the
general approach to how to solve the problem. Often, programmers can use more
than one pattern to address a specific problem. A collection of patterns is called a
pattern framework.

5.What is API stand for?

An API (Application Programming Interface) is a set of functions that allows
applications to access data and interact with external software components,
operating systems, or microservices. To simplify, an API delivers a user response
to a system and sends the system's response back to a user.
PART -B (Answer all the Questions)

1.a)Give the Overview of System Design.

Systems development is systematic process which includes phases such as planning, analysis,
design, deployment, and maintenance. Here, in this tutorial, we will primarily focus on −

• Systems analysis
• Systems design

What is a System?
A system is “an orderly grouping of interdependent components linked together according to a plan
to achieve a specific goal.”

Properties of a System
A system has the following properties −
Organization
Organization implies structure and order. It is the arrangement of components that helps to achieve
predetermined objectives.

Interaction
It is defined by the manner in which the components operate with each other.
For example, in an organization, purchasing department must interact with production department
and payroll with personnel department.

Interdependence
Interdependence means how the components of a system depend on one another. For proper
functioning, the components are coordinated and linked together according to a specified plan. The
output of one subsystem is the required by other subsystem as input.

Integration
Integration is concerned with how a system components are connected together. It means that the
parts of the system work together within the system even if each part performs a unique function.

Central Objective
The objective of system must be central. It may be real or stated. It is not uncommon for an
organization to state an objective and operate to achieve another.
The users must know the main objective of a computer application early in the analysis for a
successful design and conversion.

Elements of a System
The following diagram shows the elements of a system −

Outputs and Inputs

 • The main aim of a system is to produce an output which is useful for its user.
• Inputs are the information that enters into the system for processing.
• Output is the outcome of processing.

Processor(s)
• The processor is the element of a system that involves the actual transformation of input into
output.
• It is the operational component of a system. Processors may modify the input either totally or
partially, depending on the output specification.
• As the output specifications change, so does the processing. In some cases, input is also
modified to enable the processor for handling the transformation.

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.

Types of Systems
The systems can be divided into the following types −

Physical or Abstract Systems

• 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.

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, mail delivery.

Social, Human-Machine, Machine System

• Social System is made up of people. For example, social clubs, societies.
• In Human-Machine System, both human and machines are involved to perform a particular
task. For example, Computer programming.
• Machine System is where human interference is neglected. All the tasks are performed by the
machine. For example, an autonomous robot.

1.b)Explain about Decomposing the System.

What is Functional Decomposition?

Functional decomposition corresponds to the various functional relationships as how the original
complex business function was developed. It mainly focusses on how the overall functionality is
developed and its interaction between various components.
Large or complex functionalities are more easily understood when broken down into pieces using
functional decomposition.

When and How?

 • Functional decomposition is mostly used during the project analysis phase in order to produce
functional decomposition diagrams as part of the functional requirements document.
• Functional Decomposition is done after meeting with business analysts and subject matter
expertise.
• Decompose the first level components with their functions and continue to decompose to lower
levels until sufficient level of detail is achieved
• Perform an end-to-end walk-through of the business operation and check each function to
confirm that it is correct.

Example:
The below example, best describes the Functional Decomposition:

The process decomposition diagram (often called a decomp) explains the breakdown of processes
within a project or business area or functional area. The purpose is to show all the processes and
identify relationships and dependencies among them. Note that a decomp doesn’t drill into the how; it
merely outlines the what.

The process decomposition diagram actually functions very similarly to an org chart in that the
processes in this diagram relate to one another like the people on an organization chart relate to each
other: Just as all the workers reporting to one manager make up all the work under that manager, all
the processes under a higher process make up all the work of that process.

Processes that have processes underneath are called parent processes. Processes that report into
another process are called child processes. Designating parent and child processes follows a couple
of guidelines:

• If you break down a parent process, you must break it into at least two children; otherwise it’s not a
true parent.

• All the child processes together must completely describe all the activities in the parent process.
 The diagram doesn’t follow any defined sequence. For instance, you don’t have to check the weather
before you plan the flight. Similarly, you can check the weather in any of the locations in any order;
you don’t have to check it from origin to en route to destination because bad weather at any point
along the route prevents you from flying that route.

Credit: Illustration by Wiley, Composition Services Graphics

Here are some times you can apply this technique:

• When you’re working on a large project and need to understand the size of the work effort: Knowing
all the processes you have to document can help.

• When you’re validating with your stakeholders that you have captured all the processes you’ll
document: Stakeholders can very easily see whether you’ve missed a process.

• When you’re eliciting processes in scope from your stakeholders: The stakeholders are able to interact
with a diagram structure they’re very familiar with (in the company’s org chart).

Some pros and cons to this technique include the following:

• Pro: The decomp diagram is useful on larger projects (those with more than five processes to study
and document) because it gives you a snapshot of the big picture. On a large effort, it is easy to forget
which parent each child process belongs to and how each child relates to each other. This opens the
door to repeating processes for one or more parents.

• Pro: It’s a great tool early on in the scoping phase because it gives you an idea of how many processes
you have to define, which is important for time and resource estimates.

• Pro: It’s a great technique to get your stakeholders involved in if you have sticky notes handy. Give
your stakeholders the scope of what you’re decomposing and a pad of sticky notes, and have them
write down the processes (one per sheet) and then post them on the wall.

• Pro: Stakeholders can use the diagram to find missing processes.

• Con: Stakeholders may get caught up in how a process is performed rather than what’s being
performed.

• Con: The diagram doesn’t show solutions or sequence of processes. Let your stakeholders know you’ll
get there. First you have to make sure you have defined them all.
2.a)Explain in detail about Interfaces in Software Design and
Implementation.
Software design and implementation is the stage in the software engineering at which an executable
software system is developed.

Design and implementation activities are inter-leaved

Software design and implementation is the stage in the software engineering process at which an
executable software system is developed.
Software design and implementation activities are invariably inter-leaved.
➢ Software design is a creative activity in which you identify software components and their
relationships, based on a customer’s requirements.

➢ Implementation is the process of realizing the design as a program.

Software Design & Implementation Activity

The implementation stage of software development is the process of converting a system specification
into an executable system. A software design is a description of the structure of the software to be
implemented, the data which is part of the system, the interfaces between system components and,
sometimes, the algorithms used. Designers design step by step to meet the finished design to be
implemented in programming to crease an executable system out of the specification.

Thus, output of each stage of the design process is the input of the next stage. Stages continue until
a finished design is met which includes all the specification and work involved in the development of
the software.

Following is a diagram that illustrates software design activity

 Software design
activity in software process framework
Design Process Activities are as follows:

1. Architectural Design: Architectural design is about identifying the sub-systems or

modules of the system and the connections between them.
2. Abstract Specification: As per the output of the specification activity, abstract
specification and constraints for each sub-system or module is identified.
3. Interface Design: For each sub-system, its interface with other sub-systems is designed
and documented. This interface specification must be unambiguous as it allows the sub-
system to be used without knowledge of the sub-system operation.
4. Component Design: Services are allocated to components and the interfaces of these
components are designed.
5. Data Structure Design: The data structures used in the system implementation are
designed in detail and specified.
6. Algorithm Design: The algorithms used to provide services are designed in detail and
specified.

Implementing the System or Software Development:

Development of an executable program to implement the designed system is actually

programming to write source codes. There is no specific rules for programming. One developer
might want to start coding a component or part that s/he understands better and another
developer might want to start coding a component or part that s/he understands
less. However, at the end of the development of a part, developers do test and debug the
finished product. This often reveals program defects that must be removed from the program.
Defect testing and debugging are different processes. Testing establishes the existence of
defects. Debugging is concerned with locating and correcting these defects.
2.b)List some of the System Design Activities.
System design is the phase that bridges the gap between problem domain and the existing system
in a manageable way. This phase focuses on the solution domain, i.e. “how to implement?”
It is the phase where the SRS document is converted into a format that can be implemented and
decides how the system will operate.
In this phase, the complex activity of system development is divided into several smaller sub-activities,
which coordinate with each other to achieve the main objective of system development.

Inputs to System Design

System design takes the following inputs −
• Statement of work
• Requirement determination plan
• Current situation analysis
• Proposed system requirements including a conceptual data model, modified DFDs, and
Metadata (data about data).

Outputs for System Design

System design gives the following outputs −
• Infrastructure and organizational changes for the proposed system.
• A data schema, often a relational schema.
• Metadata to define the tables/files and columns/data-items.
 • A function hierarchy diagram or web page map that graphically describes the program
structure.
• Actual or pseudocode for each module in the program.
• A prototype for the proposed system.

Types of System Design

Logical Design
Logical design pertains to an abstract representation of the data flow, inputs, and outputs of the
system. It describes the inputs (sources), outputs (destinations), databases (data stores), procedures
(data flows) all in a format that meets the user requirements.
While preparing the logical design of a system, the system analyst specifies the user needs at level
of detail that virtually determines the information flow into and out of the system and the required data
sources. Data flow diagram, E-R diagram modeling are used.

Physical Design
Physical design relates to the actual input and output processes of the system. It focuses on how
data is entered into a system, verified, processed, and displayed as output.
It produces the working system by defining the design specification that specifies exactly what the
candidate system does. It is concerned with user interface design, process design, and data design.
It consists of the following steps −
• Specifying the input/output media, designing the database, and specifying backup procedures.
• Planning system implementation.
• Devising a test and implementation plan, and specifying any new hardware and software.
• Updating costs, benefits, conversion dates, and system constraints.

Architectural Design
It is also known as high level design that focuses on the design of system architecture. It describes
the structure and behavior of the system. It defines the structure and relationship between various
modules of system development process.

Detailed Design
It follows Architectural design and focuses on development of each module.

Conceptual Data Modeling

It is representation of organizational data which includes all the major entities and relationship.
System analysts develop a conceptual data model for the current system that supports the scope and
requirement for the proposed system.
The main aim of conceptual data modeling is to capture as much meaning of data as possible. Most
organization today use conceptual data modeling using E-R model which uses special notation to
represent as much meaning about data as possible.

Entity Relationship Model

It is a technique used in database design that helps describe the relationship between various entities
of an organization.

Terms used in E-R model

• ENTITY − It specifies distinct real world items in an application. For example: vendor, item,
student, course, teachers, etc.
• RELATIONSHIP − They are the meaningful dependencies between entities. For example,
vendor supplies items, teacher teaches courses, then supplies and course are relationship.
• ATTRIBUTES − It specifies the properties of relationships. For example, vendor code, student
name. Symbols used in E-R model and their respective meanings −
The following table shows the symbols used in E-R model and their significance −

Symbol Meaning

Entity

Weak Entity

Relationship

Identity Relationship
 Attributes

Key Attributes

Multivalued

Composite Attribute

Derived Attributes

Total Participation of
E2 in R

Cardinality Ratio 1:N

for E1:E2 in R
Three types of relationships can exist between two sets of data: one-to-one, one-to-many, and many-
to-many.

File Organization
It describes how records are stored within a file.
There are four file organization methods −
• Serial − Records are stored in chronological order (in order as they are input or
occur). Examples − Recording of telephone charges, ATM transactions, Telephone queues.
• Sequential − Records are stored in order based on a key field which contains a value that
uniquely identifies a record. Examples − Phone directories.
• Direct (relative) − Each record is stored based on a physical address or location on the device.
Address is calculated from the value stored in the record’s key field. Randomizing routine or
hashing algorithm does the conversion.
• Indexed − Records can be processed both sequentially and non-sequentially using indexes.

File Access
One can access a file using either Sequential Access or Random Access. File Access methods allow
computer programs read or write records in a file.

Sequential Access
Every record on the file is processed starting with the first record until End of File (EOF) is reached.
It is efficient when a large number of the records on the file need to be accessed at any given time.
Data stored on a tape (sequential access) can be accessed only sequentially.

Direct (Random) Access

Records are located by knowing their physical locations or addresses on the device rather than their
positions relative to other records. Data stored on a CD device (direct-access) can be accessed either
sequentially or randomly.

Types of Files used in an Organization System

Following are the types of files used in an organization system −
• Master file − It contains the current information for a system. For example, customer file,
student file, telephone directory.
• Table file − It is a type of master file that changes infrequently and stored in a tabular format.
For example, storing Zipcode.
• Transaction file − It contains the day-to-day information generated from business activities. It
is used to update or process the master file. For example, Addresses of the employees.
• Temporary file − It is created and used whenever needed by a system.
 • Mirror file − They are the exact duplicates of other files. Help minimize the risk of downtime in
cases when the original becomes unusable. They must be modified each time the original file
is changed.
• Log files − They contain copies of master and transaction records in order to chronicle any
changes that are made to the master file. It facilitates auditing and provides mechanism for
recovery in case of system failure.
• Archive files − Backup files that contain historical versions of other files.

Documentation Control
Documentation is a process of recording the information for any reference or operational purpose. It
helps users, managers, and IT staff, who require it. It is important that prepared document must be
updated on regular basis to trace the progress of the system easily.
After the implementation of system if the system is working improperly, then documentation helps the
administrator to understand the flow of data in the system to correct the flaws and get the system
working.
Programmers or systems analysts usually create program and system documentation. Systems
analysts usually are responsible for preparing documentation to help users learn the system. In large
companies, a technical support team that includes technical writers might assist in the preparation of
user documentation and training materials.

Advantages
• It can reduce system downtime, cut costs, and speed up maintenance tasks.
• It provides the clear description of formal flow of present system and helps to understand the
type of input data and how the output can be produced.
• It provides effective and efficient way of communication between technical and nontechnical
users about system.
• It facilitates the training of new user so that he can easily understand the flow of system.
• It helps the user to solve the problems such as troubleshooting and helps the manager to take
better final decisions of the organization system.
• It provides better control to the internal or external working of the system.

Types of Documentations
When it comes to System Design, there are following four main documentations −

• Program documentation
• System documentation
• Operations documentation
• User documentation

Program Documentation
• It describes inputs, outputs, and processing logic for all the program modules.
 • The program documentation process starts in the system analysis phase and continues during
implementation.
• This documentation guides programmers, who construct modules that are well supported by
internal and external comments and descriptions that can be understood and maintained
easily.

Operations Documentation
Operations documentation contains all the information needed for processing and distributing online
and printed output. Operations documentation should be clear, concise, and available online if
possible.
It includes the following information −
• Program, systems analyst, programmer, and system identification.
• Scheduling information for printed output, such as report, execution frequency, and deadlines.
• Input files, their source, output files, and their destinations.
• E-mail and report distribution lists.
• Special forms required, including online forms.
• Error and informational messages to operators and restart procedures.
• Special instructions, such as security requirements.

User Documentation
It includes instructions and information to the users who will interact with the system. For example,
user manuals, help guides, and tutorials. User documentation is valuable in training users and for
reference purpose. It must be clear, understandable, and readily accessible to users at all levels.
The users, system owners, analysts, and programmers, all put combined efforts to develop a user’s
guide.
A user documentation should include −
• A system overview that clearly describes all major system features, capabilities, and limitations.
• Description of source document content, preparation, processing, and, samples.
• Overview of menu and data entry screen options, contents, and processing instructions.
• Examples of reports that are produced regularly or available at the user’s request, including
samples.
• Security and audit trail information.
• Explanation of responsibility for specific input, output, or processing requirements.
• Procedures for requesting changes and reporting problems.
• Examples of exceptions and error situations.
• Frequently asked questions (FAQs).
• Explanation of how to get help and procedures for updating the user manual.
System Documentation
System documentation serves as the technical specifications for the IS and how the objectives of the
IS are accomplished. Users, managers and IS owners need never reference system documentation.
System documentation provides the basis for understanding the technical aspects of the IS when
modifications are made.
• It describes each program within the IS and the entire IS itself.
• It describes the system’s functions, the way they are implemented, each program's purpose
within the entire IS with respect to the order of execution, information passed to and from
programs, and overall system flow.
• It includes data dictionary entries, data flow diagrams, object models, screen layouts, source
documents, and the systems request that initiated the project.
• Most of the system documentation is prepared during the system analysis and system design
phases.
• During systems implementation, an analyst must review system documentation to verify that it
is complete, accurate, and up-to-date, and including any changes made during the
implementation process.

3.a)Explain about how to Address Design Goals.

Concurrency
Concurrency in software engineering means the collection of techniques and mechanisms that enable
a computer program to perform several different tasks simultaneously, or apparently simultaneously.
The need for concurrency in software first arose in the very early days of computing. Although early
computers were very much slower than modern machines, their peripheral devices (such as paper
tape or punched-card readers for input, and teletypewriters for output) were much slower still, and it
was soon recognized that many programs could be made to run very much faster if they did not spend
so much time waiting for input/output (I/O). The solution is easy in principle—simply allow I/O transfers
to be performed concurrently with each other and with normal computation (i.e., computation involving
only the central processor). To achieve this, new features needed to be added to both hardware and
software.

Today, such features—concurrency mechanisms, the most important of which are discussed in this
article—are commonplace and form a vital part of all modern computer systems. The operating system
of any computer (e.g., Windows, UNIX, Linux) makes use of concurrency to enable the user to do
several different things simultaneously or to allow many different users to access the computer at the
same time. Many operating systems allow a large number of tasks to be run concurrently and the
simultaneous use of peripheral devices. The earliest applications of concurrency were in real-time
systems such as operating systems, in which the software must perform actions at times determined
by external events.
3.b)Explain about Mapping Models to Code.
During object design we would like to implement a system that realizes the use cases specified
during requirements elicitation and system design.Object design is situated between system design
and implementation. Object design is not very well understood and if not well done, leads to a bad
system implementation. Here, we describe a selection of transformations to illustrate a disciplined
approach to implementation to avoid system degradation.
1. Operations on the object model:
Optimizations to address performance requirements
2. Implementation of class model components:
Realization of associations
Realization of operation contracts
3. Realizing entity objects based on selected storage strategy
Mapping the class model to a storage schema.
Characteristics of Object Design Activities
Developers perform transformations to the object model to improve its modularity and performance.
Developers transform the associations of the object model into collections of object references,
because programming languages do not support the concept of association.
If the programming language does not support contracts, the developer needs to write code for
detecting and handling contract violations. Developers often revise the interface specification to
accommodate new requirements from the client.

4.a)Explain about Requirements Management.

Once a system has been deployed, new requirements inevitably emerge. It is difficult for the users to
anticipate the effect of these new requirements (if a new system is developed for these requirements)
on the organization. Thus, to understand and control changes to system requirements, requirements
management is performed.
Requirements management can be defined as a process of eliciting, documenting, organizing, and
controlling changes to the requirements. Generally, the process of requirements management begins
as soon as the requirements document is available, but ‘planning’ for managing the changing
requirements should start during the requirements elicitation process.

The essential activities performed in requirements management are listed below.

▪ Recognizing the need for change in the requirements

▪ Establishing a relationship amongst stakeholders and involving them in the requirements
engineering process
▪ Identifying and tracking requirements attributes.
 Requirements management enables the development team to identify, control, and track
requirements and changes that occur as the software development process progresses. Other
advantages associated with the requirements management are listed below.

▪ Better control of complex projects: This provides the development team with a clear
understanding of what, when, and why the software is to be delivered. The resources are
allocated according to user-driven priorities and relative implementation effort.
▪ Improved software quality: This ensures that the software performs according to the
requirements to enhance software quality. This can be achieved when the developers and testers
have a precise understanding of what to develop and test.
▪ Reduced project costs and delays: This minimizes errors early in the development cycle as it
is expensive to ‘fix’ errors at the later stages of the development cycle. As a result, the project
costs also reduce.
▪ Improved team communication: This facilitates early involvement of users to ensure that their
needs are achieved.
▪ Easing compliance with standards and regulations: This ensures that standards involved
with software compliance and process improvement have a thorough understanding of
requirements management. For example, CMM addresses requirements management as one of
the first steps to improve software quality.
▪ All the user requirements are specified in the software requirements specification. The project
manager as part of requirements management tracks the requirements for the current project
and those which are planned for the next release.

We’ll be covering the following topics in this tutorial:

• Requirements Management Process

• Requirements Change Management
Requirements Management Process

Requirements management starts with planning, which establishes the level of requirements
management needed. After planning, each requirement is assigned a unique ‘identifier’ so that it can
be crosschecked by other requirements. Once requirements are identified, requirements tracing is
performed.
Requirements tracing is a medium to trace requirements from the start of development process till
the software is delivered to the user. The objective of requirements tracing is to ensure that all the
requirements are well understood and included in test plans and test cases. Various advantages of
requirements tracing are listed below.

▪ It verifies whether user requirements are implemented and adequately tested.

▪ It enables user understanding of impact of changing requirements.

Trace ability techniques facilitate the impact of analysis on changes of the project, which is under
development. Traceability information is stored in a traceability matrix, which relates requirements to
stakeholders or design module. The traceability matrix refers to a table that correlates high-level
requirements with the detailed requirements of the product. Mainly, five types of traceability tables
are maintained. These are listed in Table.
In a traceability matrix, each requirement is entered in a row and column of the matrix. The
dependencies between different requirements are represented in the cell at a row and column
intersection. ‘U’ in the row and column intersection indicates the dependencies of the requirements
in the row on the column and ‘R’ in the row and column intersection indicates the existence of some
other weaker relationship between the requirements.
Table Types of Traceability Tables

Traceability Table Description

Features traceability Indicates how requirements relate to

important features specified by the user.

Source traceability Identifies the source of each requirement

by linking the requirements to the
stakeholders who proposed them. When a
change is proposed, information from this
table can be used to find and consult the
stakeholders.

Requirements traceability Indicates how dependent requirements in

the SRS are related to one another.
Information from this table can be used to
evaluate the number of requirements that
will be affected due to the proposed
change(s).

Design traceability Links the requirements to the design

modules where these requirements are
implemented. Information from this table
can be used to evaluate the impact of
proposed requirements changes on the
software design and implementation.

Interface traceability Indicates how requirements are related to

internal interface and external interface of a
system.

4.b)Sketch an example to explain Use case diagram.

UML - Use Case Diagrams

To model a system, the most important aspect is to capture the

dynamic behavior. Dynamic behavior means the behavior of the
system when it is running/operating.
Only static behavior is not sufficient to model a system rather dynamic
behavior is more important than static behavior. In UML, there are five
diagrams available to model the dynamic nature and use case
diagram is one of them. Now as we have to discuss that the use case
diagram is dynamic in nature, there should be some internal or
external factors for making the interaction.
These internal and external agents are known as actors. Use case
diagrams consists of actors, use cases and their relationships. The
diagram is used to model the system/subsystem of an application. A
single use case diagram captures a particular functionality of a
system.
Hence to model the entire system, a number of use case diagrams are
used.
Purpose of Use Case Diagrams
The purpose of use case diagram is to capture the dynamic aspect of
a system. However, this definition is too generic to describe the
purpose, as other four diagrams (activity, sequence, collaboration,
and Statechart) also have the same purpose. We will look into some
specific purpose, which will distinguish it from other four diagrams.
Use case diagrams are used to gather the requirements of a system
including internal and external influences. These requirements are
mostly design requirements. Hence, when a system is analyzed to
gather its functionalities, use cases are prepared and actors are
identified.
When the initial task is complete, use case diagrams are modelled to
present the outside view.
In brief, the purposes of use case diagrams can be said to be as
follows −
• Used to gather the requirements of a system.
• Used to get an outside view of a system.
• Identify the external and internal factors influencing the system.
 • Show the interaction among the requirements are actors.
How to Draw a Use Case Diagram?
Use case diagrams are considered for high level requirement analysis
of a system. When the requirements of a system are analyzed, the
functionalities are captured in use cases.
We can say that use cases are nothing but the system functionalities
written in an organized manner. The second thing which is relevant to
use cases are the actors. Actors can be defined as something that
interacts with the system.
Actors can be a human user, some internal applications, or may be
some external applications. When we are planning to draw a use case
diagram, we should have the following items identified.
• Functionalities to be represented as use case
• Actors
• Relationships among the use cases and actors.
Use case diagrams are drawn to capture the functional requirements
of a system. After identifying the above items, we have to use the
following guidelines to draw an efficient use case diagram
• The name of a use case is very important. The name should be
chosen in such a way so that it can identify the functionalities
performed.
• Give a suitable name for actors.
• Show relationships and dependencies clearly in the diagram.
• Do not try to include all types of relationships, as the main
purpose of the diagram is to identify the requirements.
• Use notes whenever required to clarify some important points.
Following is a sample use case diagram representing the order
management system. Hence, if we look into the diagram then we will
find three use cases (Order, SpecialOrder, and NormalOrder) and
one actor which is the customer.
The SpecialOrder and NormalOrder use cases are extended
from Order use case. Hence, they have extended relationship.
Another important point is to identify the system boundary, which is
shown in the picture. The actor Customer lies outside the system as it
is an external user of the system.

Where to Use a Use Case Diagram?

As we have already discussed there are five diagrams in UML to
model the dynamic view of a system. Now each and every model has
some specific purpose to use. Actually these specific purposes are
different angles of a running system.
To understand the dynamics of a system, we need to use different
types of diagrams. Use case diagram is one of them and its specific
purpose is to gather system requirements and actors.
Use case diagrams specify the events of a system and their flows. But
use case diagram never describes how they are implemented. Use
case diagram can be imagined as a black box where only the input,
output, and the function of the black box is known.
These diagrams are used at a very high level of design. This high level
design is refined again and again to get a complete and practical
picture of the system. A well-structured use case also describes the
pre-condition, post condition, and exceptions. These extra elements
are used to make test cases when performing the testing.
Although use case is not a good candidate for forward and reverse
engineering, still they are used in a slightly different way to make
forward and reverse engineering. The same is true for reverse
engineering. Use case diagram is used differently to make it suitable
for reverse engineering.
In forward engineering, use case diagrams are used to make test
cases and in reverse engineering use cases are used to prepare the
requirement details from the existing application.
Use case diagrams can be used for −
• Requirement analysis and high level design.
• Model the context of a system.
• Reverse engineering.
• Forward engineering.
PART -C (Answer all the Questions)
1.a)Explain in detail about System Design Concepts.
Software Design is the process to transform the user requirements
into some suitable form, which helps the programmer in software
coding and implementation. During the software design phase, the
design document is produced, based on the customer requirements
as documented in the SRS document. Hence the aim of this phase is
to transform the SRS document into the design document.
The following items are designed and documented during the design
phase:
 • Different modules required.
• Control relationships among modules.
• Interface among different modules.
• Data structure among the different modules.
• Algorithms required to implement among the individual modules.
Objectives of Software Design:
1. Correctness:
A good design should be correct i.e. it should correctly implement
all the functionalities of the system.
2. Efficiency:
A good software design should address the resources, time, and
cost optimization issues.
3. Understandability:
A good design should be easily understandable, for which it
should be modular and all the modules are arranged in layers.
4. Completeness:
The design should have all the components like data structures,
modules, and external interfaces, etc.
5. Maintainability:
A good software design should be easily amenable to change
whenever a change request is made from the customer side.
Software Design Concepts:
Concepts are defined as a principal idea or invention that comes into
our mind or in thought to understand something. The software design
concept simply means the idea or principle behind the design. It
describes how you plan to solve the problem of designing software,
the logic, or thinking behind how you will design software. It allows the
software engineer to create the model of the system or software or
product that is to be developed or built. The software design concept
provides a supporting and essential structure or model for developing
the right software. There are many concepts of software design and
some of them are given below:

The following points should be considered while designing

Software:
1. Abstraction- hide Irrelevant data
Abstraction simply means to hide the details to reduce complexity
and increases efficiency or quality. Different levels of Abstraction
are necessary and must be applied at each stage of the design
process so that any error that is present can be removed to
increase the efficiency of the software solution and to refine the
software solution. The solution should be described in broad
ways that cover a wide range of different things at a higher level
of abstraction and a more detailed description of a solution of
software should be given at the lower level of abstraction.
2. Modularity- subdivide the system
Modularity simply means dividing the system or project into
smaller parts to reduce the complexity of the system or project. In
the same way, modularity in design means subdividing a system
into smaller parts so that these parts can be created
independently and then use these parts in different systems to
perform different functions. It is necessary to divide the software
 into components known as modules because nowadays there are
different software available like Monolithic software that is hard to
grasp for software engineers. So, modularity in design has now
become a trend and is also important. If the system contains
fewer components then it would mean the system is complex
which requires a lot of effort (cost) but if we are able to divide the
system into components then the cost would be small.
3. Architecture- design a structure of something
Architecture simply means a technique to design a structure of
something. Architecture in designing software is a concept that
focuses on various elements and the data of the structure. These
components interact with each other and use the data of the
structure in architecture.
4. Refinement- removes impurities
Refinement simply means to refine something to remove any
impurities if present and increase the quality. The refinement
concept of software design is actually a process of developing or
presenting the software or system in a detailed manner that
means to elaborate a system or software. Refinement is very
necessary to find out any error if present and then to reduce it.
5. Pattern- a repeated form
The pattern simply means a repeated form or design in which the
same shape is repeated several times to form a pattern. The
pattern in the design process means the repetition of a solution
to a common recurring problem within a certain context.
6. Information Hiding- hide the information
Information hiding simply means to hide the information so that it
cannot be accessed by an unwanted party. In software design,
information hiding is achieved by designing the modules in a
 manner that the information gathered or contained in one module
is hidden and can’t be accessed by any other modules.
7. Refactoring- reconstruct something
Refactoring simply means reconstructing something in such a
way that it does not affect the behavior of any other features.
Refactoring in software design means reconstructing the design
to reduce complexity and simplify it without affecting the behavior
or its functions. Fowler has defined refactoring as “the process of
changing a software system in a way that it won’t affect the
behavior of the design and improves the internal structure”.
Different levels of Software Design:
There are three different levels of software design. They are:
Architectural Design:
The architecture of a system can be viewed as the overall structure of
the system & the way in which structure provides conceptual integrity
of the system. The architectural design identifies the software as a
system with many components interacting with each other. At this
level, the designers get the idea of the proposed solution domain.
1. Preliminary or high-level design:
Here the problem is decomposed into a set of modules, the
control relationship among various modules identified, and also
the interfaces among various modules are identified. The
outcome of this stage is called the program architecture. Design
representation techniques used in this stage are structure chart
and UML.
2. Detailed design:
Once the high-level design is complete, a detailed design is
undertaken. In detailed design, each module is examined
carefully to design the data structure and algorithms. The stage
 outcome is documented in the form of a module specification
document.
1.b).Explain about Managing System Design in detail.
Managing Analysis and Design Activities
Along with managing time and resources, systems analysts must also
manage people. Management is accomplished primarily by
communicating accurately to team members who have been selected
for their competency and compatibility. Goals for project productivity
must be set, and members of systems analysis teams must be
motivated to achieve them.
Assembling a Team
Assembling a team is desirable. If a project manager has the
opportunity to create a dream team of skilled people to develop a
system, whom should he or she choose? In general, project managers
need to look for others who share their values of teamwork guided by
the desire to deliver a high-quality system on time and on budget.
Other desirable team member characteristics include a good work
ethic, honesty, competency; a readiness to take on leadership based
on expertise; motivation, enthusiasm for the project, and trust of
teammates.
The project manager needs to know about business principles, but it
doesn’t hurt to have at least one other person on the team who
understands how a business operates. Perhaps this person should be
a specialist in the same area as the system being developed. When
developing an ecommerce site, teams can enlist the help of someone
in marketing; those developing an inventory system can ask a person
versed in production and operations to provide expertise.
A team ideally should have two systems analysts on it. They can help
each other, check each other’s work, and shift their workloads
accordingly. There is certainly a need to have people with
programming skills on board. Coding is important, but people who
know how to conduct walkthroughs, reviews, testing, and
documenting systems are important as well. Some people are good at
seeing the big picture, while others perform well when tasks are
broken down into smaller ones for them. Every team should have both
types of individuals.
Beyond the basics, a project manager should look for people with both
experience and enthusiasm. Experience is especially important when
trying to estimate the time required to complete a project. Experience
in programming can mean code is developed five times faster than if
it is developed by an inexperienced team. A usability expert is also a
useful addition to the team.
The team must be motivated. One way to keep the team positively
oriented throughout the entire process is to select good people at the
outset. Look for enthusiasm, imagination, and an ability to
communicate with different kinds of people. These basic attributes
hold the potential for success. It also helps to hire superior writers and
articulate speakers who can present proposals and work directly with
customers.
Trust is an important part of a team. All members of the project need
to act responsibly and agree to do their best and complete their part
of the project. People may have different work styles, but they all need
to agree to work together toward a common goal.
Communication Strategies for Managing Teams
Teams have their own personalities, a result of combining each
individual team member with every other in a way that creates a totally
new network of interactions. A way to organize your thinking about
teams is to visualize them as always seeking a balance between
accomplishing the work at hand and maintaining the relationships
among team members.
In fact, teams will often have two leaders, not just one. Usually one
person will emerge who leads members to accomplish tasks, and
another person will emerge who is concerned with the social
relationships among group members. Both are necessary for the
team. These individuals have been labeled by other researchers as,
respectively, task leader and socioemotional leader. Every team is
subject to tensions that are an outgrowth of seeking a balance
between accomplishing tasks and maintaining relationships among
team members.
For the team to continue its effectiveness, tensions must be
continually resolved. Minimizing or ignoring tensions will lead to
ineffectiveness and eventual disintegration of the team. Much of the
tension release necessary can be gained through skillful use of
feedback by all team members. All members, however, need to agree
that the way they interact (i.e., process) is important enough to merit
some time. Productivity goals for processes are discussed in a later
section.
Securing agreement on appropriate member interaction involves
creating explicit and implicit team norms (collective expectations,
values, and ways of behaving) that guide members in their
relationships. A team’s norms belong to it and will not necessarily
transfer from one team to another. These norms change over time and
are better thought of as a team process of interaction rather than a
product.
Norms can be functional or dysfunctional. Just because a particular
behavior is a norm for a team does not mean it is helping the team to
achieve its goals. For example, an expectation that junior team
members should do all project scheduling may be a team norm. By
adhering to this norm, the team is putting extreme pressure on new
members and not taking full advantage of the experience of the team.
It is a norm that, if continued, could make team members waste
precious resources.
Team members need to make norms explicit and periodically assess
whether norms are functional or dysfunctional in helping the team
achieve its goals. The overriding expectation for your team must be
that change is the norm. Ask yourself whether team norms are helping
or hindering the team’s progress.
Setting Project Productivity Goals
When you have worked with your team members on various kinds of
projects, you or your team leader will acquire acumen for projecting
what the team can achieve in a specific amount of time. Using the
hints discussed in the earlier section in this chapter on methods for
estimating time required and coupling them with experience will
enable the team to set worthwhile productivity goals.
Systems analysts are accustomed to thinking about productivity goals
for employees who show tangible outputs, such as the number of blue
jeans sewn per hour, the number of entries keyed in per minute, or the
number of items scanned per second. As manufacturing productivity
rises, however, it is becoming clear that managerial productivity must
keep pace. It is with this aim in mind that productivity goals for the
systems analysis team are set.
Goals need to be formulated and agreed to by the team, and they
should be based on team members’ expertise, former performance,
and the nature of the specific project. Goals will vary somewhat for
each project undertaken, because sometimes an entire system will be
installed, whereas other projects might involve limited modifications to
a portion of an existing system.
Motivating Project Team Members
Although motivation is an extremely complex topic, it is a good one to
consider, even if briefly, at this point. To oversimplify, recall that people
join organizations to provide for some of their basic needs such as
food, clothing, and shelter. All humans, however, also have higher-
level needs, which include affiliation, control, independence, and
creativity. People are motivated to fulfill unmet needs on several
levels.
Team members can be motivated, at least partially, through
participation in goal setting, as described in the previous section. The
very act of setting a challenging but achievable goal and then
periodically measuring performance against the goal seems to work in
motivating people. Goals act almost as magnets in attracting people
to achievement.
Part of the reason goal setting motivates people is that team members
know prior to any performance review exactly what is expected of
them. The success of goal setting for motivating can also be ascribed
to it, affording each team member some autonomy in achieving the
goals. Although a goal is predetermined, the means to achieve it may
not be. In this instance team members are free to use their own
expertise and experience to meet their goals.
Setting goals can also motivate team members by clarifying for them
and others what must be done to get results. Team members are also
motivated by goals because goals define the level of achievement that
is expected of them. This use of goals simplifies the working
atmosphere, but it also electrifies it with the possibility that what is
expected can indeed be done.
Managing Ecommerce Projects
Many of the approaches and techniques discussed earlier are
transferable to ecommerce project management. You should be
cautioned, however, that although there are many similarities, there
are also many differences. One difference is that the data used by
ecommerce systems are scattered all over the organization.
Therefore, you are not just managing data in a self-contained
department or even one solitary unit. Hence, many organizational
politics can come into play, because units often feel protective of the
data they generate and do not understand the need to share them
across the organization.
Another stark difference is that ecommerce project teams typically
need more staff with a variety of skills, including developers,
consultants, database experts, and system integrators, from across
the organization. Neatly defined, stable project groups that exist within
a cohesive IS group or systems development team will be the
exception rather than the rule. In addition, because so much help may
be required initially, ecommerce project managers need to build
partnerships externally and internally well ahead of the
implementation, perhaps sharing talent across projects to defray costs
of ecommerce implementations and to muster the required numbers
of people with the necessary expertise. The potential for
organizational politics to drive a wedge between team members is
very real.
One way to prevent politics from sabotaging a project is for the
ecommerce project manager to emphasize the integration of the
ecommerce with the organization’s internal systems and in so doing
emphasize the organizational aspect embedded in the ecommerce
project. As one ecommerce project manager told us, “Designing the
front end [what the consumer sees] is the easy part of all this. The real
challenge comes from integrating ecommerce strategically into all the
organization’s systems.”
A fourth difference between traditional project management and
ecommerce project management is that because the system will be
linking with the outside world via the Internet, security is of the utmost
importance. Developing and implementing a security plan before the
new system is in place is a project in and of itself and must be
managed as such.
2.a).Explain the various categories of Reusing Pattern Solutions.
Design patterns represent the best practices used by experienced
object-oriented software developers. Design patterns are solutions to
general problems that software developers faced during software
development. These solutions were obtained by trial and error by
numerous software developers over quite a substantial period of time.
What is Gang of Four (GOF)?
In 1994, four authors Erich Gamma, Richard Helm, Ralph Johnson
and John Vlissides published a book titled Design Patterns -
Elements of Reusable Object-Oriented Software which initiated the
concept of Design Pattern in Software development.
These authors are collectively known as Gang of Four (GOF).
According to these authors design patterns are primarily based on the
following principles of object orientated design.
• Program to an interface not an implementation
• Favor object composition over inheritance
Usage of Design Pattern
Design Patterns have two main usages in software development.
Common platform for developers
Design patterns provide a standard terminology and are specific to
particular scenario. For example, a singleton design pattern signifies
use of single object so all developers familiar with single design
pattern will make use of single object and they can tell each other that
program is following a singleton pattern.
Best Practices
Design patterns have been evolved over a long period of time and they
provide best solutions to certain problems faced during software
development. Learning these patterns helps unexperienced
developers to learn software design in an easy and faster way.
Types of Design Patterns
As per the design pattern reference book Design Patterns -
Elements of Reusable Object-Oriented Software , there are 23
design patterns which can be classified in three categories:
Creational, Structural and Behavioral patterns. We'll also discuss
another category of design pattern: J2EE design patterns.

S.N. Pattern & Description

1 Creational Patterns
These design patterns provide a way to create objects
while hiding the creation logic, rather than instantiating
objects directly using new operator. This gives program
more flexibility in deciding which objects need to be
created for a given use case.

2 Structural Patterns
These design patterns concern class and object
composition. Concept of inheritance is used to compose
interfaces and define ways to compose objects to obtain
new functionalities.

3 Behavioral Patterns
These design patterns are specifically concerned with
communication between objects.

4 J2EE Patterns
These design patterns are specifically concerned with
the presentation tier. These patterns are identified by
Sun Java Center.
2.b).Explain about the types of Testing in Software Engineering.
Testing is the process of evaluating a system or its component(s) with
the intent to find whether it satisfies the specified requirements or not.
Testing is executing a system in order to identify any gaps, errors, or
missing requirements in contrary to the actual requirements.
This tutorial will give you a basic understanding on software testing,
its types, methods, levels, and other related terminologies.
Why to Learn Software Testing?
In the IT industry, large companies have a team with responsibilities
to evaluate the developed software in context of the given
requirements. Moreover, developers also conduct testing which is
called Unit Testing. In most cases, the following professionals are
involved in testing a system within their respective capacities −
• Software Tester
• Software Developer
• Project Lead/Manager
• End User
Different companies have different designations for people who test
the software on the basis of their experience and knowledge such as
Software Tester, Software Quality Assurance Engineer, QA Analyst,
etc.
Applications of Software Testing
• Cost Effective Development - Early testing saves both time and
cost in many aspects, however reducing the cost without testing
may result in improper design of a software application rendering
the product useless.
 • Product Improvement - During the SDLC phases, testing is
never a time-consuming process. However diagnosing and fixing
the errors identified during proper testing is a time-consuming but
productive activity.
• Test Automation - Test Automation reduces the testing time, but
it is not possible to start test automation at any time during
software development. Test automaton should be started when
the software has been manually tested and is stable to some
extent. Moreover, test automation can never be used if
requirements keep changing.
• Quality Check - Software testing helps in determining following
set of properties of any software such as
o Functionality
o Reliability
o Usability
o Efficiency
o Maintainability
o Portability
Audience
This tutorial is designed for software testing professionals who would
like to understand the Testing Framework in detail along with its types,
methods, and levels. This tutorial provides enough ingredients to start
with the software testing process from where you can take yourself to
higher levels of expertise.