MCS-014 Systems Analysis and Design

________________________________________________________________________
Course Code : MCS-014
Course Title : Systems Analysis and Design
Assignment Number : MCA(1)/014/Assign/09
______________________________________________________________________________

Q1: Define the term “Documentation”. Also, write a short note on the following:
• System Requirements Specificaion
• System Design Specification
• Test Document
• User Manual

Ans. Documentation:

In computer hardware and software product development, documentation is the information that describes the product to
its users. Software documentation: program listings or technical manuals describing the operation and use of programs.

Documentation is Instructions for using a computer device o r program. Documentation can appear in a variety of
forms, the most common being manuals. When you buy a computer product ( hardware o r software), it almost always
comes with one or more manuals that describe how to install and operate the product. In addition, many software
products include an online version of the documentation that you can display on your screen or print out on a printer. A
special type of online documentation is a help system , which has the documentation embedded into the program. Help
systems are often called context-sensitive because they display different information depending on the user's position
(context) in the application.

Documentation is often divided into the following categories:

installation: Describes how to install a program or device but not how to use it.
reference: Detailed descriptions of particular items presented in alphabetical order. Reference
documentation is designed for people who are already somewhat familiar with the
product but need reminders or very specific information about a particular topic.
Tutorial: Teaches a user how to use the product. Tutorials move at a slower pace than reference
manuals and generally contain less detail.

1. System Requirement Specification

A System Requirements Specification (SRS) is a document where the requirements of a system that is planned to be
developed are listed.

A Business analyst (BA), sometimes titled System analyst, is responsible for analysing the business needs of their
clients and stakeholders to help identify business problems and propose solutions. Within the systems development life
cycle domain, the BA typically performs a liaison function between the business side of an enterprise and the
information technology department or external service providers.

Requirements analysis i n systems engineering a n d software engineering, encompasses those tasks that go into
determining the needs or conditions to meet for a new or altered product, taking account of the possibly conflicting
requirements of the various stakeholders, such as beneficiaries or users.

11
Requirements analysis is critical to the success of a development project. Requirements must be actionable, measurable,
testable, related to identified business needs or opportunities, and defined to a level of detail sufficient for system design.

Systematic requirements analysis is also known as requirements engineering.It is sometimes referred to loosely by
names such as requirements gathering, requirements capture, o r requirements specification. The term requirements
analysis can also be applied specifically to the analysis proper, as opposed to elicitation or documentation of the
requirements, for instance.

Requirement engineering is a subdiscipline of systems engineering a n d software engineering that is concerned with
determining the goals, functions, and constrains of hardware and software systems. In some life cycle models, the
requirement engineering process begins with a feasibility study activity, which leads to a feasibility report. If the
feasibility study suggest that the product should be developed, then requirement analysis can begin. If requirement
analysis precedes feasibility studies, which may foster outside the box thinking, then feasibility should be determined
before requirements are finalized.

2. System Design Specification

The system design specifications address the "look and feel" of the interface, with rules for the display of global and
particular elements.

Flow or Logic Diagram

Flow diagrams define the end-user's paths throng the site and site functionality. A flow diagram for a commerce site
would detail the sequence of pages necessary to gather the information required by the commerce application in order to
complete an order.

Logic diagrams describe the order that logic decisions are made during the transmission, gathering, or testing of data. So
for example, upon submission of a form, information may be reviewed by the system for field completeness before being
reviewed for algorithmic accuracy; in other words, the system may verify that required fields have in fact been
completed before verifying that the format of the email address is correct or the credit card number is an algorithmically
valid number. Another example would be the logic applied to a search query, detailing the steps involved in the query
cleanup and expansion, and the application of Boolean operators.

System Architecture Diagram

A system architecture diagram illustrates the way the system hardware and software must be configured, and the way the
database tables should be defined and laid out.

Prototypes and Mock-ups

A prototype is a model of the system delivered in the medium of the system. For example, a web site prototype would
be delivered as a web site, using the standard web protocols, so that it could be interacted with in the same medium as
the project's product. Prototypes don't have to be fully functioning, they merely have to be illustrative of what the
product should look and feel like. In contrast, a mock-up is a representation in a different medium. A web site mock-up
might be a paper representation of what the pages should look like.

The authors of Constructing Superior Software describe several categories of prototypes: low fidelity prototypes which
correspond to what I've labeled "mock-ups", and high fidelity prototypes.

Low fidelity prototypes are limited function and limited interaction prototypes. They are constructed to depict concepts,
design alternatives, and screen layouts rather than to model the user interaction with the system....There are two forms of
low fidelity prototype: abstract and concrete....The visual designer works from the abstract prototype and produces
drawings of the interface as a concrete low fidelity prototype....High fidelity prototypes are fully interactive (p 70-71).

