In enhancement and replacement projects, even if you don’t have existing documentation, you do have a system to work from to discover the relevant requirements. During enhancement projects, consider drawing a dialog map for the new screens you have to add, showing the navigation connections to and from existing display elements. You might write use cases or user stories that span the new and existing functionality.
In replacement system projects, you need to understand all of the desired functionality, just as you do on any new development project. Study the user interface of the existing system to identify candidate functionality for the new system. Examine existing system interfaces to determine what data is exchanged between systems today. Understand how users use the current system. If no one understands the functionality and business rules behind the user interface, someone will need to look at the code or database to understand what’s going on. Analyze any documentation that does exist—design documents, help screens, user manuals, training materials—to identify requirements.
You might not need to specify functional requirements for the existing system at all, instead
creating models to fill the information void. Swimlane diagrams can describe how users do their jobs with the system today. Context diagrams, data flow diagrams, and entity-relationship diagrams are also useful. You might create user requirements, specifying them only at a high level without filling in all of the details. Another way to begin closing the information gap is to create data dictionary entries when you add new data elements to the system and modify existing definitions. The test suite might be useful as an initial source of information to recover the software requirements, because tests represent an alternative view of requirements.
SRS is a document created by system analyst after the requirements are collected from various stakeholders. SRS defines how the intended software will interact with hardware, external interfaces, speed of operation, response time of system, portability of software across various platforms, maintainability, speed of recovery after crashing, Security, Quality, Limitations etc. The requirements received from client are written in natural language. It is the responsibility of the system analyst to document the requirements in technical language so that they can be comprehended and used by the software development team. SRS should come up with the following features:
User Requirements are expressed in natural language.
Technical requirements are expressed in structured language, which is used inside the organization.
Design description should be written in Pseudo code.
Format of Forms and GUI screen prints.
Conditional and mathematical notations for DFDs etc.
A software product can be judged by what it offers and how well it can be used. This software must satisfy on the following grounds:
Well-engineered and crafted software is expected to have the following characteristics:
This tells us how well the software works in operations. It can be measured on:
This aspect is important when the software is moved from one platform to another:
This aspect briefs about how well the software has the capabilities to maintain itself in the ever-changing environment:
A Software Project is the complete procedure of software development from requirement gathering to testing and maintenance, carried out according to the execution methodologies, in a specified period of time to achieve intended software product.
Need of software project management Software is said to be an intangible product. Software development is a kind of all new stream in world business and there is very little experience in building software products. Most software products are tailor made to fit client’s requirements. The most important is that the underlying technology changes and advances so frequently and rapidly that the experience of one product may not be applied to the other one. All such business and environmental constraints bring risk in software development hence it is essential to manage software projects efficiently.
After requirement gathering, the team comes up with a rough plan of software process. At this step the team analyzes if a software can be designed to fulfill all requirements of the user, and if there is any possibility of software being no more useful. It is also analyzed if the project is financially, practically, and technologically feasible for the organization to take up. There are many algorithms available, which help the developers to conclude the feasibility of a software project
A software project manager is a person who undertakes the responsibility of executing the software project. Software project manager is thoroughly aware of all the phases of SDLC that the software would go through. The project manager may never directly involve in producing the end product but he controls and manages the activities involved in production. A project manager closely monitors the development process, prepares and executes various plans, arranges necessary and adequate resources, maintains communication among all team members in order to address issues of cost, budget, resources, time, quality and customer satisfaction.
The most serious outcome of a poor requirements elicitation process is that : The developers are solving the wrong problem. This guarantees the failure of the whole project. Even if the developers are solving essentially the right problem, a poor elicitation process can have other negative outcomes. The customers can be dissatisfied; this often happens if the developers did not really listen to them, or if the developers dominated the process and tended to force their own views and interpretations on the customers. Dissatisfaction may result in less effective participation by the stakeholders or customers, resulting in less complete answers to the developer’s questions. The dissatisfaction can continue to affect the project through development and delivery of the software. A poor elicitation process often leads to a chaotic development process. The developers may discover that they are missing important information, resulting in additional meetings with the customers. The developers may make the wrong decisions or tradeoffs because of a lack of understanding of the users’ needs. Requirements may change more often, resulting in greater need for configuration management, or in delays or wasted effort in design and implementation. The result is cost and schedule overruns, and sometimes failed or canceled projects. All of these effects can result in a loss of money for the company developing or buying the software, loss of reputation or credibility for the developers, and a decline in the developers’ morale. s or, in extreme cases, actively sabotage the development effort.
Validation is process of examining whether or not the software satisfies the user requirements. It is carried out at the end of the SDLC. If the software matches requirements for which it was made, it is validated.
- Validation ensures the product under development is as per the user requirements.
- Validation answers the question – "Are we developing the product which attempts all that user needs from this software ?".
- Validation emphasizes on user requirements.
Verification is the process of confirming if the software is meeting the business requirements, and is developed adhering to the proper specifications and methodologies.
- Verification ensures the product being developed is according to design specifications.
- Verification answers the question– "Are we developing this product by firmly following all design specifications ?"
- Verifications concentrates on the design and system specifications.
Targets of the test are :
Errors - These are actual coding mistakes made by developers. In addition, there is a difference in output of software and desired output, is considered as an error.
Fault - When error exists fault occurs. A fault, also known as a bug, is a result of an error which can cause system to fail.
Failure - failure is said to be the inability of the system to perform the desired task. Failure occurs when fault exists in the system