MCS 014 System Analysis And Design Important Questions and Notes
With Solved Question/Answers
MCS-014 Notes
UNIT 4 - INTRODUCTION TO DOCUMENTATION OF SYSTEMS
What is the need for Documentation?
Documentation is needed because it is
• a means for transfer of knowledge and details about description of the system
• to communicate among different teams of the software project
• to help corporate audits and other requirements of the organization
• to meet regulatory demand
• needed for IT infrastructure management and maintenance; and
• needed for migration to a new software platform.
➢ The Process of Documentation
The following are various steps involved in the process of documentation:
Collection of source material: The very first step of any documentation process is to acquire the required source material for preparation of document.
Documentation Plan: The documenter is responsible for preparation of a documentation plan, which specifies the details of the work to be carried out to prepare the document. It also defines and the target audience.
Review of Plan: The plan as set out in the process above is reviewed to see that material acquired is correct and complete.
Creation of Document: The document is prepared with the help of document generator.
Testing of Document: The document created is tested for usability as required by the target audience.
Maintain Document: Once the document is created and distributed, it must be kept up to date with new version of the software product.
▪ System Requirements Specification
A software requirements specification (SRS) is a document that captures complete description about how the system is expected to perform.
Requirements of SRS: The SRS should specify only the external system behaviour and not the internal details. A good SRS is flexible to change and acts as a reference tool for system developer, administrator, and maintainer.
▪ Characteristics of a System Requirements Specification (SRS)
1. All the requirements must be stated unambiguously. Every requirement stated has only one interpretation.
2. It should be complete. The definition should include all functions and constraints intended by the system user.
3. The requirements should be realistic and achievable with current technology. There is no point in specifying requirements which are unrealisable using existing hardware and software technology
4. It must be verifiable and consistent. The requirements should be shown to be consistent and verifiable. The requirements are verified by system tester during system testing.
5. It should be modifiable. The structure and style of the SRS are such that any necessary changes to the requirements can be made easily, completely, and consistently.
6. It should be traceable to other requirements and related documents. The SRS should facilitate the referencing of each requirement for future development or enhancement of documentation.
▪ Structure of a Typical SRS Document:
1.Introduction
• System reference and business objectives of the document.
• Goals and objectives of the software, describing it in the context of the computer-based system.
• The scope of the document.
2.Informative description about the system
• Information flow representation.
• Information content and structure representation.
• Description of sub-systems and System interface.
3.Functional Description of the system
• Functional description.
• Restrictions/limitations.
• Performance requirements.
• Design constraints.
4.Test and validation criteria
• Performance limitation, if any.
• Expected software response.
• It is essential that time and attention be given to this section.
5.Glossary
• Definitions of all technical or software-specific terms used in the document.
6.Bibliography
• List and reference of all documents that relate to the software.
7.Appendix
• Supplementary information to the specification.
▪ System Design Specification
The system design specification gives a complete understanding of the
details of each component of the system, and its associated algorithms,
etc. It has a primary audience, the system implementer. The system design
specification is developed in a two-stage process:
In the first step, design specification generally describes the overall
architecture of the system at a higher level.
The second step provides the technical details of low-level design, which
will guide the implementer.
▪ Tools for describing design
The following are some of the tools that can be used in the System Design Specification to describe various aspects of the design.
Data Dictionary - Complete definition of each data item and its synonyms are included in the data dictionary. A data dictionary may consist of description of data elements and definitions of tables.
Description of data element:
• Name and aliases of data item
• Uses
• Format
• Additional information such as default values, initial value(s), limitations, and constraints that are associated with the data elements.
Table definitions
• Table name and Aliases.
• Table owner or database name.
• Key order for all the tables, possible keys including primary key and foreign key.
• Information about indexes that exist on the table.
E-R model - Entity-relationship model is database analysis and design tool. It lists real-life application entities and defines the relationship between real life entities that are to be mapped to database. E-R model forms basis for database design.
Decision table - A decision table shows the way the system handles input conditions and subsequent actions on the event. A decision table is composed of rows and columns, separated into four separate quadrants.
State machine diagram - State machine diagrams are good at exploring the detailed transitions between states as the result of events.
Object Interaction Diagram - It illustrates the interaction between various objects of an object-oriented system. This diagram consists of directed lines between clients and servers. Each box contains the name of the object. This diagram also shows conditions for messages to be sent to other objects. The vertical distance is used to show the life of an object.
Flow chart – It shows the flow of processing control as the program executes.
Inheritance Diagram - It is a design diagram work product that primarily documents the inheritance relationships between classes and interfaces in object-oriented modelling. The standard notation consists of one box for each class.
Aggregation Diagram - The E-R model cannot express relationships among relationships. An aggregation diagram shows relationships among objects. When a class is formed as a collection of other classes, it is called an aggregation relationship between these classes.
Structure Chart - A structure chart is a tree of sub-routines in a program. It indicates the interconnections among the sub-routines. The sub-routines should be labelled with the same name used in the pseudo code.
Pseudocode - Pseudocode is a kind of structured English for describing algorithms in an easily readable and modular form. It allows the designer to focus on the logic of the algorithm without being distracted by details of language syntax in which the code is going to be written.
The pseudocode needs to be complete.
For Example IF Hours Worked > MaxWorkHour THEN
Display overtime message ELSE Display regular time message
ENDIF
▪ Contents of a typical System Design Specification document content
1. Introduction
1.1 Purpose and scope of this document
1.2 Definitions, acronyms, abbreviations and references Definitions and abbreviations used are narrated in alphabetic order.
2. System architecture description
2.1 Overview of modules, components of the system and sub-systems
2.2 Structure and relationships
• Interrelationships and dependencies among various components are described.
• Here, the use of structure charts can be useful.
3. Detailed description of components
• Name of the component
• Purpose and function
• Sub-routine and constituents of the component
• Dependencies, processing logic including pseudocode
• Data elements used in the component.
4. Appendices.
➢ Test Design Document
During system development, this document provides the information needed for adequate testing. It also lists approaches, procedures, and standards to ensure that a quality product that meets the requirement of the user is produced. This document provides valuable input for the maintenance phase. The following IEEE standards describe the standard practices on software test and documentation:
1. 829-1998 IEEE Standard for Software Test Documentation
2. 1008-1987 (R1993) IEEE Standard for Software Unit Testing
3. 1012-1998 IEEE Standard for Software Verification and Validation
The following is the typical content of Test Design Document:
1.Introduction
Purpose - The purpose of this document and its intended audience are clearly stated.
Scope - Specify what is not covered in the scope of the testing such as, supporting or not third-party software.
Glossary - It gives definition of the technical terms used in this document
References - Any references to other external documents stated in this document including references to related project documents.
2.Test Plan
A test plan is a document that describes the scope, approach, resources, and schedule of intended testing activities
2.1. Schedules and Resources - An overview of the testing schedule in phases along with resources required for testing is specified.
2.2. Recording of Tests - Specify the format to be used to record test results.
2.3. Reporting test results - The summary of what has been tested successfully and the errors that still exist which are to be rectified is specified.
3. Verification Testing
3.1. Unit Testing - For each unit/component, there must be a test which will enable tester to know about the accurate functioning of that unit.
3.2. Integration testing - Integration test is done on modules or subsystems.
4. Validation Testing
4.1. System Testing - This is the top level of integration testing. At this level, requirements are validated as described in the SRS.
4.2. Acceptance and Beta Testing - It describes how the results of such testing will be reported back and handled by the developers.
➢ User Manual
This document is complete at the end of the software development process. The following are various categories of manuals:
• Introductory manual: How to get started with the system?
• Functional description: Describes functionality of the system.
• Reference manual: Details about the system facility.
• System administrator guide: How to operate and maintain the system?
• Installation document: How to install the system?
▪ The following is the typical content of User Manual:
1.Introduction
1.1 Purpose - The purpose of this document and its intended audience is stated.
1.2 Scope of Project - Explain who could use the product. Overview the services that it provides.
1.3 Glossary - Define the technical terms used in this document.
1.4 References - References to other documents cited anywhere in this document.
1.5 Overview of Document - The contents and organization of the rest of this document are described
2. Instructional Manual
2.1 System Usage - Provide examples of normal usage. Information on how to use the on-line help system, how to access it may be provided here.
3. User Reference Manual
3.1 List of Services - Provides an alphabetical listing of services provided by the system with references to page numbers.
3.2 Error Messages and Recovery - Provides an alphabetical list of all error messages.
4. Installation – Installation information is provided including the operating environment.
➢ DIFFERENT STANDARDS FOR DOCUMENTATION
This software documentation standard is used in the organization for uniform practices for documentation preparation, interpretation, change, and revision, to ensure the inclusion of essential requirements of different standards. The Documentation Standard defines various aspects of documentation such as style, format, and the document revision/change process of these documents.
The International Standards, ISO/IEC 12207 – Software life cycle process, describes documentation as one of the supporting parallel process of software development process. The following are other documentation standards:
1.ISO/IEC 18019: Guidelines for the design and preparation of user documentation for application software. This standard describes how to establish what information users need, how to determine the way in which that information should be presented to the users, and then how to prepare the information and make it available.
2. ISO/IEC 15910: Software user documentation process. This standard specifies the minimum process for creating user documentation for software that has a user interface, including printed documentation (e.g., user manuals), on-line documentation, help text and on-line documentation systems.
3. IEEE 1063: Software user Documentation. It provides minimum requirement for structure, information content and format for user documentation.
▪ Components of software user documentation as described in IEEE 1063:
1. Identification data (e.g., Title Page)
2. Table of contents
3. List of illustrations
4. Introduction
5. Information for use of the documentation such as description of software etc.
6. Concept of operations
7. Procedures
8. Information on software commands
9. Error messages and problem resolution
10. Glossary (to make the reader acquainted with unfamiliar terms)
11. Related information sources
12. Navigational features
13. Index
14. Search capability (for electronic document).
Questions related to Unit 4:
1.What is the need for Documentation? **
2.Draw a diagram depicting various stages of the process of Documentation.
3.What is SRS? Briefly explain any four characteristics of SRS.
4.Explain the following (with an example). (i) object interaction diagram* (ii) Inheritance Diagram* (ii) Aggregation Diagram*
5.Explain State-machine diagram with example?
6.How does a structure chart differ from a flow chart? *
7.What is a Test Design Document? Explain the contents of this document.
8.Explain the term 'User manual’? *
9.What are the various standards of documentation? Also, explain in brief, the various components of software user documentation. *