software requirements
Writing Software Requirements Specifications
A well-designed, well-written SRS accomplishes four major goals:
- It provides feedback to the customer. An SRS is the customer's assurance that the development organization understands the issues or problems to be solved and the software behavior necessary to address those problems. Therefore, the SRS should be written in natural language (versus a formal language, explained later in this article), in an unambiguous manner that may also include charts, tables, data flow diagrams, decision tables, and so on.
- It decomposes the problem into component parts. The simple act of writing down software requirements in a well-designed format organizes information, places borders around the problem, solidifies ideas, and helps break down the problem into its component parts in an orderly fashion.
- It serves as an input to the design specification. As mentioned previously, the SRS serves as the parent document to subsequent documents, such as the software design specification and statement of work. Therefore, the SRS must contain sufficient detail in the functional system requirements so that a design solution can be devised.
- It serves as a product validation check. The SRS also serves as the parent document for testing and validation strategies that will be applied to the requirements for verification.
Full Article: http://www.techwr-l.com/techwhirl/magazine/writing/softwarerequirementspecs.html
The SolovatSoft development team adopts project methodologies based on the client's project specifications and requirements. Following are the basic popular models used by our company.
System Development Life Cycle (SDLC) - Waterfall
Prototype Development
Rational Unified Process
Microsoft Solutions Framework (MSF)
Rapid Application Development
Agile Development
System Development Life Cycle Model (SDLC Model)
System Development Life Cycle Model or Waterfall development approach. It has the following activities.
1. Software Requirements Analysis
2. Systems Design
3.Development
4. System Testing
5. Release and Maintenance
Software Requirement Analysis
This is also known as feasibility study. In this phase, the onsite/offshore team works with the client together and study the client requirements. We investigate the need for possible IT solution. By the end of this phase, the team creates a document that has the specific requirements for the proposed system. It also includes the team members task assignments, price, project plan, and milestones.
System Design
In this phase, the software development process, the system overall structure and all details are pre-defined based on the previously discovered requirements. The system architecture, the database design, the data data types and structure design need to be clarified at this stage. A software development roadmap is created.
Development:
Programmers write code and perform the unit testing.
System Testing:
Once the Development phase is over, the software modules needs to be tested all together. Different type of test should be used at this phase depending on the system type.
Prototyping Model
This is a weekly/bi-weekly build version of the development. In this model, once the requirement analysis and design are completed, the development process starts. Upon completion of the prototype creation, the client reviews the result and provides feedback. After several number of builds, the complete system is sent to the customer. In this methodology, the software is evolved as a result of periodic information exchange between the customer and vendor.
Offshore Agile Development
During the past 2 years, companies have begun to use Agile development processes and offshore outsourcing to realize incremental gains. The benefits that attract companies already doing offshore or companies already doing Agile development are quite different, however, as are the teams' motivations for blending the two processes.
Implementing Agile processes in offshore projects. Properly injecting Agile techniques into an offshore development project can add improved responsiveness and business/IT benefit.
To make offshore relationships successful, software teams has to dramatically improve their software processes. For example, customers/business users have had to learn how to specify their requirements carefully and understand that changing those requirements midstream could cause significant cost and time overruns. Many non IT users struggle to deal with these requirements. And their inability to manage with it can eliminate much of the savings the offshore development offers.
Communication takes center approach, between the business users, the internal IT team, and the offshore team. Short iterations force frequent reviews so business people can approve functionality or provide feedback before too much time or money has been spent on that milestone.
Agile development indirectly saves organizations money because it produces higher-quality code that meets customer needs, but cost savings aren't typically the key benefit.