Sudoku Java project - part 5

SOFTWARE REQUIREMENTS SPECIFICATION

SRS is software requirement specification it contains the s/w requirement details like what is front-end technology, backend technology, os and hardware architecture of the project.
SRS stands for Software Requirement Specification. It establishes the basis for agreement between customers and contractors or suppliers on what the software product is expected to do, as well as what it is not expected to do.

Some of the features of SRS are –
• It sets permits a rigorous assessment of requirements before design can begin.

• It sets the basis for software design, test, deployment, training etc. It also sets pre-requisite for a good design though it is not enough.
•It sets basis for software enhancement and maintenance.
• It sets Basis for Project plans like Scheduling and Estimation.
Thus, SRS should be consistent, correct, unambiguous & complete, document. The developer of the system can prepare SRS after detailed communication with the customer. An SRS clearly defines the following:
• External Interfaces of the system: They identify the information which is to flow ‘from and to’ to the system.
• Functional and non-functional requirements of the system. They stand for the finding of run time requirements.
• Design constraints:
The requirements gathering process is intensified and focused specifically on software. To understand the nature of the program(s) to be built, the software engineer (“analyst”) must understand the information domain for the software, as well as required function, behavior, performance, and interface. Requirements for both the system and the software are documented and reviewed with the user.

Design:-
Software design is actually a multi step process that focuses on four distinct attributes of a program data structure, software architecture, interface representations, and procedural (algorithmic) detail. The design process translates requirements into a representation of the
software that can be accessed for quality before coding begins. Like requirements, the design is documented and becomes part of the software configuration.

Code Generation: -
The design must be translated into a machine-readable form. The code generation step performs this task. If design is performed in a detailed manner, code generation can be accomplished mechanistically.

Testing: -
Once code has been generated, program testing begins. The testing process focuses on the logical internals of the software, ensuring that all statements have been tested and on the functional externals, that is, conducting tests to uncover errors and ensure that defined input will product actual results that agree with required results.

Waterfall Model
It is the simplest, oldest and most widely used process model. In this model, each phase of the life cycle is completed before the start of a new phase. It is actually the first engineering approach of software development.




The waterfall model is a breakdown of project activities into linear sequential phases, where each phase depends on the deliverables of the previous one and corresponds to a specialization of tasks. The approach is typical for certain areas of engineering design. In software development, it tends to be among the less iterative and flexible approaches, as progress flows in largely one direction ("downwards" like a waterfall) through the phases of conception, initiation, analysis, design, construction, testing, deployment and maintenance.

A slight modification of the waterfall model is a model with feedback. Once software is developed and is operational, then the feedback to various phases may be given.

SOFTWARE ENGINEERING PARADIGM

The linear sequential model sometimes called the classic life cycle or the waterfall model suggests a systematic, sequential approach to software development that begins at the system level and progresses through communication, planning, modeling, construction, and deployment. The following given figure illustrates the linear sequential model for software engineering.
❖ Communication: This activity involves heavy communication with customers and other stakeholders in order to gather requirements and other related activities.
❖ Planning: Here a plan to be followed will be created which will describe the technical tasks to be conducted, risks, required resources, work schedule etc.
❖ Modelling: A model will be created to better understand the requirements and design to achieve these requirements.
❖ Construction: Here the code will be generated and tested.
❖ Deployment: Here, a complete or partially complete version of the software is represented to the customers to evaluate and they give feedback based on the evaluation.

In this project, very first I get to know how the processing is done in the Java programming. When I had accepted this project the purpose is to develop software that should assists to generate the report. The software will serve them as an automated system in performing all the operation of the Sudoku Game

Before starting this project or system there are some information’s needed, they are:
1. First one is that understand about the working mechanism of Sudoku Game
2. Find out that which type of Operation should be adopted by the proposed project.
3. Which type hardware and software platform will be most suitable for the proposed project?

As the proposal system was being maintained onto the form of paper based, literature relating to this system was available in the forms of various reports. Various documents were available to collect data about the shortcoming of the existing system. The system provides information that how the work is being done and how data are maintained which are useful for the user, what changes need to be made.
❖ Requirement specification

Problem clarifications in this case are much more difficult. In either case, before any further steps can be taken, the project requests must be clearly states.
This phase (initial study) involves estimating whether or not a development project is worthwhile. Problems with the current automated or manual system are identified, as well as the benefits and costs of an alternative system. If the benefits seem to outright the costs (especially when compared with competing projects), a green signal may be given to continue the project, and detailed plans and schedules are drafted for making the system a reality.