Prototypes and mock-ups are important tools for defining the visual design, but they can be problematic from a quality
assurance and testing point of view because they are a representation of a designer's idea of what the product should look
and feel like. The issue is not that the designer's may design incorrectly, but that the prototype or mock-up will become

12
the de facto design by virtue of being a representation. The danger is that the design will become final before it has been
approved; this is known as "premature concretization" or "premature crispness of representation", where a sample
becomes the final design without a formal decision. If you have every tried to get page element removed from a design,
you have an idea what this problem is like. The value of prototypes is that they provide a visual dimension to the written
requirements and specifications; they are both a proof of concept and the designers' sketchpad wrapped up in one
package.

Technical Specifications
Technical specifications are typically written the by developers and coders, and describe how they will implement the project. The developers
work from the functional specifications, and translate the functions into their actual coding practices and methodologies.

3. Test Document
In this document, we give the test plan and test results for unit testing of some of the key modules of the Personal
Investment Management System (PIMS).

2.Unit Testing Methodology

2.1 Selection of units: We selected only the most important functional and critical classes for formal unit testing. In the
test environment we used, a unit for unit testing is a class. Here we illustrate the testing methodology by discussing only
two classes.

2.2 Test Scripts: As we used Junit for unit testing. The test scripts were java programs and each test case corresponded
to a method in these java programs.

2.3 Fixing of Defects: The programmer fixed the defects found. Unit testing was successfully complete only if the script
executed without any defects.

2.4 Test Script Enhancement: As testing proceeded, some new test cases were added.This was done by adding new test
methods to the testing program.

3. The Testing Tool: Junit

We used Junit as the tool for unit testing. It is open source software which can be used to test Java modules. It can be
freely downloaded from the website www.junit.org .The general way to test the module (usually a ‘class’) by Junit: We
create a class extending TestCase(a predefined class of Junit), and write the following methods:
(a) setUp(): In this we instantiate various objects needed to perform the testing.
(b) tearDown(): In this we deallocate all or some of the memory which was used up by objects created in
setUp() method. This is called at the end of all tests.
(c) suite(): This method is used to create a test suite, which specifies as to which tests will be performed.
(d) Various methods of the name testXXX(): These methods contain the actual code for testing. In any such
method, we do whatever operations we want to do, and then call the method assertTrue()/assertFalse(),
with a boolean as the argument, which specifies as to what condition we wish to hold true/false, for being
convinced that the tested method performs correctly.

4. Tests Performed
We unit tested the methods of following two classes: (a) Alerts, and (b) Investment
(a) Testing methods of class Alerts:

4.User Manual
As the name implies, User manual are written to help people understand an software application or IT system. They are also called
User guide. When writing a User manual, use simple language with short sentences. This writing style helps the user understand the
application.

User manual are the first port of call when something needs to be read. As many people read user guides when frustrated and after
having lost patience with the software, you need to write your material to address their concerns quickly.

13
User manual are often written for non-technical individuals. The level of content and terminology differs considerably from, for
example, a System Administration Guide, which is more detailed and complex.

This rest of article offers some guidelines to consider when writing your User Guide, such as:

· Identifying your audience

· Writing sections

· Defining style guide and standards

· Delivery formats

Ques2. Draw DFD’s upto 3rd level for a Railway Reservation System. Make assumptions wherever
necessary.

Content Level Diagram For

Railway Reservation System

Schedules
FLIGHTS CUSTOMER

PACKAGES Railway Cancellation

Reservation
System

Reservation

14
 I Level DFD

Request 1.1
CUSTOMER Reservation
Reservation D1: Reservation
Tickets

Cancel
Request

D5: Customer Check schedules

Reserve Ticket

1.3 Generate
Cancellation Ticket 1.4
Schedules
Cancel Ticket

Refund
1.2 Railway
Reservation
System
D2: cancellation D3: Schedules

Administrator

D4: Administrator

15
 II Level DFD for Scheduling

Administration 3.1
Schedules

Informs

2.2
Railway
Reservation
System

D4: Administrator

16
 II Level DFD

Enter
CUSTOMER 2.1
Data
Reservation

D1: Reservation

Deliver Ticket Reserve ticket

2.2
Railway
reservation
system

Administrator

D4: Administrator

17
 III Level DFD for Cancellation

CUSTOMER Request 3.1

Cancellation Cancellation

D1: Customer

D2: Cancellation
Refund amount Cancels

3.1
Railway reservation
system

SCREEN
Administrator

D4: Administrator

18
Ques3. Draw complete Entity Relationship Diagram (ERD) for a Railway Reservation System. Make
assumptions wherever necessary.

19
 ER-Diagram For Railway Reservation Systems

Source
Destination Train No. Time Source
Train No.
Train
Time Date Destinatio
No.
n

TrainSched
TRAINS Schedules

Train Address
No. of Seats No
Train No. Ticket
Ticket ID. Reservation Id
Date

Cancellation

Name Address

Cust. ID.
City

Reservation
CUSTOMER

20
Ques4.Explain the following kinds of information systems:
Transaction Processing Systems
Management Information Systems
Decision Support Systems
Expert Systems

1. Transaction processing system

A Transaction Processing System or Transaction Processing Monitor is a system that monitors transaction programs
(a special kind of program). The essence of a transaction program is that it manages data that must be left in a consistent
state. E.g. if an electronic payment is made, the amount must be either both withdrawn from one account and added to
the other, or none at all. In case of a failure preventing transaction completion, the partially executed transaction must be
' rolled back' by the TPS. While this type of integrity must be provided also for batch transaction processing, it is
particularly important for online processing: if e.g. an airline seat reservation system is accessed by multiple operators,
after an empty seat inquiry, the seat reservation data must be locked until the reservation is made, otherwise another user
may get the impression a seat is still free while it is actually being booked at the time. Without proper transaction
monitoring, double bookings may occur. Other transaction monitor functions include deadlock detection and resolution
(deadlocks may be inevitable in certain cases of cross-dependence on data), and transaction logging (in 'journals') for
'forward recovery' in case of massive failures.

Transaction Processing is not limited to application programs. The 'journaled file system' provided with IBMs AIX Unix
operating system employs similar techniques to maintain file system integrity, including a journal.

2.Management Processing System

A management information system ( MIS) is a subset of the overall internal controls of a business covering the
application of people, documents, technologies, and procedures by management accountants to solving business
problems such as costing a product, service or a business-wide strategy. Management information systems are distinct
from regular information systems in that they are used to analyze other information systems applied in operational
activities in the organization. [1] Academically, the term is commonly used to refer to the group of information
management methods tied to the automation or support of human decision making, e.g. Decision Support Systems,
Expert systems, and Executive information systems.
An 'MIS' is a planned system of the collecting, processing, storing and disseminating data in the form of information
needed to carry out the functions of management. According to Phillip Kotler "A marketing information system consists
of people, equipment, and procedures to gather, sort, analyze, evaluate, and distribute needed, timely, and accurate
information to marketing decision makers.

The terms MIS and information system are often confused. Information systems include systems that are not intended for
decision making. The area of study called MIS is sometimes referred to, in a restrictive sense, as information technology
management. That area of study should not be confused with computer science. IT service management is a
practitioner-focused discipline. MIS has also some differences with Enterprise Resource Planning (ERP) as ERP
incorporates elements that are not necessarily focused on decision support.

3.Decision Support System

Decision support systems constitute a class of computer-based information systems including knowledge-based
systems that support decision-making activities.

Decision Support Systems (DSS) are a specific class of computerized information system that supports business and
organizational decision-making activities. A properly-designed DSS is an interactive software-based system intended to
help decision makers compile useful information from raw data, documents, personal knowledge, and/or business
models to identify and solve problems and make decisions.

21
Typical information that a decision support application might gather and present would be:

· an inventory of all of your current information assets (including legacy and relational data sources, cubes, data
warehouses, and data marts),
· comparative sales figures between one week and the next,
· projected revenue figures based on new product sales assumptions;
· the consequences of different decision alternatives, given past experience in a context that is described.

4.Expert System

An expert system i s software that attempts to reproduce the performance of one or more human experts, most
commonly in a specific problem domain, and is a traditional application and/or subfield of artificial intelligence. A wide
variety of methods can be used to simulate the performance of the expert however common to most or all are 1) the
creation of a so-called " knowledgebase" which uses some knowledge representation formalism to capture the subject
matter experts (SME) knowledge and 2) a process of gathering that knowledge from the SME and codifying it according
to the formalism, which is called knowledge engineering. Expert systems may or may not have learning components but
a third common element is that once the system is developed it is proven by being placed in the same real world problem
solving situation as the human SME, typically as an aid to human workers or a supplement to some information system.

As a premiere application of computing and artificial intelligence, the topic of expert systems has
many points of contact with general systems theory, operations research, business process reengineering and
various topics in applied mathematics and management science.

22